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

From: Ben Campbell <[email-masked]>
Date: Tue, 16 May 2017 17:09:04 -0400

Hi,

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.

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?

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

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?

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

3.2, 2nd note: How has the msg-Id been simplified, and why?

3.4 and children: An example or two would be extremely helpful.

Editorial:

1.1, 3rd paragraph: Citation to RFC5621 is not a link in the PDF version.

1.2 and 1.3: A sentence or two that more strongly contrasts "body part" vs "message-body" would be helpful. I think that some people will think of a message-body as still a body-part.

1.5, Note: Seems like the note belongs in the problem statement more than the solution.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 May 2017 06:25:42 +0000

Hi Ben,

Thanks for your comments!

Ivo is currently attending a 3GPP meeting in China, so we’ll get back to you next week.

Thanks!

Regards,

Christer

From: Ben Campbell <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 17 May 2017 at 00:09
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AD Evaluation of draft-ietf-sipcore-content-id-05
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Ivo Sedlacek <[email-masked]<mailto:[email-masked]>>, "A. Mahoney" <[email-masked]<mailto:[email-masked]>>, Brian Rosen <[email-masked]<mailto:[email-masked]>>, Ben Campbell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "A. Mahoney" <[email-masked]<mailto:[email-masked]>>
Resent-Date: Wednesday 17 May 2017 at 00:13

Hi,

Thanks!

Ben.

Discussion Points:

Specific comments:

Editorial:

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 May 2017 11:18:50 +0000

Hi Ben,

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

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

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

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

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

>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

>3.4 and children: An example or two would be extremely helpful.

(Christer) We can do that.

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

>1.2 and 1.3: A sentence or two that more strongly contrasts "body part" vs "message-body" would be helpful. I think that some people will think of a message-body as still a body-part.

(Christer) We’ll work on some clarification text.

>1.5, Note: Seems like the note belongs in the problem statement more than the solution.

(Christer) We can move it there.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Mon, 22 May 2017 13:59:26 -0500

Thanks for the response. Comments inline:

Thanks!

Ben.

> On May 22, 2017, at 6:18 AM, Christer Holmberg <[email-masked]> wrote:
> 
> 
> Hi Ben,
>  

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) 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 s…

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

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

Thanks!

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 May 2017 06:21:40 +0000

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

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

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

Editorial:
  
>>(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.

(Christer) Ok.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 May 2017 15:49:50 -0500

> On May 24, 2017, at 1:21 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> Discussion Points:
> 

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

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

> (Christer) I guess that works too :)

Okay, no change needed.

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 May 2017 10:16:54 +0000

Hi,

…

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

I don’t have a use-case at the moment, but I don’t think we should
disallow it.

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

Looks good.

s/imbedded/embedded

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

IF someone ever comes up with such use-case, we can deal with it.

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

I should have something ready no later than Monday.

Regards,

Christer