idnits 2.17.1 draft-ietf-sip-body-handling-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 573. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (August 29, 2007) is 6057 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 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 (-03) exists of draft-ietf-sip-multiple-refer-01 == Outdated reference: A later version (-11) exists of draft-ietf-mmusic-file-transfer-mech-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 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 Expires: March 1, 2008 August 29, 2007 6 Message Body Handling in the Session Initiation Protocol (SIP) 7 draft-ietf-sip-body-handling-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 1, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document clarifies how message bodies are handled in SIP. 41 Additionally, it discusses to which degree SIP user agents need to 42 support MIME (Multipurpose Internet Mail Extensions)-encoding of body 43 parts. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Multipart Message Bodies . . . . . . . . . . . . . . . . . . . 3 50 3.1. General Considerations . . . . . . . . . . . . . . . . . . 4 51 3.2. Body Generation . . . . . . . . . . . . . . . . . . . . . 5 52 3.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Message-body and Body-part Disposition . . . . . . . . . . . . 6 54 4.1. Body Generation . . . . . . . . . . . . . . . . . . . . . 7 55 4.2. Body Processing . . . . . . . . . . . . . . . . . . . . . 8 56 4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 57 5. Guidelines to Authors of SIP Extensions . . . . . . . . . . . 9 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 63 9.2. Informational References . . . . . . . . . . . . . . . . . 12 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 Intellectual Property and Copyright Statements . . . . . . . . . . 13 67 1. Introduction 69 SIP [RFC3261] messages consist of an initial line (request line in 70 requests and status line in responses), a set of header fields, and 71 an optional message body. The message body is described using header 72 fields such as Content-Disposition, Content-Encoding, and Content- 73 Type, which provide information on its contents. 75 The message body of a SIP message can be divided into various body 76 parts. Multipart message bodies are encoded using the MIME 77 (Multipurpose Internet Mail Extensions) [RFC2045] format. Body parts 78 are also described using header fields such as Content-Disposition, 79 Content-Encoding, and Content-Type, which provide information on the 80 contents of a particular body part. 82 Section 3 discusses issues related to the handling of multipart 83 message bodies in SIP. Section 4 discusses issues related to the 84 disposition of message bodies and body parts in SIP. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 3. Multipart Message Bodies 94 [RFC3261] did not mandate support for multipart message bodies in 95 MIME format [RFC2046]. However, since [RFC3261] was written, many 96 SIP extensions rely on them. Therefore, this specification updates 97 [RFC3261]'s recommendation regarding support for multipart MIME 98 bodies. 100 It is expected that most SIP UAs will implement extensions that 101 require them to generate 'multipart/mixed' MIME bodies. An example 102 of such an extension would be the inclusion of location information 103 in an INVITE request. Such an INVITE request would use the 104 'multipart/mixed' MIME type to carry two body parts: a session 105 description and a location object. An example of an existing 106 extension that uses 'multipart/mixed' to send a session description 107 and a legacy-signalling object is defined in [RFC3204]. 109 Another MIME type a number of SIP UAs will need to generate is 110 'multipart/alternative'. Each body part within a 'multipart/ 111 alternative' carries an alternative version of the same information. 112 The body parts are ordered so that the last one is the richest 113 representation of the information. This way, the recipient of a 114 'multipart/alternative' body chooses the last body part it 115 understands. 117 Note that within a body part encoded in a given format (i.e., of a 118 given content type), there may be optional elements that may 119 provide richer information to the recipient in case the recipient 120 supports them. For example, in SDP (Session Description Protocol) 121 [RFC4566], those optional elements are encoded in 'a' lines. 122 These types of optional elements are internal to a body part and 123 are not visible at the MIME level. That is, a body part is 124 understood if the recipient understands its content type, 125 regardless of whether or not the body part's optional elements are 126 understood. 128 Note as well that each part of a 'multipart/alternative' body 129 represents the same data, but the mapping between any two parts is 130 not necessarily without information loss. For example, 131 information may be lost when translating 'text/html' to 'text/ 132 plain'. 134 It is expected that the transition from SDP to new session 135 description protocols is implemented using 'multipart/alternative' 136 bodies. SIP messages (e.g., INVITE requests) would carry a 137 'multipart/alternative' body with two body parts: a session 138 description written in SDP and a session description written in a 139 newer session description format. Legacy recipient UAs would use the 140 session description written in SDP. New recipient UAs would use the 141 one written in the newer format. 143 A number of SIP UAs will also need to generate nested MIME bodies. 144 Using the extensions in the previous examples, a UA that supported a 145 new session description format and that needed to include a location 146 object in an INVITE request would include a 'multipart/mixed' body 147 with two body parts: a location object and a 'multipart/alternative'. 148 The 'multipart/alternative' body part would, in turn, have two body 149 parts: a session description written in SDP and a session description 150 written in the newer session description format. 152 3.1. General Considerations 154 For all MIME-based extensions to work, the recipient needs to be able 155 to decode the multipart bodies. Therefore, SIP UAs MUST be able to 156 parse 'multipart' MIME bodies, including nested body parts. In 157 particular, UAs MUST support the 'multipart/mixed' and 'multipart/ 158 alternative' MIME types. Note that, by default, unknown 'multipart' 159 subtypes are treated as 'multipart/mixed'. 161 Note that SIP extensions may also include 'multipart' MIME bodies 162 in responses. That is why both UACs and UASs need to support 163 'multipart' bodies. 165 3.2. Body Generation 167 UAs should avoid unnecessarily nesting body parts. However, 168 [RFC2046] states that a 'multipart' media type with a single body 169 part is useful in some circumstances (e.g., for sending non-text 170 media types). In any case, UAs SHOULD NOT nest one 'multipart/mixed' 171 within another unless there is a need to reference the nested one 172 (i.e., using the Content ID of the nested body part). Additionally, 173 UAs SHOULD NOT nest one 'multipart/alternative' within another. 175 All the body parts within a 'multipart/alternative' have the same 176 disposition type (see Section 4.1). Some disposition types require 177 that all the body parts of a 'multipart/alternative' body have 178 different content types. In particular, for the 'session' and 179 'early-session' [RFC3959] disposition types, UAs MUST NOT place more 180 than one body part with a given content type in a 'multipart/ 181 alternative' body. That is, for 'session' and 'early-session', no 182 body part within a 'multipart/alternative' can have the same content 183 type as another body part within the same 'multipart/alternative'. 185 As stated earlier, the mapping between two body parts within a 186 'multipart/alternative' body may imply information loss. [RFC2046] 187 recommends that each part should have a different Content-ID value in 188 the case where the information content of the two parts is not 189 identical. 191 A body part can only reference another body part if both are within 192 the same 'multipart/related' wrapper. Therefore, UAs MUST ensure 193 that any given body part only references body parts within its 194 'multipart/related' wrapper. 196 UAs MUST use the binary transfer encoding for binary payloads in SIP. 198 3.3. UAS Behavior 200 Section 3.1 mandates that all UAs support 'multipart' bodies. 201 However, if a particular UAS does not support 'multipart' bodies and 202 receives one, the UAS SHOULD return a 415 (Unsupported Media Type) 203 response. 205 Note that it is essential that UASs without MIME support are at 206 least able to return an error response when receiving a 207 'multipart' body. Not being able to signal this type of error 208 could cause serious interoperability problems. Legacy UASs 209 without MIME support that, for some reason, cannot be immediately 210 upgraded to support MIME, should at least be upgraded to be able 211 to report this error. 213 As specified in [RFC3261], UASs that cannot decrypt a message body or 214 a body part can use the 493 (Undecipherable) response to report the 215 error. 217 4. Message-body and Body-part Disposition 219 The Content-Disposition header field, defined in [RFC2183] and 220 extended by [RFC3261], describes how to handle a SIP message's body 221 or an individual body part. Examples of disposition types used in 222 SIP in the Content-Disposition header field are 'session' and 223 'render'. 225 [RFC3204] and [RFC3459] define the 'handling' parameter for the 226 Content-Disposition header field. This parameter describes how a UAS 227 should react if it receives a message body whose content type or 228 disposition type it does not understand. If the parameter has the 229 value 'optional', the UAS ignores the message body; if it has the 230 value 'required', the UAS returns a 415 (Unsupported Media Type) 231 response. The default value for the 'handling' parameter is 232 'required'. 234 [RFC3204] identifies two situations where a UAS (User Agent Server) 235 needs to reject a request with a body part whose handling is 236 required: 238 1. if it has an unknown content type. 239 2. if it has an unknown disposition type. 241 If the UAS (User Agent Server) did not understand the content type of 242 the body part, it can add an Accept header field to its 415 243 (Unsupported Media Type) response listing the content types that the 244 UAS does understand. Nevertheless, there is no mechanism for a UAS 245 that does not understand the disposition type of a body part to 246 inform the UAC (User Agent Client) about which disposition type was 247 not understood or about the disposition types that are understood by 248 the UAS. 250 The reason for not having such a mechanism is that disposition types 251 are typically supported within a context. Outside that context, a UA 252 (User Agent) may not support the disposition type. For example, a UA 253 may support the 'session' disposition type for body parts in INVITE 254 and UPDATE requests and their responses. However, the same UA would 255 not support the 'session' disposition type in MESSAGE requests. 257 In another example, a UA may support the 'render' disposition type 258 for 'text/plain' and 'text/html' body parts in MESSAGE requests. 259 Additionally, the UA may support the 'session' disposition type for 260 'application/sdp' body parts in INVITE and UPDATE requests and their 261 responses. However, the UA may not support the 'render' disposition 262 type for 'application/sdp' body parts in MESSAGE requests, even if, 263 in different contexts, the UA supported all the 'render' disposition 264 type, the 'application/sdp' content type, and the MESSAGE method. 266 A given context is generally (but not necessarily) defined by a 267 method, a disposition type, and a content type. Support for a 268 specific context is usually defined within an extension. For 269 example, the extension for instant messaging in SIP [RFC3428] 270 mandates support for the MESSAGE method, the 'render' disposition 271 type, and the 'text/plain' content type. 273 Note that, effectively, content types are also supported within a 274 context. Therefore, the use of the Accept header field in a 415 275 (Unsupported Media Type) response is not enough to describe in 276 which contexts a particular content type is supported. 278 Therefore, support for a particular disposition type within a given 279 context is typically signalled by the use of a particular method or 280 an option-tag in a Supported or a Require header field. When support 281 for a particular disposition type within a context is mandated, 282 support for a default content type is also mandated (e.g., a UA that 283 supports the 'session' disposition type in an INVITE request needs to 284 support the 'application/sdp' content type). 286 Content-ID URLs (Uniform Resource Locators) are another tool to 287 describe how a body part should be handled. Some extensions use a 288 Content-ID URL [RFC2392], which can appear in a header field or 289 within a body part (e.g., in an SDP attribute), that points to a body 290 part. The way to handle that body part is defined by the field the 291 Content-ID URL appears in and by the disposition type of the body 292 part. For example, the extension to refer to multiple resources in 293 SIP [I-D.ietf-sip-multiple-refer] places a Content-ID URL in a 294 Refer-To header field. Such a Content-ID URL points to a body part 295 whose disposition type is supposed to be 'recipient-list'. In 296 another example, the extension for file transfer in SDP 297 [I-D.ietf-mmusic-file-transfer-mech] places a Content-ID URL in a 298 'file-icon' SDP attribute. This Content-ID URL points to a body part 299 whose disposition type is supposed to be 'icon'. 301 4.1. Body Generation 303 As stated earlier, the 'handling' Content-Disposition parameter can 304 take two values: 'required' or 'optional'. While it is typically 305 easy for a UA to decide which type of handling an individual body 306 part requires, setting the 'handing' parameter of 'multipart' bodies 307 requires extra considerations. 309 If at least one of the body parts within a 'multipart/mixed' body has 310 a 'handling' value of 'required', the UA MUST set the 'handling' 311 parameter of the 'multipart/mixed' body to 'required'. If all the 312 body parts within a 'multipart/mixed' body have a 'handling' value of 313 'optional', the UA MUST set the 'handling' parameter of the 314 'multipart/mixed' body to 'optional'. 316 The 'handling' parameter is a Content-Disposition parameter. 317 Therefore, in order to set this parameter, it is necessary to provide 318 the 'multipart/mixed' body with a disposition type. Per [RFC3261], 319 the default disposition type for 'application/sdp' is 'session' and 320 for other bodies is 'render'. UAs SHOULD assign 'multipart/mixed' 321 bodies a disposition type of 'render'. 323 Note that the fact that 'multipart/mixed' bodies have a 324 disposition type of 'render' does not imply that they will be 325 rendered to the user. The way the body parts within the 326 'multipart/mixed' are handled depends on the disposition types of 327 the individual body parts. The actual disposition type of the 328 whole 'multipart/mixed' is irrelevant. The 'render' disposition 329 type has been chosen for 'multipart/mixed' bodies simply because 330 it is the default disposition type in SIP. 332 If the handling of a 'multipart/alternative' body is required, the UA 333 MUST set the 'handling' parameter of the 'multipart/alternative' body 334 and to the last body part within the 'multipart/alternative' to 335 'required'. Additionally, the UA MUST set the 'handling' parameter 336 of all body parts within the 'multipart/alternative' except the last 337 one to 'optional'. The UA MUST use the same disposition type for the 338 'multipart/alternative' body and all its body parts. 340 4.2. Body Processing 342 In order to process a message body or a body part, a UA needs to know 343 whether a SIP header field or another body part contains a reference 344 to it (e.g., a Content-ID URL pointing to it). If the body part is 345 not referenced in any way (e.g., there are no header fields or other 346 body parts with a Content-ID URL pointing to it), the UA processes 347 the body part as indicated by its disposition type and the context in 348 which the body part was received. 350 If the SIP message contains a reference to the body part, the UA 351 processes the body part according to the reference and the 352 disposition type of the body part. If the SIP message contains more 353 than one reference to the body part (e.g., two header fields contain 354 Content-ID URLs pointing to the body part), the UA processes the body 355 part as many times as references there are. 357 A UA looking for references to a body part starts by parsing the SIP 358 message's header fields. Additionally, if the body part is within a 359 'multipart/related' [RFC2387] wrapper, the body parts within the 360 'multipart/related' wrapper may reference each other. Therefore, the 361 UA processes the body parts in the 'multipart/related', starting with 362 its 'root', looking for references to the body part. 364 Note that, per [RFC2387], a UA processing a 'multipart/related' 365 body processes it as a compound object ignoring the disposition 366 types of the body parts within it. 368 Following the rules in [RFC3204], if a UA does not understand a body 369 part whose handling is optional, it ignores it. 371 Note that the content indirection mechanism in SIP [RFC4483] 372 allows UAs to point to external bodies. Therefore, a UA receiving 373 a SIP message that uses content indirection may need to fetch a 374 body part (e.g., using HTTP [RFC2616]) in order to process it. 376 4.3. UAS Behavior 378 If a UAS cannot process a request because, in the given context, it 379 does not support the content type or the disposition type of a body 380 part whose handling is required, the UAS SHOULD return a 415 381 (Unsupported Media Type) response even if the UAS supported the 382 content type, the disposition type, or both in a different context. 384 Consequently, it is possible to receive a 415 (Unsupported Media 385 Type) response with an Accept header field containing all the 386 content types used in the request. 388 If a UAS receives a request with a body part whose disposition type 389 is not compatible with the way the body part should be handled 390 according to other parts of the SIP message (e.g., a Refer-To header 391 field with a Content-ID URL pointing to a body part whose disposition 392 type is 'session'), the UAS SHOULD return a 415 (Unsupported Media 393 Type) response. 395 5. Guidelines to Authors of SIP Extensions 397 These guidelines are intended for authors of SIP extensions that 398 involve, in some way, message bodies or body parts. 400 This specification mandates support for 'multipart/mixed' and 401 'multipart/alternative' and describes how to handle 'multipart/ 402 related' [RFC2387] bodies. At present, there are no SIP extensions 403 that use different 'multipart' subtypes such as parallel [RFC2046] or 404 digest [RFC2046]. If such extensions were to be defined in the 405 future, their authors would need to make sure (e.g., by using an 406 option-tag or by other means) that entities receiving those 407 'multipart' subtypes were able to process them. As stated earlier, 408 UAs treat unknown 'multipart' subtypes as 'multipart/mixed'. 410 Body parts within a 'multipart/related' wrapper can reference each 411 other. Per [RFC2387], a UA processing a 'multipart/related' body 412 processes it as a compound object ignoring the disposition types of 413 the body parts within it. However, UAs that do not understand 414 'multipart/related' will treat it as 'multipart/mixed'. These UAs 415 will not be able to process the references among the body parts and 416 will process the body parts according to their disposition type. 418 When a SIP UA receives a header field or an optional body part it 419 does not understand, the UA ignores it. A header field or a body 420 part carrying a reference to another body part (e.g., a Content-ID 421 URL) can influence the way that body part is handled. If a header 422 field or a body part carrying a reference to a body part is not 423 understood and, thus, ignored by its recipient, the body part could 424 be handled in an unintended way. Therefore, authors of SIP 425 extensions that involve references to body parts need to make sure 426 (e.g., by using an option-tag or by other means) that entities 427 processing those extensions do not behave in unintended ways. 429 Additionally, authors of such extensions need to specify the 430 acceptable disposition types of the referenced body part and a 431 default, mandatory to support, content type per disposition type. 433 As stated earlier, SIP extensions may also include 'multipart' MIME 434 bodies in responses. However, UACs receiving a response cannot 435 report errors to the UAS that generated the response (i.e., error 436 responses can only be generated for requests). Therefore, authors of 437 SIP extensions need to make sure that requests clearly indicate 438 (e.g., by using an option-tag or by other means) the capabilities of 439 the UAC so that UASs can decide what to include in their responses. 441 6. Security Considerations 443 TBD. 445 7. Acknowledgements 447 The ideas in this document were discussed with Paul Kyzivat. 448 Christer Holmberg, Francois Audet, and Dan Wing provided comments on 449 this document. 451 8. IANA Considerations 453 This document does not contain any IANA actions. 455 9. References 457 9.1. Normative References 459 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 460 Extensions (MIME) Part One: Format of Internet Message 461 Bodies", RFC 2045, November 1996. 463 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 464 Extensions (MIME) Part Two: Media Types", RFC 2046, 465 November 1996. 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 471 Presentation Information in Internet Messages: The 472 Content-Disposition Header Field", RFC 2183, August 1997. 474 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 475 RFC 2387, August 1998. 477 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 478 Locators", RFC 2392, August 1998. 480 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 481 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 482 and QSIG Objects", RFC 3204, December 2001. 484 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 485 A., Peterson, J., Sparks, R., Handley, M., and E. 486 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 487 June 2002. 489 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail 490 Extensions (MIME) Parameter", RFC 3459, January 2003. 492 [RFC3959] Camarillo, G., "The Early Session Disposition Type for the 493 Session Initiation Protocol (SIP)", RFC 3959, 494 December 2004. 496 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 497 Session Initiation Protocol (SIP) Messages", RFC 4483, 498 May 2006. 500 9.2. Informational References 502 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 503 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 504 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 506 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 507 and D. Gurle, "Session Initiation Protocol (SIP) Extension 508 for Instant Messaging", RFC 3428, December 2002. 510 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 511 Description Protocol", RFC 4566, July 2006. 513 [I-D.ietf-sip-multiple-refer] 514 Camarillo, G., "Referring to Multiple Resources in the 515 Session Initiation Protocol (SIP)", 516 draft-ietf-sip-multiple-refer-01 (work in progress), 517 January 2007. 519 [I-D.ietf-mmusic-file-transfer-mech] 520 Garcia-Martin, M., "A Session Description Protocol (SDP) 521 Offer/Answer Mechanism to Enable File Transfer", 522 draft-ietf-mmusic-file-transfer-mech-03 (work in 523 progress), June 2007. 525 Author's Address 527 Gonzalo Camarillo 528 Ericsson 529 Hirsalantie 11 530 Jorvas 02420 531 Finland 533 Email: Gonzalo.Camarillo@ericsson.com 535 Full Copyright Statement 537 Copyright (C) The IETF Trust (2007). 539 This document is subject to the rights, licenses and restrictions 540 contained in BCP 78, and except as set forth therein, the authors 541 retain all their rights. 543 This document and the information contained herein are provided on an 544 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 545 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 546 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 547 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 548 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 549 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 551 Intellectual Property 553 The IETF takes no position regarding the validity or scope of any 554 Intellectual Property Rights or other rights that might be claimed to 555 pertain to the implementation or use of the technology described in 556 this document or the extent to which any license under such rights 557 might or might not be available; nor does it represent that it has 558 made any independent effort to identify any such rights. Information 559 on the procedures with respect to rights in RFC documents can be 560 found in BCP 78 and BCP 79. 562 Copies of IPR disclosures made to the IETF Secretariat and any 563 assurances of licenses to be made available, or the result of an 564 attempt made to obtain a general license or permission for the use of 565 such proprietary rights by implementers or users of this 566 specification can be obtained from the IETF on-line IPR repository at 567 http://www.ietf.org/ipr. 569 The IETF invites any interested party to bring to its attention any 570 copyrights, patents or patent applications, or other proprietary 571 rights that may cover technology that may be required to implement 572 this standard. Please address the information to the IETF at 573 ietf-ipr@ietf.org. 575 Acknowledgment 577 Funding for the RFC Editor function is provided by the IETF 578 Administrative Support Activity (IASA).