Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05

[Ben Campbell <[e-mail]>]

> On May 24, 2017, at 1:21 AM, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
> Discussion Points:
> 
>>>> - I have some difficulty seeing the difference between "the body and
>>>> related metadata" and "the SIP message". I realize you have the more 
>>>> MIME-specific header fields in mind when you say "metadata". But any 
>>>> SIP header field could be considered metadata.
>>> 
>>> (Christer) As metadata, we are only considering SIP header fields 
>>> that are also defined as MIME header fields.
>>> 
>>>> The main point of that question is, as used in MIME, Content-Id is
>>>> intended to label a body part. Message-Id is used to label the whole 
>>>> message. Aren't we talking about the whole message here?
>>> 
>>> (Christer) No.
>> 
>> We are borrowing this from the usage in email, where people usually 
>> consider _all_ the header fields as metadata, thus the usage of 
>> "Message-Id" rather than "Content-Id" when referring to the entire 
>> contents. I¹m not saying it¹s wrong to do it differently for SIP, but 
>> it would be good to include some motivation for that difference. I 
>> suspect the difference has to do with the purpose of email being to 
>> deliver the content, while for SIP the purpose of the content is to 
>> modify the handling of session initiation. In which case one might 
>> consider the content itself as ³metadata². (I¹m curious to hear if 
>> there are other
>> reasons.)
> 
> (Christer) I have to say that I am getting a little lost...
> 
> With a multipart body, each body part MIME can contain MIME header fields providing metadata for that specific body part.
> 
> With a non-multipart body, you can today do the same thing using MIME header fields that have been defined as SIP header field (Content-This, Content-That). However, Content-ID has not been defined as a SIP header field, and that is what we do in the draft. We are not adding new metadata, or extending the scope of the metadata - we simply allow using the same metadata to describe a non-multipart body as you can use to describe body parts in a multipart body.
> 
> If your issue is caused by usage of the term "metadata" without a formal definition, then we can define the term "metadata" as "a MIME-Version SIP header field and any 'Content-' prefixed SIP header field". Or, we can replace any occurrence of the term "metadata" with "a MIME-Version SIP header field and any 'Content-' prefixed SIP header field" in the draft.

My issue is not caused by the definition of the metadata in question (3.3 does a reasonable job of that.) It was more a question of why you chose to limit the metadata to that set, which somewhat goes against the way people think about email—and all of this comes from email. But I recognize that the way SIP uses bodies is different than the way email uses them. So let’s go with the thinking in the draft, and see if anyone objects in IETF LC (where I still hope to get a MIME expert review.)

(To be clear, that means no change needed due to this particular discussion point.)

> 
>>>> - Is there an expectation for the SIP Content-ID header field value 
>>>> to be referenced from outside the SIP message? If so, what are the 
>>>> uniqueness expectations? Note that for MIME, Content-ID is expected to 
>>>> be globally unique. Is that the case here?
>>> 
>>> (Christer) The draft does not change the uniqueness requirements of 
>>> Content-ID.
>>> 
>>>> If the Content-ID is _not_ expected to be referenced from outside of
>>>> the SIP message that contains it, then we have a sort of degenerate 
>>>> case where it always identifies _this_ message regardless of the 
>>>> value. Does that value ever need to change? Does that suggest >any 
>>>> guidance on how to construct values?
>>> 
>>> (Christer) RFC 5621 does not define the above characteristics for 
>>> multipart body usage, and I see no reason how anything would be 
>>> different for a non-multipart message body. If you think there is 
>>> something generic about Content-ID that needs to be clarified I think 
>>> that should be done as a separate task.  
>> 
>> 5261 used the Content-Id MIME header field. That field and it¹s 
>> uniqueness requirements are defined elsewhere. This draft defines a 
>> Content-ID sip header field. That didn¹t exist before. Therefore I 
>> think this needs to describe the uniqueness requirements.
>> 
>> 5322 requires msg-id to be globally unique because it¹s intended to be 
>> useful outside the context of the given message. Is that the case here?
>> If not, then a globally uniqueness requirement may not make sense in 
>> this context. (IIUC, every single instance of the Content-Id SIP header 
>> field could have the same, identical value, and things would work 
>> fine.)
> 
> (Christer) I have never heard about Content-ID being used outside the context of a given message, so I think the value only needs to be unique within a given message

Are you expecting to ever have both the SIP header field and one or more MIME Content-ID header fields in the same message? If so, then text to the effect of the following seems to make sense:

“The value of Content-Id header field value must be unique in the context of a given SIP message, including any imbedded MIME Content-Id header field values. Note that the SIP Content-ID header field value is not expected to be unique among all SIP messages; it has no meaning outside of the message in which it is included.” 

If, OTOH, you think there might ever be a need to reference a body from a different SIP message, then we would need it to be globally unique.



> 
> 
> Specific comments:
> 
>>>> 1.4 and children: These examples seem like fairly weak motivation,
>>>> since I assume in both cases one could still have just put a single 
>>>> body-part inside a multipart envelope. That
>>>> seems more an "inconvenience" than a "problem". Are there any known
>>>> use-cases where that would not be possible? (This is certainly not a 
>>>> show stopper; we are allowed to solve
>>>> inconveniences. But if there are any stronger motivations that could
>>>> be documented, they might save questions down the road.)
>>> 
>>> (Christer) I can't think of any use-cases where it would not be 
>>> possible to use a single-body inside a multipart envelope instead. So, 
>>> it is about "convenience".
>> 
>> The word "optimization" comes to mind.
> 
> (Christer) I guess that works too :)

Okay, no change needed.

> 
>>>> 3.2, 2nd note: How has the msg-Id been simplified, and why?
>>> 
>>> (Christer) The simplification was done based on a comment from Dale W.
>>> 
>>> https://www.ietf.org/mail-archive/web/sipcore/current/msg07862.html
>> 
>> I think it would be helpful to say something like ³Š simplified to 
>> disallow the use of comments and to adapt to SIP¹s use of leading white 
>> space."
> 
> (Christer) Ok, we¹ll add some text.

Thanks. If you can submit a version with that change, as well as some guidance on uniqueness as discussed above, I think it will be ready for IETF LC.

Thanks!

Ben.