idnits 2.17.1 draft-ietf-sip-body-handling-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 732. 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 26, 2008) is 5814 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) ** 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) == Outdated reference: A later version (-11) exists of draft-ietf-mmusic-file-transfer-mech-06 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 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 Intended status: Standards Track May 26, 2008 5 Expires: November 27, 2008 7 Message Body Handling in the Session Initiation Protocol (SIP) 8 draft-ietf-sip-body-handling-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of 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 November 27, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document specifies how message bodies are handled in SIP. 42 Additionally, it specifies SIP user agent support for MIME 43 (Multipurpose Internet Mail Extensions) in message bodies. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Message Body Encoding . . . . . . . . . . . . . . . . . . . . 3 50 3.1. Background on Message Body Encoding . . . . . . . . . . . 3 51 3.2. UA Behavior to Encode Binary Message Bodies . . . . . . . 5 52 4. Multipart Message Bodies . . . . . . . . . . . . . . . . . . . 6 53 4.1. Background on 'multipart' Message Bodies . . . . . . . . . 6 54 4.2. Mandatory Support for 'multipart' Message Bodies . . . . . 6 55 4.3. UA Behavior to Generate 'multipart' Message Bodies . . . . 7 56 5. Multipart/alternative Message Bodies . . . . . . . . . . . . . 7 57 5.1. Background on 'multipart/alternative' Message Bodies . . . 7 58 5.2. UA Behavior to Generate 'multipart/alternative' 59 Message Bodies . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 8 61 6.1. Background on Content and Disposition Types in SIP . . . . 8 62 6.2. UA Behavior to Set the 'handling' Parameter . . . . . . . 10 63 6.3. UA Behavior to Process 'multipart/alternative' . . . . . . 11 64 6.4. UAS Behavior to Report Unsupported Message Bodies . . . . 11 65 7. Message Body Processing . . . . . . . . . . . . . . . . . . . 11 66 7.1. Background on References to Message Body Parts . . . . . . 11 67 7.2. UA Behavior to Generate References to Message Bodies . . . 12 68 7.3. UA Behavior to Process Message Bodies . . . . . . . . . . 12 69 7.4. The 'by-reference' Disposition Type . . . . . . . . . . . 12 70 8. Guidelines to Authors of SIP Extensions . . . . . . . . . . . 13 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 12.2. Informational References . . . . . . . . . . . . . . . . . 16 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 Intellectual Property and Copyright Statements . . . . . . . . . . 17 80 1. Introduction 82 Originally, message body handling in SIP was specified in [RFC3261], 83 which relied on earlier specifications (e.g., MIME) to describe some 84 areas. This document contains background material on how bodies are 85 handled in SIP and normative material on areas that had not been 86 specified before or whose specifications needed to be completed. 87 Sections containing background material are clearly identified as 88 such by their titles. The material on the normative sections is 89 based on experience gained since [RFC3261] was written. Implementers 90 need to implement what is specified in [RFC3261] (and its references) 91 in addition to what is specified in this document. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 UA: User Agent 100 UAC: User Agent Client 101 UAS: User Agent Server 102 URL: Uniform Resource Locator 104 3. Message Body Encoding 106 This section deals with the encoding of message bodies in SIP. 108 3.1. Background on Message Body Encoding 110 SIP [RFC3261] messages consist of an initial line (request line in 111 requests and status line in responses), a set of header fields, and 112 an optional message body. The message body is described using header 113 fields such as Content-Disposition, Content-Encoding, and Content- 114 Type, which provide information on its contents. Figure 1 shows a 115 SIP message that carries a body. Some of the header fields are not 116 shown for simplicity: 118 INVITE sip:conf-fact@example.com SIP/2.0 119 Content-Type: application/sdp 120 Content-Length: 192 122 v=0 123 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com 124 s=- 125 c=IN IP4 192.0.2.1 126 t=0 0 127 m=audio 20000 RTP/AVP 0 128 a=rtpmap:0 PCMU/8000 129 m=video 20002 RTP/AVP 31 130 a=rtpmap:31 H261/90000 132 Figure 1: SIP message carrying a body 134 The message body of a SIP message can be divided into various body 135 parts. Multipart message bodies are encoded using the MIME 136 (Multipurpose Internet Mail Extensions) [RFC2045] format. Body parts 137 are also described using header fields such as Content-Disposition, 138 Content-Encoding, and Content-Type, which provide information on the 139 contents of a particular body part. Figure 2 shows a SIP message 140 that carries two body parts. Some of the header fields are not shown 141 for simplicity: 143 INVITE sip:conf-fact@example.com SIP/2.0 144 Content-Type: multipart/mixed;boundary="boundary1" 145 Content-Length: 617 147 --boundary1 148 Content-Type: application/sdp 150 v=0 151 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com 152 s=- 153 c=IN IP4 192.0.2.1 154 t=0 0 155 m=audio 20000 RTP/AVP 0 156 a=rtpmap:0 PCMU/8000 157 m=video 20002 RTP/AVP 31 158 a=rtpmap:31 H261/90000 160 --boundary1 161 Content-Type: application/resource-lists+xml 162 Content-Disposition: recipient-list 164 165 167 168 169 170 171 172 --boundary1-- 174 Figure 2: SIP message carrying a body 176 SIP uses S/MIME [RFC3850] to protect message bodies. As specified in 177 [RFC3261], UASs that cannot decrypt a message body or a body part can 178 use the 493 (Undecipherable) response to report the error. 180 3.2. UA Behavior to Encode Binary Message Bodies 182 SIP messages can carry binary message bodies such as legacy 183 signalling objects [RFC3204]. SIP proxy servers are 8-bit safe. 184 That is, they are able to handle binary bodies. Therefore, there is 185 no need to use encodings such as base64 to transport binary bodies in 186 SIP messages. Consequently, UAs MUST use the binary transfer 187 encoding for binary payloads in SIP. 189 4. Multipart Message Bodies 191 This section deals with 'multipart' message bodies and their 192 handling. 194 4.1. Background on 'multipart' Message Bodies 196 [RFC3261] did not mandate support for multipart message bodies in 197 MIME format [RFC2046]. However, since [RFC3261] was written, many 198 SIP extensions rely on them. 200 The use of 'multipart/mixed' MIME bodies is a useful tool to build 201 SIP extensions. An example of such an extension could be the 202 inclusion of location information in an INVITE request. Such an 203 INVITE request would use the 'multipart/mixed' MIME type [RFC2046] to 204 carry two body parts: a session description and a location object. 205 An example of an existing extension that uses 'multipart/mixed' to 206 send a session description and a legacy-signalling object is defined 207 in [RFC3204]. 209 Another MIME type that is useful to build SIP extensions is 210 'multipart/alternative' [RFC2046]. Each body part within a 211 'multipart/alternative' carries an alternative version of the same 212 information. 214 The transition from SDP to new session description protocols could be 215 implemented using 'multipart/alternative' bodies. SIP messages 216 (e.g., INVITE requests) could carry a 'multipart/alternative' body 217 with two body parts: a session description written in SDP and a 218 session description written in a newer session description format. 219 Legacy recipient UAs would use the session description written in 220 SDP. New recipient UAs would use the one written in the newer 221 format. 223 Nested MIME bodies are yet another useful tool to build and combine 224 SIP extensions. Using the extensions in the previous examples, a UA 225 that supported a new session description format and that needed to 226 include a location object in an INVITE request would include a 227 'multipart/mixed' body with two body parts: a location object and a 228 'multipart/alternative'. The 'multipart/alternative' body part 229 would, in turn, have two body parts: a session description written in 230 SDP and a session description written in the newer session 231 description format. 233 4.2. Mandatory Support for 'multipart' Message Bodies 235 For all MIME-based extensions to work, the recipient needs to be able 236 to decode the multipart bodies. Therefore, SIP UAs MUST be able to 237 parse 'multipart' MIME bodies, including nested body parts. In 238 particular, UAs MUST support the 'multipart/mixed' and 'multipart/ 239 alternative' MIME types. 241 Note that, by default, unknown 'multipart' subtypes are treated as 242 'multipart/mixed'. Also note that SIP extensions may also include 243 'multipart' MIME bodies in responses. That is why both UACs and 244 UASs need to support 'multipart' bodies. 246 Legacy SIP UAs without support for 'multipart' bodies generate a 415 247 (Unsupported Media Type) response when they receive a 'multipart' 248 body. A UAC sending a 'multipart' body may receive such an error 249 response when communicating with a legacy SIP UA that predates this 250 specification. 252 It has been observed on the field that a number of legacy SIP UAs 253 without support for 'multipart' bodies simply ignored those bodies 254 when they were received. These UAs did not return any error 255 response. Unsurprisingly, SIP UAs not being able to report this 256 type of error have caused serious interoperability problems in the 257 past. 259 4.3. UA Behavior to Generate 'multipart' Message Bodies 261 UAs SHOULD avoid unnecessarily nesting body parts because doing so 262 would, unnecessarily, make processing the body more laborious for the 263 receiver. However, [RFC2046] states that a 'multipart' media type 264 with a single body part is useful in some circumstances (e.g., for 265 sending non-text media types). In any case, UAs SHOULD NOT nest one 266 'multipart/mixed' within another unless there is a need to reference 267 the nested one (i.e., using the Content ID of the nested body part). 268 Additionally, UAs SHOULD NOT nest one 'multipart/alternative' within 269 another. 271 5. Multipart/alternative Message Bodies 273 This section deals with 'multipart/alternative' message bodies and 274 their handling. 276 5.1. Background on 'multipart/alternative' Message Bodies 278 Each body part within a 'multipart/alternative' carries an 279 alternative version of the same information. The body parts are 280 ordered so that the last one is the richest representation of the 281 information. This way, the recipient of a 'multipart/alternative' 282 body chooses the last body part it understands. 284 Note that within a body part encoded in a given format (i.e., of a 285 given content type), there may be optional elements that may 286 provide richer information to the recipient in case the recipient 287 supports them. For example, in SDP (Session Description Protocol) 288 [RFC4566], those optional elements are encoded in 'a' lines. 289 These types of optional elements are internal to a body part and 290 are not visible at the MIME level. That is, a body part is 291 understood if the recipient understands its content type, 292 regardless of whether or not the body part's optional elements are 293 understood. 295 Note as well that each part of a 'multipart/alternative' body 296 represents the same data, but the mapping between any two parts is 297 not necessarily without information loss. For example, 298 information may be lost when translating 'text/html' to 'text/ 299 plain'. [RFC2046] recommends that each part should have a 300 different Content-ID value in the case where the information 301 content of the two parts is not identical. 303 5.2. UA Behavior to Generate 'multipart/alternative' Message Bodies 305 All the body parts within a 'multipart/alternative' have the same 306 disposition type (see Section 6.2). The 'session' and 'early- 307 session' [RFC3959] disposition types require that all the body parts 308 of a 'multipart/alternative' body have different content types. 309 Consequently, for the 'session' and 'early-session' disposition 310 types, UAs MUST NOT place more than one body part with a given 311 content type in a 'multipart/alternative' body. That is, for 312 'session' and 'early-session', no body part within a 'multipart/ 313 alternative' can have the same content type as another body part 314 within the same 'multipart/alternative'. 316 6. Disposition Types 318 This section deals with disposition types in message bodies. 320 6.1. Background on Content and Disposition Types in SIP 322 The Content-Disposition header field, defined in [RFC2183] and 323 extended by [RFC3261], describes how to handle a SIP message's body 324 or an individual body part. Examples of disposition types used in 325 SIP in the Content-Disposition header field are 'session' and 326 'render'. 328 [RFC3204] and [RFC3459] define the 'handling' parameter for the 329 Content-Disposition header field. This parameter describes how a UAS 330 should react if it receives a message body whose content type or 331 disposition type it does not understand. If the parameter has the 332 value 'optional', the UAS ignores the message body; if it has the 333 value 'required', the UAS returns a 415 (Unsupported Media Type) 334 response. The default value for the 'handling' parameter is 335 'required'. The following is an example of a Content-Disposition 336 header field: 338 Content-Disposition: signal; handling=optional 340 [RFC3204] identifies two situations where a UAS (User Agent Server) 341 needs to reject a request with a body part whose handling is 342 required: 344 1. if it has an unknown content type. 345 2. if it has an unknown disposition type. 347 If the UAS did not understand the content type of the body part, it 348 can add an Accept header field to its 415 (Unsupported Media Type) 349 response listing the content types that the UAS does understand. 350 Nevertheless, there is no mechanism for a UAS that does not 351 understand the disposition type of a body part to inform the UAC 352 about which disposition type was not understood or about the 353 disposition types that are understood by the UAS. 355 The reason for not having such a mechanism is that disposition types 356 are typically supported within a context. Outside that context, a UA 357 may not support the disposition type. For example, a UA may support 358 the 'session' disposition type for body parts in INVITE and UPDATE 359 requests and their responses. However, the same UA would not support 360 the 'session' disposition type in MESSAGE requests. 362 In another example, a UA may support the 'render' disposition type 363 for 'text/plain' and 'text/html' body parts in MESSAGE requests. 364 Additionally, the UA may support the 'session' disposition type for 365 'application/sdp' body parts in INVITE and UPDATE requests and their 366 responses. However, the UA may not support the 'render' disposition 367 type for 'application/sdp' body parts in MESSAGE requests, even if, 368 in different contexts, the UA supported all the 'render' disposition 369 type, the 'application/sdp' content type, and the MESSAGE method. 371 A given context is generally (but not necessarily) defined by a 372 method, a disposition type, and a content type. Support for a 373 specific context is usually defined within an extension. For 374 example, the extension for instant messaging in SIP [RFC3428] 375 mandates support for the MESSAGE method, the 'render' disposition 376 type, and the 'text/plain' content type. 378 Note that, effectively, content types are also supported within a 379 context. Therefore, the use of the Accept header field in a 415 380 (Unsupported Media Type) response is not enough to describe in 381 which contexts a particular content type is supported. 383 Therefore, support for a particular disposition type within a given 384 context is typically signalled by the use of a particular method or 385 an option-tag in a Supported or a Require header field. When support 386 for a particular disposition type within a context is mandated, 387 support for a default content type is also mandated (e.g., a UA that 388 supports the 'session' disposition type in an INVITE request needs to 389 support the 'application/sdp' content type). 391 6.2. UA Behavior to Set the 'handling' Parameter 393 As stated earlier, the 'handling' Content-Disposition parameter can 394 take two values: 'required' or 'optional'. While it is typically 395 easy for a UA to decide which type of handling an individual body 396 part requires, setting the 'handling' parameter of 'multipart' bodies 397 requires extra considerations. 399 If at least one of the body parts within a 'multipart/mixed' body has 400 a 'handling' value of 'required', the UA MUST set the 'handling' 401 parameter of the 'multipart/mixed' body to 'required'. If all the 402 body parts within a 'multipart/mixed' body have a 'handling' value of 403 'optional', the UA MUST set the 'handling' parameter of the 404 'multipart/mixed' body to 'optional'. 406 The 'handling' parameter is a Content-Disposition parameter. 407 Therefore, in order to set this parameter, it is necessary to provide 408 the 'multipart/mixed' body with a disposition type. Per [RFC3261], 409 the default disposition type for 'application/sdp' is 'session' and 410 for other bodies is 'render'. UAs SHOULD assign 'multipart/mixed' 411 bodies a disposition type of 'render'. 413 Note that the fact that 'multipart/mixed' bodies have a default 414 disposition type of 'render' does not imply that they will be 415 rendered to the user. The way the body parts within the 416 'multipart/mixed' are handled depends on the disposition types of 417 the individual body parts. The actual disposition type of the 418 whole 'multipart/mixed' is irrelevant. The 'render' disposition 419 type has been chosen for 'multipart/mixed' bodies simply because 420 it is the default disposition type in SIP. 422 If the handling of a 'multipart/alternative' body is required, the UA 423 MUST set the 'handling' parameter of the 'multipart/alternative' body 424 to 'required'. The UA SHOULD also set the 'handling' parameter of 425 all the body part within the 'multipart/alternative' to 'optional' 426 (the receiver will process the body parts based on the handling 427 parameter of the 'multipart/alternative' body; the receiver will 428 ignore the handling parameters of the body parts). The UA MUST use 429 the same disposition type for the 'multipart/alternative' body and 430 all its body parts. 432 6.3. UA Behavior to Process 'multipart/alternative' 434 The receiver of 'multipart/alternative' body MUST process it based on 435 its handling parameter. The receiver SHOULD ignore the handling 436 parameters of the body parts within the 'multipart/alternative'. 438 6.4. UAS Behavior to Report Unsupported Message Bodies 440 If a UAS cannot process a request because, in the given context, it 441 does not support the content type or the disposition type of a body 442 part whose handling is required, the UAS SHOULD return a 415 443 (Unsupported Media Type) response even if the UAS supported the 444 content type, the disposition type, or both in a different context. 446 Consequently, it is possible to receive a 415 (Unsupported Media 447 Type) response with an Accept header field containing all the 448 content types used in the request. 450 If a UAS receives a request with a body part whose disposition type 451 is not compatible with the way the body part should be handled 452 according to other parts of the SIP message (e.g., a Refer-To header 453 field with a Content-ID URL pointing to a body part whose disposition 454 type is 'session'), the UAS SHOULD return a 415 (Unsupported Media 455 Type) response. 457 7. Message Body Processing 459 This section deals with the processing of message bodies and how it 460 is influenced by the presence of references to them. 462 7.1. Background on References to Message Body Parts 464 Content-ID URLs allow creating references to body parts. A given 465 Content-ID URL [RFC2392], which can appear in a header field or 466 within a body part (e.g., in an SDP attribute), points to a 467 particular body part. The way to handle that body part is defined by 468 the field the Content-ID URL appears. For example, the extension to 469 refer to multiple resources in SIP [I-D.ietf-sip-multiple-refer] 470 places a Content-ID URL in a Refer-To header field. Such a 471 Content-ID URL points to a body part that carries a URI list. In 472 another example, the extension for file transfer in SDP 474 [I-D.ietf-mmusic-file-transfer-mech] places a Content-ID URL in a 475 'file-icon' SDP attribute. This Content-ID URL points to a body part 476 that carries a (typically small) picture. 478 7.2. UA Behavior to Generate References to Message Bodies 480 UAs MUST only include forward references in the SIP messages they 481 generate. That is, an element in a SIP message can reference a body 482 part only if the body part appears after the element. Consequently, 483 a given body part can only be referenced by another body part that 484 appears before it or by a header field. Having only forward 485 references allows recipients to process body parts as they parse 486 them. They do not need to parse the remainder of the message in 487 order to process a body part. 489 It was considered to only allow (forward) references among body 490 parts that belonged to the same 'multipart/related' [RFC2387] 491 wrapper. However, it was finally decided that this extra 492 constrain was not necessary. 494 7.3. UA Behavior to Process Message Bodies 496 In order to process a message body or a body part, a UA needs to know 497 whether a SIP header field or another body part contains a reference 498 to it (e.g., a Content-ID URL pointing to it). If the body part is 499 not referenced in any way (e.g., there are no header fields or other 500 body parts with a Content-ID URL pointing to it), the UA processes 501 the body part as indicated by its disposition type and the context in 502 which the body part was received. 504 If the SIP message contains a reference to the body part, the UA 505 processes the body part according to the reference. If the SIP 506 message contains more than one reference to the body part (e.g., two 507 header fields contain Content-ID URLs pointing to the body part), the 508 UA processes the body part as many times as references are. 510 Note that, following the rules in [RFC3204], if a UA does not 511 understand a body part whose handling is optional, it ignores it. 512 Also note that the content indirection mechanism in SIP [RFC4483] 513 allows UAs to point to external bodies. Therefore, a UA receiving 514 a SIP message that uses content indirection may need to fetch a 515 body part (e.g., using HTTP [RFC2616]) in order to process it. 517 7.4. The 'by-reference' Disposition Type 519 Per the rules in Section 7.3, if a SIP message contains a reference 520 to a body part, the UA processes the body part according to the 521 reference. Since the reference provides the context in which the 522 body part needs to be processed, the disposition type of the body 523 part is irrelevant. However, a UA that missed a reference to a body 524 part (e.g., because the reference was in a header field the UA did 525 not support) would attempt to process the body part according to its 526 disposition type alone. To keep this from happening, we define a new 527 disposition type for the Content-Disposition header field: by- 528 reference. 530 A body part whose disposition type is 'by-reference' needs to be 531 handled according to a reference to the body part that is located in 532 the same SIP message as the body part (given that SIP only allows 533 forward references, the reference will appear in the same SIP message 534 before the body part). A recipient of a body part whose disposition 535 type is 'by-reference' that cannot find any reference to the body 536 part (e.g., the reference was in a header field the recipient does 537 not support and, thus, did not process) MUST NOT process the body 538 part. Consequently, if the handling of the body part was required, 539 the UA needs to report an error. 541 Note that extensions that predate this specifications use 542 references to body parts whose disposition type is not 'by- 543 reference'. Those extensions use option-tags to make sure the 544 recipient understands the whole extension and, thus, cannot miss 545 the reference and attempt to process the body part according to 546 its disposition type alone. 548 8. Guidelines to Authors of SIP Extensions 550 These guidelines are intended for authors of SIP extensions that 551 involve, in some way, message bodies or body parts. These guidelines 552 discuss aspects authors of such extensions need to consider when 553 design them. 555 This specification mandates support for 'multipart/mixed' and 556 'multipart/alternative'. At present, there are no SIP extensions 557 that use different 'multipart' subtypes such as parallel [RFC2046] or 558 digest [RFC2046]. If such extensions were to be defined in the 559 future, their authors would need to make sure (e.g., by using an 560 option-tag or by other means) that entities receiving those 561 'multipart' subtypes were able to process them. As stated earlier, 562 UAs treat unknown 'multipart' subtypes as 'multipart/mixed'. 564 The situation with 'multipart/related' is similar. Per [RFC2387], a 565 UA processing a 'multipart/related' body processes it as a compound 566 object ignoring the disposition types of the body parts within it. 567 However, UAs that do not understand 'multipart/related' will treat it 568 as 'multipart/mixed'. These UAs will not be able to process the body 569 as a compound object. Instead, they will process the body parts 570 according to their disposition type. 572 As stated earlier, SIP extensions may also include 'multipart' MIME 573 bodies in responses. Hence, a response can be extremely complex and 574 the UAC receiving the response might not be able to process it 575 correctly. Because UACs receiving a response cannot report errors to 576 the UAS that generated the response (i.e., error responses can only 577 be generated for requests) authors of SIP extensions need to make 578 sure that requests clearly indicate (e.g., by using an option-tag or 579 by other means) the capabilities of the UAC so that UASs can decide 580 what to include in their responses. 582 9. Security Considerations 584 This document specifies how SIP entities handle message bodies. 585 [RFC3261] discusses what type of information is encoded in SIP 586 message bodies and how SIP entities can protect that information. In 587 addition to the hop-by-hop security SIP can provide, SIP can also 588 secure information in an end-to-end fashion. SIP message bodies can 589 be end-to-end encrypted and integrity protected using S/MIME 590 [RFC3850], as described in [RFC3261] 592 10. Acknowledgements 594 The ideas in this document were discussed with Paul Kyzivat. 595 Christer Holmberg, Francois Audet, and Dan Wing provided comments on 596 it. Dave Crocker performed a thorough review on the whole document. 598 11. IANA Considerations 600 This document defines a new Content-Disposition header field 601 disposition type (by-reference) Section 7.4. This value has been 602 registered in the IANA registry for Content-Dispositions with the 603 following description: 605 by-reference The body needs to be handled according to a 606 reference to the body that is located in 607 the same SIP message as the body. 609 12. References 610 12.1. Normative References 612 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 613 Extensions (MIME) Part One: Format of Internet Message 614 Bodies", RFC 2045, November 1996. 616 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 617 Extensions (MIME) Part Two: Media Types", RFC 2046, 618 November 1996. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 624 Presentation Information in Internet Messages: The 625 Content-Disposition Header Field", RFC 2183, August 1997. 627 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 628 RFC 2387, August 1998. 630 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 631 Locators", RFC 2392, August 1998. 633 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 634 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 635 and QSIG Objects", RFC 3204, December 2001. 637 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 638 A., Peterson, J., Sparks, R., Handley, M., and E. 639 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 640 June 2002. 642 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 643 Extensions (MIME) Parameter", RFC 3459, January 2003. 645 [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail 646 Extensions (S/MIME) Version 3.1 Certificate Handling", 647 RFC 3850, July 2004. 649 [RFC3959] Camarillo, G., "The Early Session Disposition Type for the 650 Session Initiation Protocol (SIP)", RFC 3959, 651 December 2004. 653 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 654 Session Initiation Protocol (SIP) Messages", RFC 4483, 655 May 2006. 657 12.2. Informational References 659 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 660 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 661 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 663 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 664 and D. Gurle, "Session Initiation Protocol (SIP) Extension 665 for Instant Messaging", RFC 3428, December 2002. 667 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 668 Description Protocol", RFC 4566, July 2006. 670 [I-D.ietf-sip-multiple-refer] 671 Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., 672 and H. Khartabil, "Referring to Multiple Resources in the 673 Session Initiation Protocol (SIP)", 674 draft-ietf-sip-multiple-refer-03 (work in progress), 675 December 2007. 677 [I-D.ietf-mmusic-file-transfer-mech] 678 Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., 679 and P. Kyzivat, "A Session Description Protocol (SDP) 680 Offer/Answer Mechanism to Enable File Transfer", 681 draft-ietf-mmusic-file-transfer-mech-06 (work in 682 progress), December 2007. 684 Author's Address 686 Gonzalo Camarillo 687 Ericsson 688 Hirsalantie 11 689 Jorvas 02420 690 Finland 692 Email: Gonzalo.Camarillo@ericsson.com 694 Full Copyright Statement 696 Copyright (C) The IETF Trust (2008). 698 This document is subject to the rights, licenses and restrictions 699 contained in BCP 78, and except as set forth therein, the authors 700 retain all their rights. 702 This document and the information contained herein are provided on an 703 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 704 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 705 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 706 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 707 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 708 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 710 Intellectual Property 712 The IETF takes no position regarding the validity or scope of any 713 Intellectual Property Rights or other rights that might be claimed to 714 pertain to the implementation or use of the technology described in 715 this document or the extent to which any license under such rights 716 might or might not be available; nor does it represent that it has 717 made any independent effort to identify any such rights. Information 718 on the procedures with respect to rights in RFC documents can be 719 found in BCP 78 and BCP 79. 721 Copies of IPR disclosures made to the IETF Secretariat and any 722 assurances of licenses to be made available, or the result of an 723 attempt made to obtain a general license or permission for the use of 724 such proprietary rights by implementers or users of this 725 specification can be obtained from the IETF on-line IPR repository at 726 http://www.ietf.org/ipr. 728 The IETF invites any interested party to bring to its attention any 729 copyrights, patents or patent applications, or other proprietary 730 rights that may cover technology that may be required to implement 731 this standard. Please address the information to the IETF at 732 ietf-ipr@ietf.org. 734 Acknowledgment 736 Funding for the RFC Editor function is provided by the IETF 737 Administrative Support Activity (IASA).