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

[Christer Holmberg <[e-mail]>]

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.

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


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.


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>


>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