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

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Aug 2017 11:34:35 +0000

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]<mailto:[email-masked]>
       ;tag=abca
To: sip:[email-masked]<mailto:[email-masked]>
     ;tag=1234
Call-ID: [email-masked]<mailto:[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]<mailto:[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: Thu, 31 Aug 2017 11:46:53 -0500

> - RFC6080 does NOT need to use the *SIP* Content-ID header.

Thanks. Your analysis looks correct to me.

/a

---

From: Ben Campbell <[email-masked]>
Date: Thu, 31 Aug 2017 16:27:37 -0500

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,
> 
> From: sip:[email-masked]
>        ;tag=abca
> To: sip:[email-masked]
>      ;tag=1234
> Call-ID: [email-masked]
> CSeq: 322 NOTIFY
> Content-ID: <[email-masked]>
> ---------------
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Sep 2017 05:59:44 +0000

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.)

Don¹t worry - some of the text suggested on the list has been slightly
modified, based on input from Ivo etc :)

>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,
>
>   to explicitly allow it.²

Works for me.

Regards,

Christer

>> 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