idnits 2.17.1 draft-ietf-sip-body-handling-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC3204, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3459, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3204, updated by this document, for RFC5378 checks: 2000-01-28) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5527 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 758, but not defined ** Obsolete normative reference: RFC 3850 (Obsoleted by RFC 5750) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Updates: 3261, 3204, 3459 March 9, 2009 5 (if approved) 6 Intended status: Standards Track 7 Expires: September 10, 2009 9 Message Body Handling in the Session Initiation Protocol (SIP) 10 draft-ietf-sip-body-handling-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 10, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document specifies how message bodies are handled in SIP. 50 Additionally, this document specifies SIP user agent support for MIME 51 (Multipurpose Internet Mail Extensions) in message bodies. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Message Body Encoding . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Background on Message Body Encoding . . . . . . . . . . . 3 59 3.2. UA Behavior to Encode Binary Message Bodies . . . . . . . 5 60 4. Multipart Message Bodies . . . . . . . . . . . . . . . . . . . 6 61 4.1. Background on 'multipart' Message Bodies . . . . . . . . . 6 62 4.2. Mandatory Support for 'multipart' Message Bodies . . . . . 6 63 4.3. UA Behavior to Generate 'multipart' Message Bodies . . . . 7 64 5. Multipart/mixed Message Bodies . . . . . . . . . . . . . . . . 7 65 6. Multipart/alternative Message Bodies . . . . . . . . . . . . . 8 66 6.1. Background on 'multipart/alternative' Message Bodies . . . 8 67 6.2. UA Behavior to Generate 'multipart/alternative' 68 Message Bodies . . . . . . . . . . . . . . . . . . . . . . 8 69 6.3. UA Behavior to Process 'multipart/alternative' Message 70 Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7. Multipart/related Message Bodies . . . . . . . . . . . . . . . 9 72 7.1. Background on 'multipart/related' Message Bodies . . . . . 9 73 7.2. UA Behavior to Generate 'multipart/related' Message 74 Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.3. UA Behavior to Process 'multipart/related' Message 76 Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Background on Content and Disposition Types in SIP . . . . 10 79 8.2. UA Behavior to Set the 'handling' Parameter . . . . . . . 11 80 8.3. UA Behavior to Process 'multipart/alternative' . . . . . . 13 81 8.4. UAS Behavior to Report Unsupported Message Bodies . . . . 13 82 9. Message Body Processing . . . . . . . . . . . . . . . . . . . 14 83 9.1. Background on References to Message Body Parts . . . . . . 14 84 9.2. UA Behavior to Generate References to Message Bodies . . . 14 85 9.3. UA Behavior to Process Message Bodies . . . . . . . . . . 14 86 9.4. The 'by-reference' Disposition Type . . . . . . . . . . . 15 87 10. Guidelines to Authors of SIP Extensions . . . . . . . . . . . 16 88 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 90 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 13.1. Registration of the 'by-reference' Disposition Type . . . 17 92 13.2. Update of the 'handling' Parameter Registration . . . . . 17 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 14.1. Normative References . . . . . . . . . . . . . . . . . . . 17 95 14.2. Informational References . . . . . . . . . . . . . . . . . 18 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 Message body handling in SIP was originally specified in [RFC3261], 101 which relied on earlier specifications (e.g., MIME) to describe some 102 areas. This document contains background material on how bodies are 103 handled in SIP and normative material on areas that had not been 104 specified before or whose specifications needed to be completed. 105 Sections containing background material are clearly identified as 106 such by their titles. The material on the normative sections is 107 based on experience gained since [RFC3261] was written. Implementers 108 need to implement what is specified in [RFC3261] (and its references) 109 in addition to what is specified in this document. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 UA: User Agent 118 UAC: User Agent Client 119 UAS: User Agent Server 120 URL: Uniform Resource Locator 122 3. Message Body Encoding 124 This section deals with the encoding of message bodies in SIP. 126 3.1. Background on Message Body Encoding 128 SIP [RFC3261] messages consist of an initial line (request line in 129 requests and status line in responses), a set of header fields, and 130 an optional message body. The message body is described using header 131 fields such as Content-Disposition, Content-Encoding, and Content- 132 Type, which provide information on its contents. Figure 1 shows a 133 SIP message that carries a body. Some of the header fields are not 134 shown for simplicity: 136 INVITE sip:conf-fact@example.com SIP/2.0 137 Content-Type: application/sdp 138 Content-Length: 192 140 v=0 141 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com 142 s=- 143 c=IN IP4 192.0.2.1 144 t=0 0 145 m=audio 20000 RTP/AVP 0 146 a=rtpmap:0 PCMU/8000 147 m=video 20002 RTP/AVP 31 148 a=rtpmap:31 H261/90000 150 Figure 1: SIP message carrying a body 152 The message body of a SIP message can be divided into various body 153 parts. Multipart message bodies are encoded using the MIME 154 (Multipurpose Internet Mail Extensions) [RFC2045] format. Body parts 155 are also described using header fields such as Content-Disposition, 156 Content-Encoding, and Content-Type, which provide information on the 157 contents of a particular body part. Figure 2 shows a SIP message 158 that carries two body parts. Some of the header fields are not shown 159 for simplicity: 161 INVITE sip:conf-fact@example.com SIP/2.0 162 Content-Type: multipart/mixed;boundary="boundary1" 163 Content-Length: 617 165 --boundary1 166 Content-Type: application/sdp 168 v=0 169 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com 170 s=- 171 c=IN IP4 192.0.2.1 172 t=0 0 173 m=audio 20000 RTP/AVP 0 174 a=rtpmap:0 PCMU/8000 175 m=video 20002 RTP/AVP 31 176 a=rtpmap:31 H261/90000 178 --boundary1 179 Content-Type: application/resource-lists+xml 180 Content-Disposition: recipient-list 182 183 185 186 187 188 189 190 --boundary1-- 192 Figure 2: SIP message carrying a body 194 SIP uses S/MIME [RFC3850] to protect message bodies. As specified in 195 [RFC3261], UASs that cannot decrypt a message body or a body part can 196 use the 493 (Undecipherable) response to report the error. 198 3.2. UA Behavior to Encode Binary Message Bodies 200 SIP messages can carry binary message bodies such as legacy 201 signalling objects [RFC3204]. SIP proxy servers are 8-bit safe. 202 That is, they are able to handle binary bodies. Therefore, there is 203 no need to use encodings such as base64 to transport binary bodies in 204 SIP messages. Consequently, UAs SHOULD use the binary transfer 205 encoding for all payloads in SIP, including binary payloads. The 206 only case where a UA MAY use a different encoding is when 207 transferring application data between applications that only handle a 208 different encoding (e.g., base64). 210 4. Multipart Message Bodies 212 This section deals with 'multipart' message bodies and their 213 handling. 215 4.1. Background on 'multipart' Message Bodies 217 [RFC3261] did not mandate support for multipart message bodies in 218 MIME format [RFC2046]. However, since [RFC3261] was written, many 219 SIP extensions rely on them. 221 The use of 'multipart/mixed' MIME bodies is a useful tool to build 222 SIP extensions. An example of such an extension could be the 223 inclusion of location information in an INVITE request. Such an 224 INVITE request would use the 'multipart/mixed' MIME type [RFC2046] to 225 carry two body parts: a session description and a location object. 226 An example of an existing extension that uses 'multipart/mixed' to 227 send a session description and a legacy-signalling object is defined 228 in [RFC3204]. 230 Another MIME type that is useful to build SIP extensions is 231 'multipart/alternative' [RFC2046]. Each body part within a 232 'multipart/alternative' carries an alternative version of the same 233 information. 235 The transition from SDP to new session description protocols could be 236 implemented using 'multipart/alternative' bodies. SIP messages 237 (e.g., INVITE requests) could carry a 'multipart/alternative' body 238 with two body parts: a session description written in SDP and a 239 session description written in a newer session description format. 240 Legacy recipient UAs would use the session description written in 241 SDP. New recipient UAs would use the one written in the newer 242 format. 244 Nested MIME bodies are yet another useful tool to build and combine 245 SIP extensions. Using the extensions in the previous examples, a UA 246 that supported a new session description format and that needed to 247 include a location object in an INVITE request would include a 248 'multipart/mixed' body with two body parts: a location object and a 249 'multipart/alternative'. The 'multipart/alternative' body part 250 would, in turn, have two body parts: a session description written in 251 SDP and a session description written in the newer session 252 description format. 254 4.2. Mandatory Support for 'multipart' Message Bodies 256 For all MIME-based extensions to work, the recipient needs to be able 257 to decode the multipart bodies. Therefore, SIP UAs MUST support 258 parsing 'multipart' MIME bodies, including nested body parts. 259 Additionally, UAs MUST support the 'multipart/mixed' and 'multipart/ 260 alternative' MIME types. Support for other MIME types such as 261 'multipart/related' is OPTIONAL. 263 Note that, by default, unknown 'multipart' subtypes are treated as 264 'multipart/mixed'. Also note that SIP extensions can also include 265 'multipart' MIME bodies in responses. That is why both UACs and 266 UASs need to support 'multipart' bodies. 268 Legacy SIP UAs without support for 'multipart' bodies generate a 415 269 (Unsupported Media Type) response when they receive a 'multipart' 270 body in a request. A UAC sending a 'multipart' body can receive such 271 an error response when communicating with a legacy SIP UA that 272 predates this specification. 274 It has been observed on the field that a number of legacy SIP UAs 275 without support for 'multipart' bodies simply ignored those bodies 276 when they were received. These UAs did not return any error 277 response. Unsurprisingly, SIP UAs not being able to report this 278 type of error have caused serious interoperability problems in the 279 past. 281 4.3. UA Behavior to Generate 'multipart' Message Bodies 283 UAs SHOULD avoid unnecessarily nesting body parts because doing so 284 would, unnecessarily, make processing the body more laborious for the 285 receiver. However, [RFC2046] states that a 'multipart' media type 286 with a single body part is useful in some circumstances (e.g., for 287 sending non-text media types). In any case, UAs SHOULD NOT nest one 288 'multipart/mixed' within another unless there is a need to reference 289 the nested one (i.e., using the Content ID of the nested body part). 290 Additionally, UAs SHOULD NOT nest one 'multipart/alternative' within 291 another. 293 Note that UAs receiving unnecessarily nested body parts treat them 294 as if they were not nested. 296 5. Multipart/mixed Message Bodies 298 This section does not specify any additional behavior regarding how 299 to generate and process 'multipart/mixed' bodies. This section is 300 simply included for completeness. 302 6. Multipart/alternative Message Bodies 304 This section deals with 'multipart/alternative' message bodies and 305 their handling. 307 6.1. Background on 'multipart/alternative' Message Bodies 309 Each body part within a 'multipart/alternative' carries an 310 alternative version of the same information. The body parts are 311 ordered so that the last one is the richest representation of the 312 information. The recipient of a 'multipart/alternative' body chooses 313 the last body part it understands. 315 Note that within a body part encoded in a given format (i.e., of a 316 given content type), there can be optional elements that can 317 provide richer information to the recipient in case the recipient 318 supports them. For example, in SDP (Session Description Protocol) 319 [RFC4566], those optional elements are encoded in 'a' lines. 320 These types of optional elements are internal to a body part and 321 are not visible at the MIME level. That is, a body part is 322 understood if the recipient understands its content type, 323 regardless of whether or not the body part's optional elements are 324 understood. 326 Note as well that each part of a 'multipart/alternative' body 327 represents the same data, but the mapping between any two parts is 328 not necessarily without information loss. For example, 329 information can be lost when translating 'text/html' to 'text/ 330 plain'. [RFC2046] recommends that each part should have a 331 different Content-ID value in the case where the information 332 content of the two parts is not identical. 334 6.2. UA Behavior to Generate 'multipart/alternative' Message Bodies 336 Section 8.2 mandates all the top-level body parts within a 337 'multipart/alternative' to have the same disposition type. 339 The 'session' and 'early-session' [RFC3959] disposition types require 340 that all the body parts of a 'multipart/alternative' body have 341 different content types. Consequently, for the 'session' and 'early- 342 session' disposition types, UAs MUST NOT place more than one body 343 part with a given content type in a 'multipart/alternative' body. 344 That is, for 'session' and 'early-session', no body part within a 345 'multipart/alternative' can have the same content type as another 346 body part within the same 'multipart/alternative'. 348 6.3. UA Behavior to Process 'multipart/alternative' Message Bodies 350 This section does not specify any additional behavior regarding how 351 to process 'multipart/alternative' bodies. This section is simply 352 included for completeness. 354 7. Multipart/related Message Bodies 356 This section deals with 'multipart/related' message bodies and their 357 handling. 359 7.1. Background on 'multipart/related' Message Bodies 361 Compound objects in MIME are represented using the 'multipart/ 362 related' content type [RFC2387]. The body parts within a particular 363 'multipart/related' body are all part of a compound object and are 364 processed as such. The body part within a 'multipart/related' body 365 that needs to be processed first is referred to as the 'root' body 366 part. The root body part of a 'multipart/related' body is identified 367 by the 'start' parameter, which is a Content-Type header field 368 parameter and contains a Content-ID URL pointing to the root body 369 part. If the start parameter is not present, the root body part is, 370 by default, the first body part of the 'multipart/related'. An 371 example of a compound object is a web page that contains images. The 372 html body part would the root. The remaining body parts would 373 contain the images. An example of a SIP extension using 'multipart/ 374 related' is specified in [RFC4662]. 376 7.2. UA Behavior to Generate 'multipart/related' Message Bodies 378 This section does not specify any additional behavior regarding how 379 to generate 'multipart/related' bodies. This section is simply 380 included for completeness. 382 7.3. UA Behavior to Process 'multipart/related' Message Bodies 384 Per [RFC2387], a UA processing a 'multipart/related' body processes 385 the body as a compound object ignoring the disposition types of the 386 body parts within it. Ignoring the disposition types of the 387 individual body parts makes sense in the context in which 'multipart/ 388 related' was originally specified. For instance, in the example of 389 the web page, the implicit disposition type for the images would be 390 'inline', since the images are displayed as indicated by the root 391 html file. However, in SIP, the disposition types of the individual 392 body parts within a 'multipart/related' play an important role and, 393 thus, need to be considered by the UA processing the 'multipart/ 394 related'. Different SIP extensions that use the same disposition 395 type for the 'multipart/related' body can be distinguished by the 396 disposition types of the individual body parts within the 'multipart/ 397 related'. Consequently, SIP UAs processing a 'multipart/related' 398 body with a given disposition type MUST process the disposition types 399 of the body parts within it according to the SIP extension making use 400 the disposition type of the 'multipart/related'. 402 Note that UAs that do not understand 'multipart/related' will 403 treat 'multipart/related' bodies as 'multipart/mixed' bodies. 404 These UAs will not be able to process a given body as a compound 405 object. Instead, they will process the body parts according to 406 their disposition type as if each body part was independent from 407 each other. 409 8. Disposition Types 411 This section deals with disposition types in message bodies. 413 8.1. Background on Content and Disposition Types in SIP 415 The Content-Disposition header field, defined in [RFC2183] and 416 extended by [RFC3261], describes how to handle a SIP message's body 417 or an individual body part. Examples of disposition types used in 418 SIP in the Content-Disposition header field are 'session' and 419 'render'. 421 [RFC3204] and [RFC3459] define the 'handling' parameter for the 422 Content-Disposition header field. This parameter describes how a UAS 423 reacts if it receives a message body whose content type or 424 disposition type it does not understand. If the parameter has the 425 value 'optional', the UAS ignores the message body; if the parameter 426 has the value 'required', the UAS returns a 415 (Unsupported Media 427 Type) response. The default value for the 'handling' parameter is 428 'required'. The following is an example of a Content-Disposition 429 header field: 431 Content-Disposition: signal; handling=optional 433 [RFC3204] identifies two situations where a UAS (User Agent Server) 434 needs to reject a request with a body part whose handling is 435 required: 437 1. if it has an unknown content type. 438 2. if it has an unknown disposition type. 440 If the UAS did not understand the content type of the body part, the 441 UAS can add an Accept header field to its 415 (Unsupported Media 442 Type) response listing the content types that the UAS does 443 understand. Nevertheless, there is no mechanism for a UAS that does 444 not understand the disposition type of a body part to inform the UAC 445 about which disposition type was not understood or about the 446 disposition types that are understood by the UAS. 448 The reason for not having such a mechanism is that disposition types 449 are typically supported within a context. Outside that context, a UA 450 need not support the disposition type. For example, a UA can support 451 the 'session' disposition type for body parts in INVITE and UPDATE 452 requests and their responses. However, the same UA would not support 453 the 'session' disposition type in MESSAGE requests. 455 In another example, a UA can support the 'render' disposition type 456 for 'text/plain' and 'text/html' body parts in MESSAGE requests. 457 Additionally, the UA can support the 'session' disposition type for 458 'application/sdp' body parts in INVITE and UPDATE requests and their 459 responses. However, the UA might not support the 'render' 460 disposition type for 'application/sdp' body parts in MESSAGE 461 requests, even if, in different contexts, the UA supported all the 462 'render' disposition type, the 'application/sdp' content type, and 463 the MESSAGE method. 465 A given context is generally (but not necessarily) defined by a 466 method, a disposition type, and a content type. Support for a 467 specific context is usually defined within an extension. For 468 example, the extension for instant messaging in SIP [RFC3428] 469 mandates support for the MESSAGE method, the 'render' disposition 470 type, and the 'text/plain' content type. 472 Note that, effectively, content types are also supported within a 473 context. Therefore, the use of the Accept header field in a 415 474 (Unsupported Media Type) response is not enough to describe in 475 which contexts a particular content type is supported. 477 Therefore, support for a particular disposition type within a given 478 context is typically signalled by the use of a particular method or 479 an option-tag in a Supported or a Require header field. When support 480 for a particular disposition type within a context is mandated, 481 support for a default content type is also mandated (e.g., a UA that 482 supports the 'session' disposition type in an INVITE request needs to 483 support the 'application/sdp' content type). 485 8.2. UA Behavior to Set the 'handling' Parameter 487 As stated earlier, the 'handling' Content-Disposition parameter can 488 take two values: 'required' or 'optional'. While it is typically 489 easy for a UA to decide which type of handling an individual body 490 part requires, setting the 'handling' parameter of 'multipart' bodies 491 requires extra considerations. 493 If the handling of a 'multipart/mixed' body as a whole is required 494 for processing its enclosing body part or message, the UA MUST set 495 the 'handling' parameter of the 'multipart/mixed' body to 'required'. 496 Otherwise, the UA MUST set it to 'optional'. The 'handling' 497 parameters of the top-level body parts within the 'multipart/mixed' 498 body are set independently from the 'handling' parameter of the 499 'multipart/mixed' body. If the handling of a particular top-level 500 body part is required, the UA MUST set the 'handling' parameter of 501 that body part 'required'. Otherwise, the UA MUST set it to 502 'optional'. 504 Per the previous rules, a 'multipart/mixed' body whose handling is 505 optional can contain body parts whose handling is required. In 506 such case, the receiver is required to process the body parts 507 whose handling is required if and only if the receiver decides to 508 process the optional 'multipart/mixed' body. 510 Also per the previous rules, a 'multipart/mixed' body whose 511 handling is required can contain only body parts whose handling is 512 optional. In such case, the receiver is required to process the 513 body as a whole but, when processing it, the receiver may decide 514 (based on its local policy) not to process any of the body parts. 516 The 'handling' parameter is a Content-Disposition parameter. 517 Therefore, in order to set this parameter, it is necessary to provide 518 the 'multipart/mixed' body with a disposition type. Per [RFC3261], 519 the default disposition type for 'application/sdp' is 'session' and 520 for other bodies is 'render'. UAs SHOULD assign 'multipart/mixed' 521 bodies a disposition type of 'render'. 523 Note that the fact that 'multipart/mixed' bodies have a default 524 disposition type of 'render' does not imply that they will be 525 rendered to the user. The way the body parts within the 526 'multipart/mixed' are handled depends on the disposition types of 527 the individual body parts. The actual disposition type of the 528 whole 'multipart/mixed' is irrelevant. The 'render' disposition 529 type has been chosen for 'multipart/mixed' bodies simply because 530 'render' is the default disposition type in SIP. 532 If the handling of a 'multipart/alternative' body as a whole is 533 required for processing its enclosing body part or message, the UA 534 MUST set the 'handling' parameter of the 'multipart/alternative' body 535 to 'required'. Otherwise, the UA MUST set it to 'optional'. The UA 536 SHOULD also set the 'handling' parameter of all the top-level body 537 part within the 'multipart/alternative' to 'optional'. 539 The receiver will process the body parts based on the handling 540 parameter of the 'multipart/alternative' body. The receiver will 541 ignore the handling parameters of the body parts. That is why 542 setting them to 'optional' is at the "should" level and not at the 543 "must" level; because their value is irrelevant. 545 The UA MUST use the same disposition type for the 'multipart/ 546 alternative' body and all its top-level body parts. 548 If the handling of a 'multipart/related' body as a whole is required 549 for processing its enclosing body part or message, the UA MUST set 550 the 'handling' parameter of the 'multipart/related' body to 551 'required'. Otherwise, the UA MUST set it to 'optional'. The 552 'handling' parameters of the top-level body parts within the 553 'multipart/related' body are set independently from the 'handling' 554 parameter of the 'multipart/related' body. If the handling of a 555 particular top-level body part is required, the UA MUST set the 556 'handling' parameter of that body part to 'required'. Otherwise, the 557 UA MUST set it to 'optional'. If at least one top-level body part 558 within a 'multipart/related' body has a 'handling' parameter of 559 'required', the UA SHOULD set the 'handling' parameter of the root 560 body part to 'required'. 562 8.3. UA Behavior to Process 'multipart/alternative' 564 The receiver of 'multipart/alternative' body MUST process the body 565 based on its handling parameter. The receiver SHOULD ignore the 566 handling parameters of the body parts within the 'multipart/ 567 alternative'. 569 8.4. UAS Behavior to Report Unsupported Message Bodies 571 If a UAS cannot process a request because, in the given context, the 572 UAS does not support the content type or the disposition type of a 573 body part whose handling is required, the UAS SHOULD return a 415 574 (Unsupported Media Type) response even if the UAS supported the 575 content type, the disposition type, or both in a different context. 577 Consequently, it is possible to receive a 415 (Unsupported Media 578 Type) response with an Accept header field containing all the 579 content types used in the request. 581 If a UAS receives a request with a body part whose disposition type 582 is not compatible with the way the body part is supposed to be 583 handled according to other parts of the SIP message (e.g., a Refer-To 584 header field with a Content-ID URL pointing to a body part whose 585 disposition type is 'session'), the UAS SHOULD return a 415 586 (Unsupported Media Type) response. 588 9. Message Body Processing 590 This section deals with the processing of message bodies and how that 591 processing is influenced by the presence of references to them. 593 9.1. Background on References to Message Body Parts 595 Content-ID URLs allow creating references to body parts. A given 596 Content-ID URL [RFC2392], which can appear in a header field or 597 within a body part (e.g., in an SDP attribute), points to a 598 particular body part. The way to handle that body part is defined by 599 the field the Content-ID URL appears. For example, the extension to 600 refer to multiple resources in SIP [RFC5368] places a Content-ID URL 601 in a Refer-To header field. Such a Content-ID URL points to a body 602 part that carries a URI list. In another example, the extension for 603 file transfer in SDP [I-D.ietf-mmusic-file-transfer-mech] places a 604 Content-ID URL in a 'file-icon' SDP attribute. This Content-ID URL 605 points to a body part that carries a (typically small) picture. 607 9.2. UA Behavior to Generate References to Message Bodies 609 UAs MUST only include forward references in the SIP messages they 610 generate. That is, an element in a SIP message can reference a body 611 part only if the body part appears after the element. Consequently, 612 a given body part can only be referenced by another body part that 613 appears before it or by a header field. Having only forward 614 references allows recipients to process body parts as they parse 615 them. They do not need to parse the remainder of the message in 616 order to process a body part. 618 It was considered to only allow (forward) references among body 619 parts that belonged to the same 'multipart/related' [RFC2387] 620 wrapper. However, it was finally decided that this extra 621 constraint was not necessary. 623 9.3. UA Behavior to Process Message Bodies 625 In order to process a message body or a body part, a UA needs to know 626 whether a SIP header field or another body part contains a reference 627 to the message body or body part (e.g., a Content-ID URL pointing to 628 it). If the body part is not referenced in any way (e.g., there are 629 no header fields or other body parts with a Content-ID URL pointing 630 to it), the UA processes the body part as indicated by its 631 disposition type and the context in which the body part was received. 633 If the SIP message contains a reference to the body part, the UA 634 processes the body part according to the reference. If the SIP 635 message contains more than one reference to the body part (e.g., two 636 header fields contain Content-ID URLs pointing to the body part), the 637 UA processes the body part as many times as references are. 639 Note that, following the rules in [RFC3204], if a UA does not 640 understand a body part whose handling is optional, the UA ignores 641 it. Also note that the content indirection mechanism in SIP 642 [RFC4483] allows UAs to point to external bodies. Therefore, a UA 643 receiving a SIP message that uses content indirection could need 644 to fetch a body part (e.g., using HTTP [RFC2616]) in order to 645 process it. 647 9.4. The 'by-reference' Disposition Type 649 Per the rules in Section 9.3, if a SIP message contains a reference 650 to a body part, the UA processes the body part according to the 651 reference. Since the reference provides the context in which the 652 body part needs to be processed, the disposition type of the body 653 part is irrelevant. However, a UA that missed a reference to a body 654 part (e.g., because the reference was in a header field the UA did 655 not support) would attempt to process the body part according to its 656 disposition type alone. To keep this from happening, we define a new 657 disposition type for the Content-Disposition header field: by- 658 reference. 660 A body part whose disposition type is 'by-reference' needs to be 661 handled according to a reference to the body part that is located in 662 the same SIP message as the body part (given that SIP only allows 663 forward references, the reference will appear in the same SIP message 664 before the body part). A recipient of a body part whose disposition 665 type is 'by-reference' that cannot find any reference to the body 666 part (e.g., the reference was in a header field the recipient does 667 not support and, thus, did not process) MUST NOT process the body 668 part. Consequently, if the handling of the body part was required, 669 the UA needs to report an error. 671 Note that extensions that predate this specifications use 672 references to body parts whose disposition type is not 'by- 673 reference'. Those extensions use option-tags to make sure the 674 recipient understands the whole extension and, thus, cannot miss 675 the reference and attempt to process the body part according to 676 its disposition type alone. 678 10. Guidelines to Authors of SIP Extensions 680 These guidelines are intended for authors of SIP extensions that 681 involve, in some way, message bodies or body parts. These guidelines 682 discuss aspects authors of such extensions need to consider when 683 design them. 685 This specification mandates support for 'multipart/mixed' and 686 'multipart/alternative'. At present, there are no SIP extensions 687 that use different 'multipart' subtypes such as parallel [RFC2046] or 688 digest [RFC2046]. If such extensions were to be defined in the 689 future, their authors would need to make sure (e.g., by using an 690 option-tag or by other means) that entities receiving those 691 'multipart' subtypes were able to process them. As stated earlier, 692 UAs treat unknown 'multipart' subtypes as 'multipart/mixed'. 694 Authors of SIP extensions making use of 'multipart/related' bodies 695 have to explicitly address the handling of the disposition types of 696 the body parts within the 'multipart/related' body. Authors wishing 697 to make use of 'multipart/related' bodies should keep in mind that 698 UAs that do not understand 'multipart/related' will treat it as 699 'multipart/mixed'. If such treatment by a recipient is not 700 acceptable for a particular extension, the authors of such extension 701 would need to make sure (e.g., by using an option-tag or by other 702 means) that entities receiving the 'multipart/related' body were able 703 to correctly process them. 705 As stated earlier, SIP extensions can also include 'multipart' MIME 706 bodies in responses. Hence, a response can be extremely complex and 707 the UAC receiving the response might not be able to process it 708 correctly. Because UACs receiving a response cannot report errors to 709 the UAS that generated the response (i.e., error responses can only 710 be generated for requests) authors of SIP extensions need to make 711 sure that requests clearly indicate (e.g., by using an option-tag or 712 by other means) the capabilities of the UAC so that UASs can decide 713 what to include in their responses. 715 11. Security Considerations 717 This document specifies how SIP entities handle message bodies. 718 [RFC3261] discusses what type of information is encoded in SIP 719 message bodies and how SIP entities can protect that information. In 720 addition to the hop-by-hop security SIP can provide, SIP can also 721 secure information in an end-to-end fashion. SIP message bodies can 722 be end-to-end encrypted and integrity protected using S/MIME 723 [RFC3850], as described in [RFC3261]. 725 12. Acknowledgements 727 The ideas in this document were originally discussed with Paul 728 Kyzivat. Christer Holmberg, Francois Audet, Dan Wing, Adam Roach, 729 Keith Drage, and Dale Worley provided comments on it. Dave Crocker 730 performed a thorough review on the whole document. 732 13. IANA Considerations 734 This document contains two actions for the IANA. 736 13.1. Registration of the 'by-reference' Disposition Type 738 This document defines a new Content-Disposition header field 739 disposition type (by-reference) Section 9.4. This value has been 740 registered in the IANA registry for Content-Dispositions with the 741 following description: 743 by-reference The body needs to be handled according to a 744 reference to the body that is located in 745 the same SIP message as the body. 747 13.2. Update of the 'handling' Parameter Registration 749 A reference to this specification, to [RFC3204], and to [RFC3459] 750 should be added to the entry for the Content-Disposition 'handling' 751 parameter in the Header Field Parameters and Parameter Values 752 registry. The following is the resulting entry. 754 Predefined 755 Header Field Parameter Name Values Reference 756 ------------------- --------------- --------- ------------------- 757 Content-Disposition handling Yes [RFC3204] [RFC3261] 758 [RFC3459] [RFCxxxx] 760 Note to the RFC Editor: Please, replace RFCxxxx with the RFC number 761 of this document. 763 14. References 765 14.1. Normative References 767 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 768 Extensions (MIME) Part One: Format of Internet Message 769 Bodies", RFC 2045, November 1996. 771 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 772 Extensions (MIME) Part Two: Media Types", RFC 2046, 773 November 1996. 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, March 1997. 778 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 779 Presentation Information in Internet Messages: The 780 Content-Disposition Header Field", RFC 2183, August 1997. 782 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 783 RFC 2387, August 1998. 785 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 786 Locators", RFC 2392, August 1998. 788 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 789 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 790 and QSIG Objects", RFC 3204, December 2001. 792 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 793 A., Peterson, J., Sparks, R., Handley, M., and E. 794 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 795 June 2002. 797 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 798 Extensions (MIME) Parameter", RFC 3459, January 2003. 800 [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail 801 Extensions (S/MIME) Version 3.1 Certificate Handling", 802 RFC 3850, July 2004. 804 [RFC3959] Camarillo, G., "The Early Session Disposition Type for the 805 Session Initiation Protocol (SIP)", RFC 3959, 806 December 2004. 808 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 809 Session Initiation Protocol (SIP) Messages", RFC 4483, 810 May 2006. 812 14.2. Informational References 814 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 815 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 816 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 818 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 819 and D. Gurle, "Session Initiation Protocol (SIP) Extension 820 for Instant Messaging", RFC 3428, December 2002. 822 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 823 Description Protocol", RFC 4566, July 2006. 825 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 826 Initiation Protocol (SIP) Event Notification Extension for 827 Resource Lists", RFC 4662, August 2006. 829 [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., 830 and H. Khartabil, "Referring to Multiple Resources in the 831 Session Initiation Protocol (SIP)", RFC 5368, 832 October 2008. 834 [I-D.ietf-mmusic-file-transfer-mech] 835 Garcia, M., Isomaki, M., Camarillo, G., Loreto, S., and P. 836 Kyzivat, "A Session Description Protocol (SDP) Offer/ 837 Answer Mechanism to Enable File Transfer", 838 draft-ietf-mmusic-file-transfer-mech-11 (work in 839 progress), February 2009. 841 Author's Address 843 Gonzalo Camarillo 844 Ericsson 845 Hirsalantie 11 846 Jorvas 02420 847 Finland 849 Email: Gonzalo.Camarillo@ericsson.com