Message Body Handling in the Session Initiation Protocol (SIP)
Extracted elements (28)
Extensions predating RFC 5621 use option-tags to ensure recipients understand the extension and thus cannot miss references to body parts. The 'by-reference' disposition type provides a declarative, extension-agnostic mechanism for the same protection.
In SIP, unlike in the original context for 'multipart/related', the disposition types of individual body parts within a 'multipart/related' play an important role and cannot be ignored. Different SIP extensions using the same top-level disposition type are distinguished by inner body part disposition types.
Only forward references are allowed so that recipients can process body parts as they parse them, without needing to parse the remainder of the message. It was considered to restrict references to within the same 'multipart/related' wrapper, but this extra constraint was deemed unnecessary.
SIP proxy servers are 8-bit safe and can handle binary bodies, so there is no need to use encodings such as base64 to transport binary bodies in SIP messages. This justifies mandating binary transfer encoding as the default.
Unknown 'multipart' subtypes are treated as 'multipart/mixed' by default. This fallback behavior means SIP extensions using novel multipart subtypes must use option-tags or other mechanisms to ensure recipients can process them correctly.
Because UACs receiving a response cannot report errors to the UAS (error responses can only be generated for requests), SIP extension authors must ensure requests clearly indicate UAC capabilities (e.g., via option-tags) so UASs can decide what to include in their responses.
Legacy SIP UAs without support for 'multipart' bodies generate a 415 (Unsupported Media Type) response when they receive a multipart body in a request. Some legacy UAs have been observed to silently ignore multipart bodies, causing serious interoperability problems.
UAs that do not understand 'multipart/related' will treat it as 'multipart/mixed', processing body parts independently by disposition type rather than as a compound object. Authors of SIP extensions using 'multipart/related' must account for this fallback behavior.
A recipient of a body part whose disposition type is 'by-reference' that cannot find any reference to the body part MUST NOT process the body part. If the handling was required, the UA must report an error.
For a 'multipart/alternative' body, the UA MUST set 'handling' to 'required' or 'optional' based on whether processing is required, and SHOULD set the 'handling' of all top-level body parts within to 'optional'. The UA MUST use the same disposition type for the 'multipart/alternative' body and all its top-level body parts.
For a 'multipart/mixed' body, the UA MUST set 'handling' to 'required' if processing the multipart body as a whole is required, otherwise MUST set it to 'optional'. The 'handling' parameters of top-level body parts within are set independently.
For the 'session' and 'early-session' disposition types, UAs MUST NOT place more than one body part with a given content type in a 'multipart/alternative' body, since these disposition types require all body parts to have different content types.
If a UAS cannot process a request because the content type or disposition type of a required-handling body part is not supported in the given context, the UAS SHOULD return a 415 (Unsupported Media Type) response even if it supports those types in a different context.
If a UAS receives a request with a body part whose disposition type is incompatible with how it is supposed to be handled according to other parts of the SIP message (e.g., a Refer-To Content-ID URL pointing to a body with disposition type 'session'), the UAS SHOULD return a 415 response.
SIP UAs MUST support parsing 'multipart' MIME bodies, including nested body parts. UAs MUST support the 'multipart/mixed' and 'multipart/alternative' MIME types. Support for other MIME types such as 'multipart/related' is OPTIONAL.
SIP UAs processing a 'multipart/related' body with a given disposition type MUST process the disposition types of the body parts within it according to the SIP extension making use of the disposition type of the 'multipart/related'. This differs from the base MIME spec.
The receiver of a 'multipart/alternative' body MUST process the body based on its 'handling' parameter and SHOULD ignore the 'handling' parameters of the individual body parts within the 'multipart/alternative'.
UAs MUST only include forward references in the SIP messages they generate. An element in a SIP message can reference a body part only if the body part appears after the element in the message.
UAs SHOULD assign 'multipart/mixed' bodies a disposition type of 'render', since a disposition type is required in order to set the 'handling' parameter. The actual disposition type of the whole 'multipart/mixed' is irrelevant to how the inner body parts are processed.
UAs SHOULD avoid unnecessarily nesting body parts. UAs SHOULD NOT nest one 'multipart/mixed' within another unless there is a need to reference the nested one using its Content-ID. Additionally, UAs SHOULD NOT nest one 'multipart/alternative' within another.
UAs SHOULD use the binary transfer encoding for all payloads in SIP, including binary payloads. The only exception is when transferring application data between applications that only handle a different encoding (e.g., base64).
If a SIP message contains a reference (e.g., a Content-ID URL) to a body part, the UA processes the body part according to the reference rather than its disposition type. If more than one reference to a body part exists, the UA processes the body part once per reference.
In a 'multipart/alternative' body, body parts are ordered so that the last one is the richest representation. The recipient chooses the last body part it understands. Each part within a 'multipart/alternative' represents the same data, but the mapping between parts may not be lossless.
The 'by-reference' disposition type indicates that the body part must be handled according to a reference located elsewhere in the same SIP message. It prevents a UA that missed a reference from attempting to process the body part by disposition type alone.
The 'handling' parameter of the Content-Disposition header field specifies how a UAS reacts if it receives a body part with an unrecognized content type or disposition type. The value 'optional' means ignore it; 'required' means return a 415 response. The default value is 'required'.
This document registers the 'by-reference' disposition type in the IANA Mail Content Disposition Values registry. A body with this disposition type needs to be handled according to a reference to the body located in the same SIP message.
This document updates the IANA Header Field Parameters and Parameter Values registry entry for the Content-Disposition 'handling' parameter, adding references to RFC 3204, RFC 3261, RFC 3459, and RFC 5621.
SIP message bodies can be end-to-end encrypted and integrity protected using S/MIME (RFC 3851), as described in RFC 3261. UASs that cannot decrypt a message body or body part can use the 493 (Undecipherable) response to report the error.