idnits 2.17.1 draft-ietf-sip-content-indirect-mech-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 2, 2003) is 7628 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 590, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (ref. '3') (Obsoleted by RFC 3986) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '7') Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP S. Olson 3 Internet-Draft Microsoft 4 Expires: December 1, 2003 June 2, 2003 6 A Mechanism for Content Indirection in Session Initiation Protocol 7 (SIP) Messages 8 draft-ietf-sip-content-indirect-mech-03 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on December 1, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document proposes an extension to the URL MIME External- Body 39 Access-Type to satisfy the content indirection requirements for SIP. 40 These extensions are aimed at allowing any MIME part in a SIP message 41 to be referred to indirectly via a URI. 43 Table of Contents 45 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. Example Use Cases . . . . . . . . . . . . . . . . . . . . . 6 48 3.1 Presence Notification . . . . . . . . . . . . . . . . . . . 6 49 3.2 Document Sharing . . . . . . . . . . . . . . . . . . . . . . 7 50 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 51 5. Application of RFC2017 to the Content Indirection Problem . 9 52 5.1 Specifying support for content indirection . . . . . . . . . 9 53 5.2 Mandatory support for HTTP URI . . . . . . . . . . . . . . . 9 54 5.3 Rejecting content indirection . . . . . . . . . . . . . . . 9 55 5.4 Specifying the location of the content via a URI . . . . . . 9 56 5.5 Specifying versioning information for the URI . . . . . . . 10 57 5.6 Specifying the lifetime of the URI . . . . . . . . . . . . . 10 58 5.7 Specifying the type of the indirect content . . . . . . . . 10 59 5.8 Specifying the size of the indirect content . . . . . . . . 11 60 5.9 Specifying the purpose of the indirect content . . . . . . . 11 61 5.10 Specifying multiple URIs for content indirection . . . . . . 12 62 5.11 Supplying additional comments about the indirect content . . 12 63 5.12 Relationship to Call-Info, Error-Info, and Alert-Info 64 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 6.1 Single Content Indirection . . . . . . . . . . . . . . . . . 14 67 6.2 Multipart MIME with Content Indirection . . . . . . . . . . 14 68 7. Security Considerations . . . . . . . . . . . . . . . . . . 16 69 References . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 71 Intellectual Property and Copyright Statements . . . . . . . 18 73 1. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [1]. 79 2. Introduction 81 The purpose of the Session Initiation Protocol [2] (SIP) is to 82 create, modify, or terminate sessions with one or more participants. 83 SIP messages, like HTTP, are sytnactically composed of a start line, 84 one or more headers, and an optional body. Unlike HTTP, SIP is not 85 designed as a general purpose transport of data. 87 There are numerous reasons why it might be desirable to indirectly 88 specify the content of the SIP message body. For bandwidth limited 89 applications such as cellular wireless, indirection provides a means 90 to annotate the (indirect) content with meta-data which may be used 91 by the recipient to determine whether or not to retrieve the content 92 over the resource limited link. 94 It is also possible that the content size to be transferred might 95 potentially overwhelm intermediate signaling proxies, thereby 96 unnecessarily increasing network latency. For time-sensitive SIP 97 applications, this may be unacceptable. Indirect content can remedy 98 this by moving the transfer of this content out of the SIP signaling 99 network and into a potentially separate data transfer channel. 101 There may also be scenarios where the session related data (body) 102 that needs to be conveyed does not directly reside on the endpoint or 103 User Agent. In such scenarios, it is desirable to have a mechanism 104 whereby the SIP message can contain an indirect reference to the 105 desired content. The receiving party would then use this indirect 106 reference to retrieve the content via a non-SIP transfer channel such 107 as HTTP, FTP, or LDAP. 109 The purpose of content indirection is purely to provide an 110 alternative transport mechanism for SIP MIME body parts. With the 111 exception of the transport mechanism, indirected body parts are 112 equivalent, and should have the same treatment, as in-line body 113 parts. 115 Previous attempts at solving the content indirection problem made use 116 of the text/uri-list [7] MIME type. While attractive for its 117 simplicity (a list of URIs delimted by end-of-line markers), it fails 118 to satisfy a number of the requirements for a more general purpose 119 content indirection mechanism in SIP. Most notably lacking is the 120 ability to specify various attributes on a per-URI basis. These 121 attributes might include version information, the MIME type of the 122 referenced content, etc. 124 In searching for a replacement for the text/uri-list MIME type, 125 RFC2017 defines a strong candidate. RFC2017 defines an extension to 126 the message/external-body MIME type originally defined in RFC2046 128 [5]. The extension that RFC2017 makes is to allow a generic URI to 129 specify the location of the content rather than protocol specific 130 parameters for FTP, etc. as originally defined in RFC2046. While 131 providing most of the functionality needed for a SIP content 132 indirection mechanism, RFC2017 by itself is not a complete solution. 133 This document will specify the usage of RFC2017 necessary to fulfill 134 the requirments outlined for content indirection. 136 The requirements can be classified as applying either to the URI 137 which indirectly references the desired content or to the content 138 itself. Where possible, existing MIME parameters and entity headers 139 will be used to satisfy those requirements. MIME (Content-Type) 140 parameters will be the preferred manner of describing the URI while 141 entity headers will be the preferred manner of describing the 142 (indirect) content. See RFC 2045 [4] for a description of most of 143 these entity headers and MIME parameters. 145 3. Example Use Cases 147 There are several example users of such a content indirection 148 mechanism. These are examples only and are not intended to limit the 149 scope or applicability of the mechanism. 151 3.1 Presence Notification 153 The information carried in a presence document could potentially 154 exceed the recommended size for a SIP (NOTIFY) request, particularly 155 if the document carries aggregated information from multiple 156 endpoints. In such a situation, it would be desirable to send the 157 NOTIFY request with an indirect pointer to the presence document 158 which could then be retrieved by, for example, HTTP. 160 Figure 1: Example information flow for presence notification 162 Watcher Presence Server 163 | | 164 | SUBSCRIBE | 165 |-------------------------->| 166 | 200 OK | 167 |<--------------------------| 168 | | 169 | NOTIFY | 170 |-------------------------->| 171 | 200 OK | 172 |<--------------------------| 173 | | 174 | NOTIFY (w/URI) | 175 |<--------------------------| 176 | 200 | 177 |-------------------------->| 178 | | 179 | HTTP GET | 180 |-------------------------->| 181 | | 182 | application/cpim-pidf+xml | 183 |<--------------------------| 184 | | 186 In this example, the presence server returns an HTTP URI pointing to 187 a presence document on the presence server which the watcher can then 188 fetch using an HTTP GET. 190 3.2 Document Sharing 192 During an instant messaging conversation, a useful service is 193 document sharing wherein one party sends an IM (MESSAGE request) with 194 an indirect pointer to a document which is meant to be rendered by 195 the remote party. Carrying such a document directly in the MESSAGE 196 request is not appropriate for most documents. Furthermore, the 197 document to be shared may reside on a completely independent server 198 from the originating party. 200 Figure 2: Example information flow for document sharing 202 UAC UAS Web Server 203 | | | 204 | MESSAGE w/URI | | 205 |------------------->| | 206 | 200 | | 207 |<-------------------| | 208 | | | 209 | | HTTP GET | 210 | |--------------->| 211 | | image/jpeg | 212 | |<---------------| 213 | | | 215 In this example, a user wishes to exchange a JPEG image that she has 216 stored on her web server with another user she has a IM conversation 217 with. The JPEG is intended to be rendered inline in the IM 218 conversation. The recepient of the MESSAGE request launches a HTTP 219 GET request to the web server to retrieve the JPEG image. 221 4. Requirements 223 It MUST be possible to specify the location of content via a URI 224 [3]. 226 It MUST be possible to specify the length of the indirect content. 228 It MUST be possible to specify the type of the indirect content. 230 It MUST be possible to specify the disposition of each URI 231 independently. 233 It MUST be possible to label each URI to identify if and when the 234 content referred to by that URI has changed. Applications of this 235 mechanism may send the same URI more than once. The intention of 236 this requirement is to allow the receiving party to determine if 237 the content referenced by the URI has changed without having to 238 actually retrieve that content. Example ways the URI could be 239 labelled include a sequence number, timestamp, version number, 240 etc. 242 It MUST be possible to specify the timespan for which a given URI 243 is valid. This may or may not be the same as the lifetime for the 244 content itself. 246 It MUST be possible for the UAC and the UAS to indicate support of 247 this content indirection mechanism. A fallback mechanism SHOULD be 248 specified in the event that one of the parties is unable to 249 support content indirection. 251 It MUST be possible for the UAC and UAS to negotiate the type of 252 the indirect content when using the content indirection mechanism. 254 It MUST be possible for the UAC and UAS to negotiate support for 255 URI scheme(s) to be used in the content indirection mechanism. 256 This is in addition to the ability to negotiate the content type. 258 It SHOULD be possible to ensure the integrity and privacy of the 259 URI when it is received by the remote party. 261 It MUST be possible to process the content indirection without 262 human intervention. 264 It MUST allow for indirect transference of content in any SIP 265 message which would otherwise carry that content as a body. 267 5. Application of RFC2017 to the Content Indirection Problem 269 The following text describes the application of RFC2017 to the 270 requirements for content indirection. 272 5.1 Specifying support for content indirection 274 A UAC/UAS may indicate support for content indirection through an 275 Accept header containing the message/external-body MIME type. The 276 UAC/UAS must supply additional values in the Accept header to 277 indicate the content types that it is willing to accept either 278 directly or through content indirection. User-Agents supporting 279 content indirection MUST support content indirection of the 280 application/sdp MIME type. 282 For example: 284 Accept: message/external-body, image/*, application/sdp 286 5.2 Mandatory support for HTTP URI 288 Applications which use this content indirection mechanism MUST 289 support at least the HTTP URI scheme. Additional URI schemes MAY be 290 used, but a UAC/UAS MUST support receiving a HTTP URI for indirect 291 content if it advertises support for content indirection. 293 The intention is to establish a baseline of support to further 294 strengthen interoperability. Implementors may design for the most 295 common case (HTTP) without having to worry about negotiation of 296 support for this particular URI scheme. 298 5.3 Rejecting content indirection 300 If a UAS receives a SIP request which contains a content indirection 301 payload, and the UAS cannot or does not wish to support such a 302 content type, it MUST reject the request with a 415 Unsupported Media 303 Type response as defined in section 21.4.13 of SIP [2]. In 304 particular, the UAC should note the absence of the message/ 305 external-body MIME type in the Accept header of this response to 306 indicate that the UAS does not support content indirection. 308 5.4 Specifying the location of the content via a URI 310 The URI for the indirect content is specified in a "URI" parameter of 311 the message/external-body MIME type. An access-type parameter 312 indicates that the external content is referenced by a URI. 314 For example: 316 Content-Type: message/external-body; 317 access-type="URL"; 318 URL="http://www.volcano.com/the-indirect-content" 320 5.5 Specifying versioning information for the URI 322 In order to determine whether or not the content indirectly 323 referenced by the URI has changed, a Content-ID entity header is 324 used. The syntax of this header is defined in RFC2045 [4]. Changes in 325 the underlying content referred to by a URI MUST result in a change 326 in the Content-ID associated with that URI. Multiple SIP messages 327 carrying URI that refer to the same content SHOULD reuse the same 328 Content-ID to allow the receiver to cache this content and avoid 329 unnecessary retrievals. The Content-ID is intended to be globally 330 unique and SHOULD be temporally unique across SIP dialogs. 332 For example: 334 Content-ID: <4232423424@www.volcano.com> 336 5.6 Specifying the lifetime of the URI 338 The URI supplied by in Content-Type header is not required to be 339 accessible or valid for an indefinite period of time. Rather, the 340 supplier of the URI MUST specify the time period for which this URI 341 is valid and accessible. This is done through an "EXPIRATION" 342 parameter of the Content-Type. The format of this expiration 343 parameter is a RFC1123 date-time value. This is further restricted 344 in this application to use only GMT time, consistent with the Date: 345 header in SIP. This is a mandatory parameter. Note that the 346 date-time value can range from minutes to days or even years. 348 For example: 350 Content-Type: message/external-body; 351 expiration="Mon, 24 June 2002 09:00:00 GMT" 353 5.7 Specifying the type of the indirect content 355 To support existing SIP mechanisms for the negotiation of content 356 types, a Content-Type entity header SHOULD be present in the entity 357 (payload) itself. If the protocol (scheme) of the URI supports its 358 own content negotiation mechanisms (e.g. HTTP), this header may be 359 omitted. The sender MUST however be prepared for the receiving party 360 to reject content indirection if the receiver is unable to negotiate 361 an appropriate MIME type using the underlying protocol for the URI 362 scheme. 364 For example: 366 Content-Type: message/external-body; access-type="URL"; 367 expiration="Mon, 24 June 2002 09:00:00 GMT"; 368 URL="http://www.volcano.com/the-indirect-content" 369 370 Content-Type: application/sdp 371 373 5.8 Specifying the size of the indirect content 375 When known in advance, the size of the indirect content should be 376 supplied via a size parameter on the Content-Type header. This is an 377 extension of RFC2017 but in line with other access types defined for 378 the message/external-body MIME type in RFC2046. The content size is 379 useful for the receiving party to make a determination about whether 380 or not to retrieve the content. As with directly supplied content, a 381 UAS may return a 513 error response in the event the content size is 382 too large. This is an optional parameter. 384 For example: 386 Content-Type: message/external-body; access-type="URL"; 387 expiration="Mon, 24 June 2002 09:00:00 GMT"; 388 URL="http://www.volcano.com/the-indirect-content"; 389 size=4123 391 5.9 Specifying the purpose of the indirect content 393 A Content-Disposition entity header SHOULD be present for all 394 indirect content. In the absence of an an explicit 395 Content-Disposition header, a content disposition of "session" should 396 be assumed. 398 For example: 400 Content-Type: message/external-body; access-type="URL"; 401 expiration="Mon, 24 June 2002 09:00:00 GMT"; 402 URL="http://www.volcano.com/the-indirect-content" 403 404 Content-Type: image/jpeg 405 Content-Disposition: render 407 5.10 Specifying multiple URIs for content indirection 409 If there is a need to send multiple URIs for the purpose of content 410 indirection, an appropriate multipart MIME type [5] should be used. 411 Each URI should be contained in a single entity. Indirect content may 412 be mixed with directly supplied content. This is particularly useful 413 with the multipart/alternative MIME type. 415 For example: 417 MIME-Version: 1.0 418 Content-Type: multipart/mixed; boundary=boundary42 420 --boundary42 421 Content-Type: text/plain; charset=us-ascii 423 The company announcement for June, 2002 follows: 424 --boundary42 425 Content-Type: message/external-body; 426 access-type="URL"; 427 expiration="Mon, 24 June 2002 09:00:00 GMT"; 428 URL="http://www.volcano.com/announcements/07242002"; 429 size=4123 431 Content-Type: text/html 432 Content-Disposition: render 434 --boundary42-- 436 5.11 Supplying additional comments about the indirect content 438 Optional, freeform text may be supplied to comment on the indirect 439 content. This should be supplied in a Content-Description entity 440 header. 442 For example: 444 Content-Type: message/external-body; 445 access-type="URL"; 446 expiration="Mon, 24 June 2002 09:00:00 GMT"; 447 URL="http://www.volcano.com/the-indirect-content"; 448 size=52723 449 450 Content-Description: Multicast gaming session 452 5.12 Relationship to Call-Info, Error-Info, and Alert-Info Headers 454 SIP [2] defines three headers which are used to supply additional 455 information with regard to a session, a particular error response, or 456 alerting. All three of these headers allow the UAC or UAS to indicate 457 additional information through a URI. They may be considered a form 458 of content indirection. The content indirection mechanism defined in 459 this document is not intended as a replacement for these headers. 460 Rather, the headers defined in SIP MUST be used in preference to this 461 mechanism where applicable because of the well defined semantics of 462 those headers. 464 6. Examples 466 6.1 Single Content Indirection 468 INVITE sip:boromir@volcano.com SIP/2.0 469 From: ;tag=347242 470 To: 471 Call-ID: 3573853342923422@nwt.com 472 CSeq: 2131 INVITE 473 Accept: message/external-body application/sdp 474 Content-Type: message/external-body; 475 ACCESS-TYPE=URL; 476 URL="http://www.nwt.com/party/06/2002/announcement"; 477 EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT" 478 size=231 479 Content-Length: ... 481 Content-Type: application/sdp 482 Content-Disposition: session 483 Content-ID: <4e5562cd1214427d@nwt.com> 485 6.2 Multipart MIME with Content Indirection 487 MESSAGE sip:boromir@volcano.com SIP/2.0 488 From: ;tag=34589882 489 To: 490 Call-ID: 9242892442211117@nwt.com 491 CSeq: 388 MESSAGE 492 Accept: message/external-body, text/html, text/plain, image/*, text/x-emoticon 493 MIME-Version: 1.0 494 Content-Type: multipart/mixed; boundary=zz993453 496 --zz993453 497 Content-Type: message/external-body; 498 access-type="URL"; 499 expiration="Mon, 24 June 2002 09:00:00 GMT"; 500 URL="http://www.nwt.com/company_picnic/image1.png" 501 size=234422 503 Content-Type: image/png 504 Content-ID: <9535035333@nwt.com> 505 Content-Disposition: render 506 Content-Description: Kevin getting dunked in the wading pool 507 --zz993453 508 Content-Type: message/external-body; 509 access-type="URL"; 510 expiration="Mon, 24 June 2002 09:00:00 GMT"; 511 URL="http://www.nwt.com/company_picnic/image2.png" 512 size=233811 514 Content-Type: image/png 515 Content-ID: <1134299224244@nwt.com> 516 Content-Disposition: render 517 Content-Description: Peter on his tricycle 519 --zz993453-- 521 7. Security Considerations 523 Any content indirection mechanism introduces additional security 524 concerns. By its nature, content indirection requires an extra 525 processing step and information transfer. There are a number of 526 potential abuses of a content indirection mechanism: 528 Content indirection allows the initiator to choose an alternative 529 protocol with weaker security or known vulnerabilities for the 530 content transfer. For example, asking the recipient to issue an 531 HTTP request which results in a Basic authentication challenge. 533 Content indirection allows the initiator to ask the recipient to 534 consume additional resources in the information transfer and 535 content processing, potentially creating an avenue for denial of 536 service attacks. For example, an active FTP URL consuming 2 537 connections for every indirect content message. 539 Content indirection could be used as a form of port scanning 540 attack where the indirect content URL is actually a bogus URL 541 pointing to an internal resource of the recipient. The response to 542 the content indirection request could reveal information about 543 open (and vulnerable) ports on these internal resources. 545 A content indirection URL can disclose sensitive information about 546 the initiator such as an internal user name (as part of an HTTP 547 URL) or possibly geolocation information. 549 Fortunately, all of these potential threats can be mitigated through 550 careful screening of both the indirect content URIs that are received 551 as well as those that are sent. Integrity and privacy protection of 552 the indirect content URI can prevent additional attacks as well. 554 For confidentiality, integrity, and authentication, this content 555 indirection mechanism relies on the security mechanisms outlined in 556 RFC3261. In particular, the usage of S/MIME as defined in section 23 557 of RFC3261 provides the necessary mechanism to ensure integrity 558 protection and privacy of the indirect content URI and associated 559 parameters. 561 Securing the transfer of the indirect content is the responsibility 562 of the underlying protocol used for this transfer. It is RECOMMENDED 563 that applications implementing this content indirection method 564 support the HTTPS URI scheme for secure transfer of content. 566 Access control to the content referenced by the URI is not defined by 567 this specification. Access control mechanisms may be defined by the 568 protocol for the scheme of the indirect content URI. 570 References 572 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 573 Levels", BCP 14, RFC 2119, March 1997. 575 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 576 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 577 Session Initiation Protocol", RFC 3261, June 2002. 579 [3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 580 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 582 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 583 Extensions (MIME) Part One: Format of Internet Message Bodies", 584 RFC 2045, November 1996. 586 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 587 Extensions (MIME) Part Two: Media Types", RFC 2046, November 588 1996. 590 [6] Freed, N. and K. Moore, "Definition of the URL MIME 591 External-Body Access-Type", RFC 2017, October 1996. 593 [7] Daniel, R., "A Trivial Convention for using HTTP in URN 594 Resolution", RFC 2169, June 1997. 596 Author's Address 598 Sean Olson 599 Microsoft 600 One Microsoft Way 601 Redmond, WA 98052 602 US 604 Phone: +1-425-707-2846 605 EMail: seanol@microsoft.com 606 URI: http://www.microsoft.com/rtc 608 Intellectual Property Statement 610 The IETF takes no position regarding the validity or scope of any 611 intellectual property or other rights that might be claimed to 612 pertain to the implementation or use of the technology described in 613 this document or the extent to which any license under such rights 614 might or might not be available; neither does it represent that it 615 has made any effort to identify any such rights. Information on the 616 IETF's procedures with respect to rights in standards-track and 617 standards-related documentation can be found in BCP-11. Copies of 618 claims of rights made available for publication and any assurances of 619 licenses to be made available, or the result of an attempt made to 620 obtain a general license or permission for the use of such 621 proprietary rights by implementors or users of this specification can 622 be obtained from the IETF Secretariat. 624 The IETF invites any interested party to bring to its attention any 625 copyrights, patents or patent applications, or other proprietary 626 rights which may cover technology that may be required to practice 627 this standard. Please address the information to the IETF Executive 628 Director. 630 Full Copyright Statement 632 Copyright (C) The Internet Society (2003). All Rights Reserved. 634 This document and translations of it may be copied and furnished to 635 others, and derivative works that comment on or otherwise explain it 636 or assist in its implementation may be prepared, copied, published 637 and distributed, in whole or in part, without restriction of any 638 kind, provided that the above copyright notice and this paragraph are 639 included on all such copies and derivative works. However, this 640 document itself may not be modified in any way, such as by removing 641 the copyright notice or references to the Internet Society or other 642 Internet organizations, except as needed for the purpose of 643 developing Internet standards in which case the procedures for 644 copyrights defined in the Internet Standards process must be 645 followed, or as required to translate it into languages other than 646 English. 648 The limited permissions granted above are perpetual and will not be 649 revoked by the Internet Society or its successors or assignees. 651 This document and the information contained herein is provided on an 652 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 653 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 654 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 655 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 656 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 658 Acknowledgement 660 Funding for the RFC Editor function is currently provided by the 661 Internet Society.