I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. What this RFC does is define a syntax that allows a part of a SIP message to refer to another part of the SIP message. This was previously possible only if the referred-to-part was a body part and this spec generalizes that to allow references to an entire body. It is very difficult to read this by itself, even though it is very short. I'd think it would be better to just make this minor modification to the base RFC. And if we want to have these tiny RFCs, I understand that it's unusual for someone to just read one rather than the whole group...it's really the case of a SECDIR person being assigned a specific RFC that might not be caught up on all the jargon for that WG. However, I think each RFC should be understandable. There ought to be a "context", that includes what other RFCs should be read first, and in particular, either an acronym dictionary or a pointer to an RFC that has explanations for all the acronyms in the little RFC. I found one technical point that seems like an important inconsistency: Section 3.2 says the Content-ID header field must be unique in the context of a given SIP message, while section 3.4.1 says it must be globally unique. The difference is important; globally unique is hard and ugly. I hope that section 3.4.1 is wrong. More examples - with annotations - would be helpful, as would an explanation of how people work around this limitation today. Perhaps also an explanation understandable to an ordinary human as to what problem they are trying to solve and the context in which that problem comes up. Perhaps also worth asking is how the sender of a SIP message is supposed to know whether the recipient of the SIP message can handle this new syntax, and perhaps what it would do if it couldn’t. I suspect they have a good answer to these questions, but they would be worth stating. The security considerations section says "The Content-ID header field value MUST NOT reveal sensitive user information. If the message-body associated with the Content-ID header field is an encrypted body, it MUST NOT be possible to derive a key that can be used to decrypt the body from the Content-ID header field value." It seems to me that that text should be in the body of the RFC, because it is specifying what must be done, rather than what I usually think of for security considerations, which would say "if you didn't do what we said in section XXX, the following bad things could happen." But as long as people read the security considerations section, it's OK. Radia