Content-ID Header Field in the Session Initiation Protocol (SIP)
draft-ietf-sipcore-content-id-10

Note: This ballot was opened for revision 07 and is now closed.

Ben Campbell Yes

Adam Roach Yes

Comment (2017-07-05 for -07)
I'm a little surprised that the document didn't end up with any text detailing the historical context for formally adding this mechanism.

I would expect to see some discussion explaining that the use of Content-ID as a SIP header field has been inferred as acceptable for years, and that so many IETF participants had taken it as given that Content-ID was *already* a registered SIP header field that it appears in examples in (for example) RFCs 5368 and 6080.

While I think the document would serve its intended purpose as-is, I believe that more explanatory text in the Introduction section to clarify that this is an attempt to formalize already-assumed (and likely deployed) behavior -- rather than simply casting it as a minor optimization -- would go a long way towards dealing with Eric's concerns.

Alia Atlas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2017-07-05 for -07)
Per the Gen-ART review, the references to RFC 5368 and RFC 6442 should be informative rather than normative.

Spencer Dawkins No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2017-07-05 for -07)
I'm following EKR's discuss on the interoperability / backward compatibility implications.

Mirja Kühlewind No Objection

Terry Manderson No Objection

Alexey Melnikov No Objection

Comment (2017-07-06 for -07)
I've checked whether this is consistent with email use and it seems to be.

Note that RFC 2392 says:

   The Content-ID of a MIME body part is required to be globally unique.

and this document only requires it to be unique within a message.

I don't think the difference in restrictions makes any real world difference, because I don't think applications enforce uniqueness of Content-IDs between different messages.

Eric Rescorla (was Discuss) No Objection

Comment (2017-07-05 for -07)
This document seems rather gratuitous to me. I agree it's somewhat of a misfeature not to be able to have Content-ID in the SIP headers, but as the examples in this document make clear, there's a straightforward workaround. It's unclear to me that there is actually sufficient benefit to this mechanism to publishing a standards track document with this change.

Alvaro Retana No Objection