Subject: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Jul 2017 05:09:35 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-sipcore-content-id-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document really needs some discussion of the interoperability implications
of this change. Assuming I understand correctly, it is not possible to use this
mechanism with any existing content type, because receiving implementations
will expect to see a multipart and thus refuse to accept the message. Is that
correct? If so, it seems like a limitation which needs to be called out
explicitly

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document seems rather gratuitous to me. I agree it's somewhat of a
misfeature not to be able to have Content-ID in the SIP headers, but as the
examples in this document make clear, there's a straightforward workaround.
It's unclear to me that there is actually sufficient benefit to this mechanism
to publishing a standards track document with this change.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 5 Jul 2017 10:39:49 -0400

EKR,

> correct? If so, it seems like a limitation which needs to be called out

I don't see how "with any existing content type" has relevance here. The 
impact, if any, has to do with *references* (via cid: URLs in the sip 
message).

The impact would occur with some existing implementation that already 
has code to dereference a cid url in some context, but only knows to 
search for the reference starting in a multipart body. In that case, if 
the sender follows this document then the reference may not be resolved. 
That perhaps does deserve some discussion.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Jul 2017 18:53:06 +0000

Hi Ekr,

Note that the draft does not update the existing multipart usages (RFC 5368 and 6442). So, the draft does not cause any backward compatibility issues.

(Now, IF people want to change existing multipart usages, I agree there needs to be a mechanism to ensure that the endpoints understand it. We can add some text about that. I think that is also what Paul indicated.)

The draft allows any new usages not having to use multipart (if there is only one body part), and (as pointed out by Adam) makes existing usages (RFC 5368 and 6080) of Content-ID as a SIP header field standards compliant.

Regards,

Christer

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: 05 July 2017 14:10
To: The IESG <[email-masked]>
Cc: [email-masked]; Jean Mahoney <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

This document really needs some discussion of the interoperability implications of this change. Assuming I understand correctly, it is not possible to use this mechanism with any existing content type, because receiving implementations will expect to see a multipart and thus refuse to accept the message. Is that correct? If so, it seems like a limitation which needs to be called out explicitly

This document seems rather gratuitous to me. I agree it's somewhat of a misfeature not to be able to have Content-ID in the SIP headers, but as the examples in this document make clear, there's a straightforward workaround.
It's unclear to me that there is actually sufficient benefit to this mechanism to publishing a standards track document with this change.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Jul 2017 12:14:00 -0700

On Wed, Jul 5, 2017 at 11:53 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Ekr,
>
> Note that the draft does not update the existing multipart usages (RFC
> 5368 and 6442). So, the draft does not cause any backward compatibility
> issues.
>

I must have missed this. Can you point me to where I can find that?

>
> (Now, IF people want to change existing multipart usages, I agree there
> needs to be a mechanism to ensure that the endpoints understand it. We can
> add some text about that. I think that is also what Paul indicated.)
>
> The draft allows any new usages not having to use multipart (if there is
> only one body part), and (as pointed out by Adam) makes existing usages
> (RFC 5368 and 6080) of Content-ID

Now I'm confused about the status of 5368....

-Ekr

> as a SIP header field standards compliant.
>
> Regards,
>
> Christer
>
> Cc: [email-masked]; Jean Mahoney <
> [email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> This document really needs some discussion of the interoperability
> implications of this change. Assuming I understand correctly, it is not
> possible to use this mechanism with any existing content type, because
> receiving implementations will expect to see a multipart and thus refuse to
> accept the message. Is that correct? If so, it seems like a limitation
> which needs to be called out explicitly
>
>
> It's unclear to me that there is actually sufficient benefit to this
> mechanism to publishing a standards track document with this change.
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Jul 2017 19:25:04 +0000

Hi,

>I must have missed this. Can you point me to where I can find that?

The draft does NOT update those RFCs, so there is nothing to find :)

The draft uses those RFCs to show how things have to be done without the draft.

>>(Now, IF people want to change existing multipart usages, I agree there needs to be a mechanism to ensure that the endpoints understand it. We can add some text about >>that. I think that is also what Paul indicated.)
>>
>>The draft allows any new usages not having to use multipart (if there is only one body part), and (as pointed out by Adam) makes existing usages (RFC 5368 and 6080) of >>Content-ID
>

In RFC 5368 Content-ID is used as a SIP header field.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Jul 2017 12:28:43 -0700

> The draft uses those RFCs to show how things have to be done without the

Yeah, I think given these examples, one might naturally infer that the rule
was being
relaxed for them. The draft needs to be clear about its scope, and not just
rely on
people looking at "Updates:"

> add some text about >>that. I think that is also what Paul indicated.)
> >>
> (RFC 5368 and 6080) of >>Content-ID
> >

So then this is retrospectively changing the status of this.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Jul 2017 19:34:55 +0000

Hi,

>Yeah, I think given these examples, one might naturally infer that the rule was being
>relaxed for them. The draft needs to be clear about its scope, and not just rely on

We will add some text, saying that the draft does not change the existing usages.

>>>>(Now, IF people want to change existing multipart usages, I agree there needs to be a mechanism to 
>>>>ensure that the endpoints understand it. We can add some text about >>that. I think that is also what Paul indicated.)
>>>>
>>>>The draft allows any new usages not having to use multipart (if there is only one body part), and (as pointed 
>>>>out by Adam) makes existing usages (RFC 5368 and 6080) of >>Content-ID
>>>

The draft defines Content-ID as a SIP header field, which it wasn't when RFC 5368 was published - although people seemed to have assumed it was, as it is used as a SIP header field both in 5368 and 6080.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Jul 2017 10:19:46 -0500

> (Now, IF people want to change existing multipart usages, I agree there needs to be a mechanism to ensure that the endpoints understand it. We can add some text about that. I think that is also wha…

Right. I think this document really needs to contain text that 
normatively says that implementations can't use Content-ID as a SIP 
header field (and elide the multipart top-level type) except with those 
mechanisms that have explicitly "opted in" -- which is to say, the 
corresponding protocol document needs to contain text saying that this 
is an okay thing to do. Example 1, in particular, needs a clear 
disclaimer that the described mechanism *cannot* be used with this 
example unless and until RFC6442 is updated.

> The draft allows any new usages not having to use multipart (if there is only one body part), and (as pointed out by Adam) makes existing usages (RFC 5368 and 6080) of Content-ID as a SIP header fi…

I'll note that these two documents didn't explicitly say that they could 
use Content-ID as a SIP header field; they only showed doing so in 
examples. For the sake of normative tidiness, I would suggest that 
sipcore-content-id specifically update these two RFCs, and have text 
that explicitly and normatively allows the use of non-multipart 
top-level content types for multiple-target REFER requests and for 
device profile NOTIFY messages.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Jul 2017 17:45:52 +0000

Hi,

>> (Now, IF people want to change existing multipart usages, I agree 
>> there needs to be a mechanism to ensure that the endpoints understand 
>> it. We can add some text about that. I think that is also what Paul 
>> indicated.)
>
>Right. I think this document really needs to contain text that normatively says that implementations can't use Content-ID as a SIP header field (and elide the multipart top->level type) except with those mechanisms that have explicitly "opted in" -- which is to say, the corresponding protocol document needs to contain text saying that this is an >okay thing to do. Example 1, in particular, needs a clear disclaimer that the described mechanism *cannot* be used with this example unless and until RFC6442 is updated.

What about the following new section:

      <section title="Backward compatibility" toc="default">
        <t>
          This specification does not update any of the current specifications defining usage of Content-ID
          URLs for referencing body parts, and implementations of such specifications MUST NOT be modified in 
          a backward incompatible way (even if the publication of this specification would allow such change), 
          unless there is a mechanism to ensure that the endpoints support such modification. 
        </t>
      </section>

>> The draft allows any new usages not having to use multipart (if there is only one body part), 
>> and (as pointed out by Adam) makes existing usages (RFC 5368 and 6080) of Content-ID as a 
>> SIP header field standards compliant.
>
> I'll note that these two documents didn't explicitly say that they could use Content-ID as a SIP header field; they only showed 
> doing so in examples. For the sake of normative tidiness, I would suggest that sipcore-content-id specifically update these two 
> RFCs, and have text that explicitly and normatively allows the use of non-multipart top-level content types for multiple-target 
> REFER requests and for device profile NOTIFY messages.

We could update RFC 5368 by updating the second paragraph of section 7:

OLD:

   "The Refer-To header field of a REFER request with multiple REFER-
   Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource
   Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part
   that carries the URI list.  The REFER-Issuer SHOULD NOT include any
   particular URI more than once in the URI list."

NEW:

   "The Refer-To header field of a REFER request with multiple REFER-
   Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource
   Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part
   that carries the URI list.  The REFER-Issuer SHOULD NOT include any
   particular URI more than once in the URI list. The REFER
   request can contain a SIP Content-ID header field referencing the
   message-body."

We could update RFC 6080 by adding the following new paragraph to section 6.5:

NEW:

   "The NOTIFY request can contain a SIP Content-ID header field referencing the
   message-body."

In addition, I suggest adding the following paragraph to the 'Problem statement' section:

        <t>
          <xref target="RFC5368" pageno="false" format="default"/> and <xref target="RFC6080"
          pageno="false" format="default"/> contain examples that show usage of a SIP Content-ID 
          header field referencing a complete message-body, eventhough such usage had not been
          specified when those RFCs were published.
        </t>

...and to add the following bullet to the 'Solution' section:

              <t>
                    Updates <xref target="RFC5368" pageno="false" format="default"/> and <xref target="RFC6080"
                    pageno="false" format="default"/> by adding explicit text saying that a SIP Content-ID header 
                    field can be used.
              </t> 

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Jul 2017 16:23:43 -0500

>            unless there is a mechanism to ensure that the endpoints support such modification.

That looks good, with two minor adjustments.

1. "Except as noted in section <x>, this specification does not 
update..." where "section <x>" refers to the updates you propose below.

2. In section 1.4.1, add a "Note that this example cannot be used with 
the mechanism described in this document unless and until [RFC6442] is 
updated; see section <Backwards compatibility> for details."

>     request can contain a SIP Content-ID header field referencing the

I'd make it a normative "...request MAY contain...", but aside from 
that, it looks fine.

>     "The NOTIFY request can contain a SIP Content-ID header field referencing the

Same comment regarding "MAY," but that looks fine.

>                      pageno="false" format="default"/> by adding explicit text saying that a SIP Content-ID header

That looks reasonable; but do note that RFC5368 and RFC6080 need to 
appear in the document metadata (as "Updates"), and they need to be 
mentioned in the Abstract ("This document updates RFC 5368 and RFC 6080 
to clarify their use of Content-ID.")

/a

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Jul 2017 16:35:11 -0500

Some comments inline. 

BTW, I think updates to 5368 and 6080 would be material enough to require WG approval. (Read: sipcore participants, please pay attention)

> On Jul 6, 2017, at 12:45 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

Won’t the “does not update” bit become untrue if we add the proposed updates (below)?

>   message-body.”

I’m not sure I agree there’s a need to update 5386, since as far as I can find, it doesn’t have text that says anything about how the content-ID is labeled other than in the example. But I don’t object if other’s feel strongly. If w do update it, I suggest the following variation (or something to it’s effect):

NEW:
  "The Refer-To header field of a REFER request with multiple REFER-
  Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource
  Locator (URL) as per RFC 2392 [RFC2392]) that points to the message body 
  or body part that carries the URI list.  The REFER-Issuer SHOULD NOT 
  include any particular URI more than once in the URI list. The REFER
  request can use either a MIME Content-ID header field [RFC4483 ] or a 
  SIP Content-ID header field [RFCTHIS] to label the message-body.”

>   message-body.”

I’m not sure that quite works, since there’s already text in 6.5 saying it MUST use the Content-ID MIME header field.

How about this for the second sentence of the first paragraph:

OLD:
   For profile data delivered via content indirection, i.e., a pointer to a PCC, then 
   the Content-ID MIME header, as described in [RFC4483 ], MUST be used 
   for each profile document URI.
NEW
   For profile data delivered via content indirection, i.e., a pointer to a PCC, then 
   either a Content-ID MIME header field [RFC4483 ] or the Content-ID SIP
   header field [RFCTHIS]  MUST be used for each profile document URI.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Jul 2017 16:42:29 -0500

> On Jul 6, 2017, at 4:23 PM, Adam Roach <[email-masked]> wrote:
> 
> 1. "Except as noted in section <x>, this specification does not update..." where "section <x>" refers to the updates you propose below.
> 
> 2. In section 1.4.1, add a "Note that this example cannot be used with the mechanism described in this document unless and until [RFC6442] is updated; see section <Backwards compatibility> for details.”

+1 on both

> I'd make it a normative "...request MAY contain...", but aside from that, it looks fine.

I had a slightly different take (my mail crossed yours in my mailbox): I don’t see any text that says you also [can/MAY] use the mime header. So if this becomes normative, the question I have is do we want to say you MAY use the sip header or the mime header or something else, or say you MUST use either the sip header or the mime header?

> Same comment regarding "MAY," but that looks fine.

Same comment to your comment (except there’s already text in 6080 6.5 that says MUST use the mime header.)

> That looks reasonable; but do note that RFC5368 and RFC6080 need to appear in the document metadata (as "Updates"), and they need to be mentioned in the Abstract ("This document updates RFC 5368 and RFC 6080 to clarify their use of Content-ID.")
> 
> /a
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Jul 2017 19:39:13 +0000

Hi,

One thing that I forgot earlier:

Unlike the other RFCs defining Content-ID usages, RFC 6442 actually doesn't contain examples with a single body part - all examples contain multipart bodies with two body parts: SDP and location.

So, the question is what an implementation would do if it ONLY sends location? Would it use a SIP Content-ID header field, or will it use a multipart body with a single body part? 

So, since we WILL allow SIP Content-ID header field (with a non-multipart body) for RFC 5638 and RFC 6080, shouldn't we do it also for RFC 6442? I personally think it would be safe to do so, because the only case where it could cause problem is if someone ONLY sends location (i.e., no SDP or any other body part), and does not use multipart. 

Regards,

Christer

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: 06 July 2017 23:24
To: Christer Holmberg <[email-masked]>; Eric Rescorla <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's Discuss on draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT)

On 7/6/17 12:45, Christer Holmberg wrote:
>>> there needs to be a mechanism to ensure that the endpoints 
>>> understand it. We can add some text about that. I think that is also 
>>> what Paul
>>> indicated.)

2. In section 1.4.1, add a "Note that this example cannot be used with the mechanism described in this document unless and until [RFC6442] is updated; see section <Backwards compatibility> for details."

>>> The draft allows any new usages not having to use multipart (if 
>>> there is only one body part), and (as pointed out by Adam) makes 
>>> existing usages (RFC 5368 and 6080) of Content-ID as a SIP header field standards compliant.
>> I'll note that these two documents didn't explicitly say that they 
>> could use Content-ID as a SIP header field; they only showed doing so 
>> in examples. For the sake of normative tidiness, I would suggest that 
>> sipcore-content-id specifically update these two RFCs, and have text that explicitly and normatively allows the use of non-multipart top-level content types for multiple-target REFER requests and for device profile NOTIFY messages.

/a

---

From: Ben Campbell <[email-masked]>
Date: Fri, 7 Jul 2017 16:02:42 -0500

> On Jul 7, 2017, at 2:39 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

In general, we should minimize material changes post last-call and IESG evaluation. That doesn’t mean we can’t do it, just that we need good reason. In this case, how likely are we to see location sent without sdp in real life? Do people expect situations where a sender sends the SIP header field but the receiver only knows about the MIME header? (That is, does this fall into the interop issue already discussed?)

Otherwise, this seems reasonable, perhaps with something to the effect of “When sending location with no other body parts…” added.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Jul 2017 10:59:19 +0000

Hi,

>> Unlike the other RFCs defining Content-ID usages, RFC 6442 actually
>>doesn't contain examples with a single body part - all examples contain
>>multipart bodies with two body parts: SDP and location.
>> 
>> So, the question is what an implementation would do if it ONLY sends
>>location? Would it use a SIP Content-ID header field, or will it use a
>>multipart body with a single body part?
>> 
>> So, since we WILL allow SIP Content-ID header field (with a
>>non-multipart body) for RFC 5638 and RFC 6080, shouldn't we do it also
>>for RFC 6442? I personally think it would be safe to do so, because the
>>only case where it could cause problem is if someone ONLY sends location
>>(i.e., no SDP or any other body part), and does not use multipart.
>>  
>
>In general, we should minimize material changes post last-call and IESG
>evaluation. That doesn¹t mean we can¹t do it, just that we need good
>reason. 

Actually, I don¹t think it would be a change to the current version,
because it doesn¹t say anything about backward compatibility: it simply
says that one can now use Content-ID as a SIP header field :)

>In this case, how likely are we to see location sent without sdp in real
>life?
> Do people expect situations where a sender sends the SIP header field
>but the receiver only knows about the MIME header? (That is, does this
>fall into the interop issue already discussed?)

I would say that currently it is very unlikely - which is the reason I
think we could allow a non-multipart message body without causing any
backward compatibility issues.

>Otherwise, this seems reasonable, perhaps with something to the effect of
>³When sending location with no other body partsŠ² added.

Yes.

Regards,

Christer

>> Cc: [email-masked]; [email-masked];
>>[email-masked]; [email-masked]
>> Subject: Re: Eric Rescorla's Discuss on
>>draft-ietf-sipcore-content-id-07: (with DISCUSS and COMMENT)
>> 
>>>>> Note that the draft does not update the existing multipart usages
>>>>>(RFC 5368 and 6442). So, the draft does not cause any backward
>>>>>compatibility issues.
>>>>> 
>>>>header field (and elide the multipart top->level type) except with
>>>>those mechanisms that have explicitly "opted in" -- which is to say,
>>>>the corresponding protocol document needs to contain text saying that
>>>>this is an >okay thing to do. Example 1, in particular, needs a clear
>>>           This specification does not update any of the current
>>>specifications defining usage of Content-ID
>>>                     Updates <xref target="RFC5368" pageno="false"
>>>format="default"/> and <xref target="RFC6080"
>>>                     pageno="false" format="default"/> by adding
>>>explicit text saying that a SIP Content-ID header
>>>                     field can be used.
>>>               </t>
>>> 
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Jul 2017 14:41:31 +0000

Hi,

...

>Won¹t the ³does not update² bit become untrue if we add the proposed
>updates (below)?

You are correct.

Perhaps we instead could say:

     ³If an existing specification explicitly defines the usage of a
multipart message body for
      carrying a single body part, that specification MUST be updated in
order to allow usage of a non-multipart message body
      for carrying the body part, and for referencing the whole message
body using a Content-ID URL."

-------

>>>could use Content-ID as a SIP header field; they only showed
>>> doing so in examples. For the sake of normative tidiness, I would
>>>suggest that sipcore-content-id specifically update these two
>>> RFCs, and have text that explicitly and normatively allows the use of
>>>non-multipart top-level content types for multiple-target
>>   message-body.²
>I¹m not sure I agree there¹s a need to update 5386, since as far as I can
>find, it doesn¹t have text that says anything about how the content-ID is
>labeled other than in the example.

Based on the new suggested text above, I agree that there would be no
need. But, I have no strong opinion.

>But I don¹t object if other¹s feel strongly. If w do update it, I suggest
>the following variation (or something to it¹s effect):
>
>NEW:
>  SIP Content-ID header field [RFCTHIS] to label the message-body.²

s/label the message-body/label the body-part

---------

>>   message-body.²
>I¹m not sure that quite works, since there¹s already text in 6.5 saying
>it MUST use the Content-ID MIME header field.
>

Looks good.

Regards,

Christer