Content-ID Header Field in the Session Initiation Protocol (SIP)
updates
Extracted elements (16)
Existing specifications such as RFC 5368 contained examples showing a SIP Content-ID header field referencing a complete message-body without normative language permitting it; many implementors acted on these examples anyway. This document retroactively legalizes and standardizes that de facto behavior.
Prior to this document, implementations were forced to wrap a single MIME entity in an unnecessary multipart message-body simply to attach a Content-ID for referencing (e.g., in INVITE with location, REFER with URI list). This document eliminates that overhead by allowing the SIP Content-ID header field to identify a non-multipart message-body directly.
RFC 5368 is updated so that the Refer-To header field in a REFER request with multiple REFER-Targets may point to either a body part or a complete message-body carrying the URI list, and either a MIME Content-ID header field (RFC 4483) or a SIP Content-ID header field (RFC 8262) may be used to label it.
RFC 5621 is updated so that a Content-ID URL may reference either a specific body part or a complete message-body (and the header fields describing the message-body), expanding beyond the previous body-part-only restriction.
RFC 6442 is updated to require that either a MIME Content-ID header field (RFC 4483) or the SIP Content-ID header field (RFC 8262) MUST be used to label the location information body part or message-body in a Geolocation conveyance.
A proxy MUST NOT add, modify, or delete a Content-ID header field in a SIP message. All three operations are explicitly prohibited.
A UA MAY include a Content-ID header field in any SIP message that is allowed to contain a message-body.
A UA MUST NOT include a Content-ID header field in any SIP message that is not allowed to contain a message-body.
A UA MUST set the value of the Content-ID header field to a value that is unique in the context of the SIP message, including any embedded MIME Content-ID header field values.
If an existing specification only defines usage of a multipart message-body to carry a single body part to be referenced by a Content-ID URL, implementations MUST NOT carry the MIME entity in a non-multipart message-body unless the specification is updated to explicitly allow it.
The Content-ID header field for SIP identifies the complete message-body of a SIP message and the metadata provided by MIME-Version and any 'Content-' prefixed header fields included in the SIP message. It can be included in any SIP message allowed to contain a message-body.
The Content-ID header field value has no meaning outside the message in which it is included; it is required to be unique only within the context of a given SIP message, not globally across all SIP messages.
RFC 8262 registers a new SIP header field 'Content-ID' (no compact form) in the 'Header Fields' sub-registry of the 'Session Initiation Protocol (SIP) Parameters' registry.
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.
The Content-ID header field value MUST NOT reveal sensitive user information, to prevent inadvertent disclosure through header inspection.
The Content-ID header field follows the ABNF: `Content-ID = "Content-ID" HCOLON msg-id` where `msg-id = "<" id-left "@" id-right ">"`. Comments are disallowed and leading white space follows SIP conventions, simplifying RFC 5322 syntax.