Subject: [sipcore] Draft new version: draft-content-id-09

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Sep 2017 09:20:47 +0000

Hi,

Based on Ben¹s comment, we¹ve submitted a new version (-09) of
draft-content-id.

Regards,

Christer

On 01/09/17 00:27, "Ben Campbell" <[email-masked]> wrote:

>Hi,
>
>I¹m a little confused by the new text in section 1.6. (Apologies, I
>realize that you proposed that text in email, but I somehow missed it at
>the time.)
>
>> 1.6.  Backward compatibility
>> 
>>    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 MIME entity, and for
>>    referencing the whole message-body using a Content-ID URL.
>> 
>
>
>Is the point of that to simply say that an update must occur, or that
>implementations cannot use a non-multipart body unless such an update
>occurs? If the former, I suggest dropping the normative language, for
>example by replacing ³MUST be² with ³should be², since we can¹t really
>make people update a specification,
>
>If the latter, I propose the following:
>
>  "If an existing specification only defines the usage of a
>   multipart message-body for carrying a single body part to be referenced
>   by a Content-ID URL, , implementations MUST NOT carry the MIME entity
>   in a non-multipart message-body unless the specification is updated
>   to explicitly allow it.²
>
>Ben.
>
>
>> On Aug 31, 2017, at 6:34 AM, Christer Holmberg
>><[email-masked]> wrote:
>> 
>> Hi,
>> 
>> Based on the IESG reviews, we have submitted a new version (-08) of
>>draft-content-id.
>> 
>> Note that we did NOT include any update to RFC 6080, because we
>>double-checked the RFC6080
>> usage of Content-ID header field and we believe that:
>> 
>> - RFC6080 does NOT use the *SIP* Content-ID header; and
>> - RFC6080 does NOT need to use the *SIP* Content-ID header.
>> 
>> Reasons:
>> 
>> RFC6080 uses Content-ID heaer field as follows:
>> 
>> ---------------
>>    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.
>> ---------------
>> and gives example as follows:
>> ---------------
>> NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
>>         @192.168.1.44 SIP/2.0
>> Event: ua-profile;effective-by=3600
>> From: sip:[email-masked]
>>        ;tag=abca
>> To: sip:[email-masked]
>>      ;tag=1234
>> Call-ID: [email-masked]
>> CSeq: 322 NOTIFY
>> Via: SIP/2.0/UDP 192.0.2.3;
>>    branch=z9hG4bK1e3effada91dc37fd5a0c95cbf6767d0
>> MIME-Version: 1.0
>> Content-Type: message/external-body; access-type="URL";
>>                expiration="Mon, 01 Jan 2010 09:00:00 UTC";
>>                URL="http://example.com/z100-000000000000.html";
>>                size=9999;
>>                hash=10AB568E91245681AC1B
>> 
>> Content-Type: application/x-z100-device-profile
>> Content-ID: <[email-masked]>
>> ---------------
>> 
>> The Content-ID header field above is NOT a *SIP* header field since it
>>is placed *after* CRLF.
>> 
>> The Content-ID header field above is a part of the message-body.
>> 
>> Since the message-body is of message/external-body MIME type the
>>semantic of the Content-ID header field above follows
>> RFC2046 section 5.2.3 and RFC4483 section 5.6 - i.e. the Content-ID
>>header field above is a MIME header field and is used by
>> UAS to determine whether the content fetched from
>>http://example.com/z100-000000000000.html has changed between
>> UAC sending the SIP NOTIFY message and UAS receiving the SIP NOTIFY
>>message.
>> 
>> 
>> Regards,
>> 
>> Christer
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 1 Sep 2017 16:53:20 -0500

Thanks for adding new text describing the historical context. I think I 
was expecting something that bears a bit more on the "the old documents 
are broken, and this document fixes them" aspect; more along the lines of:

> Some existing specifications, such as [RFC5368], contain examples that 
> show usage of a SIP Content-ID header field referencing a complete 
> message-body, even though such usage has never been specified. Many 
> implementors have interpreted these examples to indicate that such 
> usage is allowed by the corresponding specification, despite the 
> absence of language allowing it. This document updates the normative 
> language in the affected documents to explicitly allow such usage.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 2 Sep 2017 07:22:11 +0000

Hi,

>Thanks for adding new text describing the historical context. I think I was expecting >something that bears a bit more on the "the old documents are broken, and this >document fixes them" aspect; more along the lines of:
>

Looks good. I will modify as suggested.

Regards,

Christer

On 9/1/17 04:20, Christer Holmberg wrote:
>> realize that you proposed that text in email, but I somehow missed it 
>> at the time.)
>>
>> example by replacing ³MUST be² with ³should be², since we can¹t 
>> really make people update a specification,
>>
>>> double-checked the RFC6080 usage of Content-ID header field and we 
>>> believe that:
>>>
>>> The Content-ID header field above is NOT a *SIP* header field since 
>>> it is placed *after* CRLF.
>>>
>>> header field above is a MIME header field and is used by UAS to 
>>> determine whether the content fetched from 
>>> http://example.com/z100-000000000000.html has changed between UAC 
>>> sending the SIP NOTIFY message and UAS receiving the SIP NOTIFY 
>>> message.
>>>
>>>
>>> Regards,
>>>
>>> Christer