RFC 5621

Message Body Handling in the Session Initiation Protocol (SIP)

📅 published September 2009, from ietf

Message Body Handling in the Session Initiation Protocol (SIP) 🎀

Okay bestie, this is RFC 5621 💖, a Standards Track doc from the Network Working Group (RFC number 5621, so it's a Request for Comments). It was written by G. Camarillo at Ericsson and dropped in September 2009 🌸. It doesn't obsolete anything, but it updates RFCs 3204, 3261, and 3459, so those older specs get some extra context from this one ✨.

Abstract

Here's the vibe in one breath 🫶. This document is all about how message bodies get handled in SIP. It also adds SIP user agent support for MIME (Multipurpose Internet Mail Extensions) inside those message bodies 💅.

Status of This Memo

This is an Internet standards track protocol for the Internet community, and the authors are asking for discussion and suggestions for improvements 🔥. If you want to know where the protocol stands in terms of standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were in effect on the date of publication. The license info lives at http://trustee.ietf.org/license-info 🙈. Please actually read those documents, because they spell out your rights and restrictions for this doc 😭.

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Message Body Encoding  . . . . . . . . . . . . . . . . . . . .  3
  3.1.  Background on Message Body Encoding  . . . . . . . . . . .  3
  3.2.  UA Behavior to Encode Binary Message Bodies  . . . . . . .  5
4.  'multipart' Message Bodies . . . . . . . . . . . . . . . . . .  6
  4.1.  Background on 'multipart' Message Bodies . . . . . . . . .  6
  4.2.  Mandatory Support for 'multipart' Message Bodies . . . . .  7
  4.3.  UA Behavior to Generate 'multipart' Message Bodies . . . .  7
5.  'multipart/mixed' Message Bodies . . . . . . . . . . . . . . .  7
6.  'multipart/alternative' Message Bodies . . . . . . . . . . . .  8
  6.1.  Background on 'multipart/alternative' Message Bodies . . .  8
  6.2.  UA Behavior to Generate 'multipart/alternative'
        Message Bodies . . . . . . . . . . . . . . . . . . . . . .  8
  6.3.  UA Behavior to Process 'multipart/alternative' Message
        Bodies . . . . . . . . . . . . . . . . . . . . . . . . . .  9
7.  'multipart/related' Message Bodies . . . . . . . . . . . . . .  9
  7.1.  Background on 'multipart/related' Message Bodies . . . . .  9
  7.2.  UA Behavior to Generate 'multipart/related' Message
        Bodies . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  7.3.  UA Behavior to Process 'multipart/related' Message
        Bodies . . . . . . . . . . . . . . . . . . . . . . . . . .  9
8.  Disposition Types  . . . . . . . . . . . . . . . . . . . . . . 10
  8.1.  Background on Content and Disposition Types in SIP . . . . 10
  8.2.  UA Behavior to Set the 'handling' Parameter  . . . . . . . 12
  8.3.  UA Behavior to Process 'multipart/alternative' . . . . . . 13
  8.4.  UAS Behavior to Report Unsupported Message Bodies  . . . . 13
9.  Message Body Processing  . . . . . . . . . . . . . . . . . . . 14
  9.1.  Background on References to Message Body Parts . . . . . . 14
  9.2.  UA Behavior to Generate References to Message Bodies . . . 14
  9.3.  UA Behavior to Process Message Bodies  . . . . . . . . . . 14
  9.4.  The 'by-reference' Disposition Type  . . . . . . . . . . . 15
10. Guidelines to Authors of SIP Extensions  . . . . . . . . . . . 16
11. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
  12.1. Registration of the 'by-reference' Disposition Type  . . . 17
  12.2. Update of the 'handling' Parameter Registration  . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
  14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
  14.2. Informative References . . . . . . . . . . . . . . . . . . 18

1. Introduction ✨

Okay so message body handling in SIP was first specified in [RFC3261] 💅, which leaned on earlier specs (MIME, for example) to cover some areas. This document has two parts 🧚. There's background material explaining how bodies get handled in SIP, and there's normative material for areas that weren't specified before or that needed finishing. The background sections are clearly labelled by their titles, so you can't miss them 🎀. The normative material is based on experience gained since [RFC3261] was written 🔥. Implementers need to implement what [RFC3261] specifies (and its references) in addition to what this document specifies, so don't skip the homework bestie 📚.

2. Terminology 🌈

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜.

Here are the abbreviations this doc uses 🍓:

UA: User Agent

UAC: User Agent Client

UAS: User Agent Server

URL: Uniform Resource Locator

3. Message Body Encoding 🦋

This section is all about how message bodies get encoded in SIP 💖.

3.1. Background on Message Body Encoding

Quick recap: SIP [RFC3261] messages are made of an initial line (a request line in requests, a status line in responses), a set of header fields, and an optional message body 🫶. The body gets described with header fields like Content-Disposition, Content-Encoding, and Content-Type, which tell you what's inside 👀. Figure 1 shows a SIP message carrying a body. Some of the header fields are left out to keep it simple 🌸:

INVITE sip:conf-fact@example.com SIP/2.0
Content-Type: application/sdp
Content-Length: 192

v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000

Figure 1: SIP message carrying a body

The message body of a SIP message can be split into different body parts 🧁. Multipart message bodies are encoded with the MIME (Multipurpose Internet Mail Extensions) [RFC2045] format 💫. Body parts get described with header fields like Content-Disposition, Content-Encoding, and Content-Type too, and those tell you about the contents of one particular body part 🍓. Figure 2 shows a SIP message carrying two body parts. Again, some header fields are hidden for simplicity 🙈:

INVITE sip:conf-fact@example.com SIP/2.0
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 619

--boundary1
Content-Type: application/sdp

v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000

--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
  <list>
    <entry uri="sip:bill@example.com"/>
    <entry uri="sip:randy@example.net"/>
    <entry uri="sip:joe@example.org"/>
  </list>
</resource-lists>
--boundary1--

Figure 2: SIP message carrying a body

SIP uses S/MIME [RFC3851] to protect message bodies 🔐. As [RFC3261] specifies, UASs that can't decrypt a message body or a body part can send the 493 (Undecipherable) response to report the error 😭.

3.2. UA Behavior to Encode Binary Message Bodies

SIP messages can carry binary message bodies, like legacy signalling objects [RFC3204] 💾. SIP proxy servers are 8-bit safe, meaning they can handle binary bodies 💪. So there's no need to use encodings like base64 to transport binary bodies in SIP messages 🙌. Consequently, UAs SHOULD use the binary transfer encoding [RFC4289] for all payloads in SIP, including binary payloads ✨. The only case where a UA MAY use a different encoding is when transferring application data between applications that only handle a different encoding (e.g., base64) 🎀.

4. 'multipart' Message Bodies 💜

This section deals with 'multipart' message bodies and how they're handled 🧚.

4.1. Background on 'multipart' Message Bodies

Okay, the tea ☕: [RFC3261] did not mandate support for 'multipart' message bodies in MIME format [RFC2046]. But since [RFC3261] was written, a bunch of SIP extensions rely on them 🌈.

'multipart/mixed' MIME bodies are a super useful tool for building SIP extensions 🛠️. An example could be including location information in an INVITE request 📍. That INVITE would use the 'multipart/mixed' MIME type [RFC2046] to carry two body parts: a session description and a location object 💅. An existing extension that uses 'multipart/mixed' to send a session description and a legacy-signalling object is defined in [RFC3204] 🦋.

'multipart/alternative' [RFC2046] is another MIME type that's useful for building SIP extensions 🫶. Each body part inside a 'multipart/alternative' carries an alternative version of the same information 🍓.

The move from SDP to newer session description protocols could be done with 'multipart/alternative' bodies 🔥. SIP messages (INVITE requests, for example) could carry a 'multipart/alternative' body with two body parts: a session description written in SDP, and a session description written in a newer format 💖. Legacy recipient UAs would use the SDP one, and new recipient UAs would use the one in the newer format 👑.

Nested MIME bodies are yet another tool for building and combining SIP extensions 🧁. Using the extensions from the previous examples, a UA that supports a new session description format and needs to include a location object in an INVITE request would include a 'multipart/mixed' body with two body parts: a location object and a 'multipart/alternative' 🌸. That 'multipart/alternative' body part would, in turn, have two body parts: a session description written in SDP and a session description written in the newer format 💫.

4.2. Mandatory Support for 'multipart' Message Bodies

okay so for any MIME-based extension to actually work, the recipient has to be able to decode the multipart bodies 💅 That's why SIP UAs MUST support parsing 'multipart' MIME bodies, including nested body parts. On top of that, UAs MUST support the 'multipart/mixed' and 'multipart/alternative' MIME types. Support for other MIME types, like 'multipart/related', is OPTIONAL 🎀

Note that, by default, unknown 'multipart' subtypes are treated as 'multipart/mixed' 👀 Also, SIP extensions can put 'multipart' MIME bodies in responses too, which is why both UACs and UASs need to support 'multipart' bodies 🫶

Legacy SIP UAs without 'multipart' support generate a 415 (Unsupported Media Type) response when they get a 'multipart' body in a request. So a UAC sending a 'multipart' body can get that error when it's talking to a legacy SIP UA that predates this spec 😭

It has been observed in the field that a bunch of legacy SIP UAs without 'multipart' support just ignored those bodies when they showed up, and didn't return any error response at all. Unsurprisingly, SIP UAs that can't report this type of error have caused serious interoperability problems in the past 💀

4.3. UA Behavior to Generate 'multipart' Message Bodies

UAs SHOULD avoid unnecessarily nesting body parts, because doing so would make processing the body more laborious for the receiver 🥴 However, [RFC2046] says a 'multipart' media type with a single body part is useful in some circumstances (e.g., for sending non-text media types). In any case, UAs SHOULD NOT nest one 'multipart/mixed' within another unless there is a need to reference the nested one (i.e., using the Content ID of the nested body part). Additionally, UAs SHOULD NOT nest one 'multipart/alternative' within another 🙅‍♀️

Note that UAs receiving unnecessarily nested body parts treat them as if they were not nested ✨

5. 'multipart/mixed' Message Bodies

This section doesn't specify any additional behavior for generating or processing 'multipart/mixed' bodies. It's just here for completeness 🌸

6. 'multipart/alternative' Message Bodies

This section is all about 'multipart/alternative' message bodies and how they get handled 🦋

6.1. Background on 'multipart/alternative' Message Bodies

Each body part in a 'multipart/alternative' carries an alternative version of the same information. The body parts are ordered so that the last one is the richest representation of the information. The recipient of a 'multipart/alternative' body chooses the last body part it understands 👑

Note that within a body part encoded in a given format (i.e., of a given content type), there can be optional elements that give richer information to the recipient if it supports them. For example, in SDP (Session Description Protocol) [RFC4566], those optional elements are encoded in 'a' lines. These types of optional elements are internal to a body part and aren't visible at the MIME level. In other words, a body part is understood if the recipient understands its content type, regardless of whether or not it understands the body part's optional elements 🧚

Note as well that each part of a 'multipart/alternative' body represents the same data, but the mapping between any two parts isn't necessarily lossless. For example, information can be lost when translating 'text/html' to 'text/plain'. [RFC2046] recommends that each part have a different Content-ID value in the case where the information content of the two parts is not identical 🤓

6.2. UA Behavior to Generate 'multipart/alternative' Message Bodies

Section 8.2 mandates that all the top-level body parts within a 'multipart/alternative' have the same disposition type 📌

The 'session' and 'early-session' [RFC3959] disposition types require that all the body parts of a 'multipart/alternative' body have different content types. So, 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. In other words, for 'session' and 'early-session', no body part within a 'multipart/alternative' can have the same content type as another body part in that same 'multipart/alternative' 🚫

6.3. UA Behavior to Process 'multipart/alternative' Message Bodies

This section doesn't specify any additional behavior for processing 'multipart/alternative' bodies. It's just here for completeness 💖

This section is all about 'multipart/related' message bodies and how they get handled 🌈

Compound objects in MIME are represented using the 'multipart/related' content type [RFC2387]. The body parts within a particular 'multipart/related' body are all part of one compound object and get processed that way. The body part within a 'multipart/related' body that needs to be processed first is called the 'root' body part. The root body part is identified by the 'start' parameter, which is a Content-Type header field parameter and contains a Content-ID URL pointing to the root body part. If the start parameter isn't present, the root body part is, by default, the first body part of the 'multipart/related' 🧩

An example of a compound object is a web page that contains images. The html body part would be the root, and the remaining body parts would contain the images. An example of a SIP extension using 'multipart/related' is specified in [RFC4662] ✨

This section doesn't specify any additional behavior for generating 'multipart/related' bodies. It's just here for completeness 🫠

Per [RFC2387], a UA processing a 'multipart/related' body treats the body as a compound object and ignores the disposition types of the body parts inside it. That makes total sense for the context where 'multipart/related' was originally specified. Take the web page example: the implicit disposition type for the images would be 'inline', since the images get displayed as the root html file indicates 🖼️

BUT in SIP, the disposition types of the individual body parts inside a 'multipart/related' play an important role, so they need to be considered by the UA processing it 😤 Different SIP extensions that use the same disposition type for the 'multipart/related' body can be told apart by the disposition types of the individual body parts inside it. So 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 the disposition type of the 'multipart/related' 💅

Note that UAs that don't understand 'multipart/related' will treat 'multipart/related' bodies as 'multipart/mixed' bodies. These UAs won't be able to process a given body as a compound object. Instead, they'll process the body parts according to their disposition type, as if each body part were independent from each other 🥹

8. Disposition Types

This section is all about disposition types in message bodies 🎀

8.1. Background on Content and Disposition Types in SIP

The Content-Disposition header field, defined in [RFC2183] and extended by [RFC3261], describes how to handle a SIP message's body or an individual body part. Examples of disposition types used in SIP in the Content-Disposition header field are 'session' and 'render' 📬

[RFC3204] and [RFC3459] define the 'handling' parameter for the Content-Disposition header field. This parameter describes how a UAS reacts if it receives a message body whose content type or disposition type it doesn't understand. If the parameter has the value 'optional', the UAS ignores the message body. If the parameter has the value 'required', the UAS returns a 415 (Unsupported Media Type) response. The default value for the 'handling' parameter is 'required'. Here's an example of a Content-Disposition header field:

Content-Disposition: signal; handling=optional

[RFC3204] identifies two situations where a UAS (User Agent Server) needs to reject a request with a body part whose handling is required 🙅‍♀️

if it has an unknown content type.
if it has an unknown disposition type.

If the UAS didn't understand the content type of the body part, the UAS can add an Accept header field to its 415 (Unsupported Media Type) response, listing the content types that it does understand. Still, there's no mechanism for a UAS that doesn't understand the disposition type of a body part to tell the UAC which disposition type it didn't understand, or which disposition types the UAS does understand 😩

The reason there's no such mechanism is that disposition types are typically supported within a context. Outside that context, a UA doesn't need to support the disposition type. For example, a UA can support the 'session' disposition type for body parts in INVITE and UPDATE requests and their responses. But that same UA wouldn't support the 'session' disposition type in MESSAGE requests 🫣

In another example, a UA can support the 'render' disposition type for 'text/plain' and 'text/html' body parts in MESSAGE requests. The UA can also support the 'session' disposition type for 'application/sdp' body parts in INVITE and UPDATE requests and their responses. However, the UA might not support the 'render' disposition type for 'application/sdp' body parts in MESSAGE requests, even if, in different contexts, it supported all of the following: the 'render' disposition type, the 'application/sdp' content type, and the MESSAGE method 🤯

A given context is generally (but not necessarily) defined by a method, a disposition type, and a content type. Support for a specific context is usually defined within an extension. For example, the extension for instant messaging in SIP [RFC3428] mandates support for the MESSAGE method, the 'render' disposition type, and the 'text/plain' content type 💬

Note that, effectively, content types are also supported within a context. So the use of the Accept header field in a 415 (Unsupported Media Type) response isn't enough to describe in which contexts a particular content type is supported 🧐

Therefore, support for a particular disposition type within a given context is typically signalled by the use of a particular method or an option-tag in a Supported or a Require header field. When support for a particular disposition type within a context is mandated, support for a default content type is also mandated (e.g., a UA that supports the 'session' disposition type in an INVITE request needs to support the 'application/sdp' content type) 🌷

8.2. UA Behavior to Set the 'handling' Parameter 🎀

okay so bestie, handling can only be required or optional 💅 picking one for a single body part is usually easy, but setting it on multipart bodies is giving extra homework ✨

If the handling of a multipart/mixed body as a whole is required for processing its enclosing body part or message, the UA MUST set the handling parameter of the multipart/mixed body to required. Otherwise, the UA MUST set it to optional. The handling parameters of the top-level body parts inside the multipart/mixed body are set independently from the handling parameter of the multipart/mixed body itself 🧚 If the handling of a particular top-level body part is required, the UA MUST set that body part's handling parameter to required. Otherwise, the UA MUST set it to optional.

Per the previous rules, a multipart/mixed body whose handling is optional can contain body parts whose handling is required. In that case, the receiver is required to process the body parts whose handling is required if and only if the receiver decides to process the optional multipart/mixed body. 🙈

Also per the previous rules, a multipart/mixed body whose handling is required can contain only body parts whose handling is optional. In that case, the receiver is required to process the body as a whole, but while processing it, the receiver may decide (based on its local policy) not to process any of the body parts. 💀

The handling parameter is a Content-Disposition parameter, so to set it, the multipart/mixed body needs a disposition type first 🎀 Per [RFC3261], the default disposition type is session for application/sdp and render for everything else. UAs SHOULD assign multipart/mixed bodies a disposition type of render.

Quick reality check: just because multipart/mixed bodies default to render doesn't mean anything gets rendered to the user 😭 How the body parts inside get handled depends on their own disposition types. The disposition type of the whole multipart/mixed is irrelevant. render was picked only because it's the default disposition type in SIP 🌸

If the handling of a multipart/alternative body as a whole is required for processing its enclosing body part or message, the UA MUST set the handling parameter of the multipart/alternative body to required. Otherwise, the UA MUST set it to optional. The UA SHOULD also set the handling parameter of all the top-level body parts within the multipart/alternative to optional.

The receiver processes the body parts based on the handling parameter of the multipart/alternative body, and it ignores the handling parameters of the body parts. That's why setting them to optional sits at the "SHOULD" level and not the "MUST" level. Their value is irrelevant 🦋

The UA MUST use the same disposition type for the multipart/alternative body and all of its top-level body parts. 🫶

If the handling of a multipart/related body as a whole is required for processing its enclosing body part or message, the UA MUST set the handling parameter of the multipart/related body to required. Otherwise, the UA MUST set it to optional. The handling parameters of the top-level body parts inside the multipart/related body are set independently from the handling parameter of the multipart/related body. If the handling of a particular top-level body part is required, the UA MUST set that body part's handling parameter to required. Otherwise, the UA MUST set it to optional. If at least one top-level body part within a multipart/related body has a handling parameter of required, the UA SHOULD set the handling parameter of the root body part to required. 👑

8.3. UA Behavior to Process 'multipart/alternative' 🌈

The receiver of a multipart/alternative body MUST process the body based on its handling parameter. The receiver SHOULD ignore the handling parameters of the body parts within the multipart/alternative. ✨

8.4. UAS Behavior to Report Unsupported Message Bodies 🚫

If a UAS cannot process a request because, in the given context, it doesn't support the content type or the disposition type of a body part whose handling is required, the UAS SHOULD return a 415 (Unsupported Media Type) response. This applies even if the UAS supported that content type, that disposition type, or both in a different context. 😤

So it's possible to get a 415 (Unsupported Media Type) response with an Accept header field that lists every content type used in the request. Yes, really 💀

If a UAS receives a request with a body part whose disposition type isn't compatible with how that body part is supposed to be handled according to other parts of the SIP message, the UAS SHOULD return a 415 (Unsupported Media Type) response. For example, a Refer-To header field with a Content-ID URL pointing to a body part whose disposition type is session would count 🙅‍♀️

9. Message Body Processing 🍓

This section is all about processing message bodies, and how that processing changes depending on whether something references them 💜

9.1. Background on References to Message Body Parts 🧠

Content-ID URLs let you create references to body parts 🔗 A given Content-ID URL [RFC2392], which can show up in a header field or inside a body part (for example, in an SDP attribute), points to one particular body part. How that body part gets handled is defined by the field the Content-ID URL appears in. For instance, the extension for referring to multiple resources in SIP [RFC5368] puts a Content-ID URL in a Refer-To header field, and that URL points to a body part carrying a URI list. Another example: the extension for file transfer in SDP [RFC5547] puts a Content-ID URL in a file-icon SDP attribute, and that URL points to a body part carrying a (typically small) picture 📸

9.2. UA Behavior to Generate References to Message Bodies 🎀

UAs MUST only include forward references in the SIP messages they generate. In other words, an element in a SIP message can reference a body part only if that body part appears after the element. So a given body part can only be referenced by another body part that comes before it, or by a header field. Forward-only references mean recipients can process body parts as they parse them. They don't have to parse the rest of the message first 🏃‍♀️💨

It was considered to only allow (forward) references among body parts that belonged to the same multipart/related [RFC2387] wrapper. It was finally decided that this extra constraint wasn't necessary 🙃

9.3. UA Behavior to Process Message Bodies 🔍

To process a message body or body part, a UA needs to know whether a SIP header field or another body part references it (for example, a Content-ID URL pointing to it). If nothing references the body part (no header fields or other body parts have a Content-ID URL pointing to it), the UA processes the body part as indicated by its disposition type and the context it was received in 🌸

If the SIP message does contain a reference to the body part, the UA processes the body part according to that reference. If the SIP message contains more than one reference to the body part (for example, two header fields both contain Content-ID URLs pointing to it), the UA processes the body part once for each reference 🔁

Note that, following the rules in [RFC3204], if a UA doesn't understand a body part whose handling is optional, the UA ignores it 🫶 Also, the content indirection mechanism in SIP [RFC4483] lets UAs point to external bodies. So a UA receiving a SIP message that uses content indirection might need to fetch a body part (for example, using HTTP [RFC2616]) before it can process it 🌐

9.4. The 'by-reference' Disposition Type 🦋

Per the rules in Section 9.3, if a SIP message contains a reference to a body part, the UA processes the body part according to that reference. Because the reference gives the context the body part needs to be processed in, the body part's disposition type is irrelevant. But a UA that missed a reference to a body part (for example, because the reference was in a header field the UA didn't support) would try to process the body part based on its disposition type alone. To stop that from happening, we define a new disposition type for the Content-Disposition header field: by-reference 🚨

A body part whose disposition type is by-reference needs to be handled according to a reference to it that appears in the same SIP message (and since SIP only allows forward references, that reference will show up in the same message before the body part). A recipient of a body part whose disposition type is by-reference that can't find any reference to it (for example, the reference was in a header field the recipient doesn't support and so didn't process) MUST NOT process the body part. So if the handling of that body part was required, the UA needs to report an error 🥺

Note that extensions that predate this specification use references to body parts whose disposition type is not by-reference. Those extensions use option-tags to make sure the recipient understands the whole extension, so the recipient can't miss the reference and try to process the body part based on its disposition type alone 🧚

10. Guidelines to Authors of SIP Extensions ✨

okay bestie, this part is for anyone writing a SIP extension that touches message bodies or body parts 🎀 these are the things you need to think about before you ship your design 💅

This spec makes support for 'multipart/mixed' and 'multipart/alternative' mandatory. Right now, no SIP extensions use other 'multipart' subtypes like parallel [RFC2046] or digest [RFC2046]. If someone defines one later, they need to make sure (for example, with an option-tag or some other way) that receivers can actually process it 🦋 And like we said earlier, UAs treat unknown 'multipart' subtypes as 'multipart/mixed' 🧚

Extension authors who use 'multipart/related' bodies have to deal with the disposition types of the body parts inside the 'multipart/related' body, explicitly, no skipping 💀 Also keep in mind that UAs which don't understand 'multipart/related' will treat it as 'multipart/mixed'. If that's not acceptable for your extension, you need to make sure (again, an option-tag or another method works) that receivers of the 'multipart/related' body can process it correctly 🌸

As we covered, SIP extensions can put 'multipart' MIME bodies in responses too. So a response can get super complicated, and the UAC that receives it might not be able to handle it 😭 UACs can't report errors back to the UAS that made the response, since error responses only exist for requests. So extension authors need requests to clearly say what the UAC can do (for example, with an option-tag or another way) so the UAS knows what to put in its responses 🫶

11. Security Considerations 🔥

This doc is all about how SIP entities handle message bodies. [RFC3261] covers what kind of info goes inside SIP message bodies and how SIP entities can protect it. On top of the hop-by-hop security SIP offers, SIP can also secure information end-to-end. SIP message bodies can be end-to-end encrypted and integrity protected using S/MIME [RFC3851], as described in [RFC3261] 🔐 this part is seriously important, bestie, so please don't skip it 💜

12. IANA Considerations 👑

This doc has two actions that IANA has already completed 🌈

12.1. Registration of the 'by-reference' Disposition Type

This doc defines a new Content-Disposition header field disposition type (by-reference) Section 9.4. The value has been registered in the IANA registry for Mail Content Disposition Values, with this description:

      by-reference    The body needs to be handled according to a
                      reference to the body that is located in
                      the same SIP message as the body.

12.2. Update of the 'handling' Parameter Registration

References to this spec, to [RFC3204], and to [RFC3459] got added to the entry for the Content-Disposition 'handling' parameter in the Header Field Parameters and Parameter Values registry. Here's the resulting entry 🍓

                                      Predefined
Header Field         Parameter Name     Values       Reference
-------------------  ---------------  ---------  -------------------
Content-Disposition     handling         Yes     [RFC3204] [RFC3261]
                                                 [RFC3459] [RFC5621]

13. Acknowledgements 🦋

The ideas in this doc were first discussed with Paul Kyzivat 🫶 Christer Holmberg, Francois Audet, Dan Wing, Adam Roach, Keith Drage, and Dale Worley all gave comments. Dave Crocker did a thorough review of the whole document, which is so iconic of him 🌟

14. References ✨

14.1. Normative References

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 📚
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 📚
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. 📚
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. 📚
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. 📚
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. 📚
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📚
[RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003. 📚
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 📚
[RFC3959] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004. 📚
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 📚

14.2. Informative References

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 🌸
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. 🌸
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005. 🌸
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 🌸
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006. 🌸
[RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., and H. Khartabil, "Referring to Multiple Resources in the Session Initiation Protocol (SIP)", RFC 5368, October 2008. 🌸
[RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", RFC 5547, May 2009. 🌸

Author's Address 💖

Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Gonzalo.Camarillo@ericsson.com

📦 where this page comes from

ietf: rfc5621 2009-09
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms