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

[Christer Holmberg <[e-mail]>]

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

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.