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

[Ben Campbell <[e-mail]>]

Thanks for the response. Comments inline:

Thanks!

Ben.

> On May 22, 2017, at 6:18 AM, Christer Holmberg <[e-mail]> wrote:
> 
> 
> Hi Ben,
>  
> >This is my AD evaluation of draft-ietf-sipcore-content-id-05. I have some points I would like discuss before going to IETF last call.
> > 
> >Note: I plan to request an Art-Art review on this draft to focus on the MIME usage aspects.
> > 
> >Thanks!
> > 
> >Ben.
> > 
>  
> 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.)


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


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

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

>  
>  
> >3.4 and children: An example or two would be extremely helpful.
>  
> (Christer) We can do that.

Thanks!

>  
>  
> Editorial:
>  
> >1.1, 3rd paragraph: Citation to RFC5621 is not a link in the PDF version.
>  
> (Christer) That’s strange. I checked the XML file, and everything seems correct. Could the fact that the sentence starts with the reference have anything to do with it?
>  
> <t><xref target="RFC5621" pageno="false" format="default"/> defines generic handling of a multipart message-body in a SIP message.</t>

I don’t know, it may be an xml2rfc bug. If there’s no error in the xml, then we could leave this to the RFC editor.

[I removed the rest of the editorial section, since all my responses would be “Okay”]