idnits 2.17.1 draft-ietf-mmusic-sdp-comedia-06.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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 526. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 542), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 173 has weird spacing: '... active pas...' == Line 174 has weird spacing: '...passive acti...' == Line 175 has weird spacing: '...actpass acti...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 14, 2004) is 7286 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 793 (ref. '1') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '7') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '8') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group D. Yon 3 Internet-Draft Dialout.Net, Inc 4 Expires: November 12, 2004 G. Camarillo 5 Ericsson 6 May 14, 2004 8 Connection-Oriented Media Transport in the Session Description 9 Protocol (SDP) 10 draft-ietf-mmusic-sdp-comedia-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 12, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes how to express media transport over 43 connection-oriented protocols using the Session Description Protocol 44 (SDP). It defines two new protocol identifiers: TCP and TCP/TLS. It 45 also defines the SDP setup attribute, which describes the connection 46 setup procedure, and the SDP reconnect attribute. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . . 3 53 3.1 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2 TCP/TLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Setup Attribute . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1 The Setup Attribute in the Offer/answer Model . . . . . . 4 57 4.2 Multiple-Connection Avoidance when Using Actpass . . . . . 5 58 5. The Reconnect Attribute . . . . . . . . . . . . . . . . . . . 6 59 6. Connection Lifetime . . . . . . . . . . . . . . . . . . . . . 7 60 6.1 Session Renegotiation . . . . . . . . . . . . . . . . . . 7 61 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7.1 Passive/Active . . . . . . . . . . . . . . . . . . . . . . 8 63 7.2 Passive/Active with Reconnect . . . . . . . . . . . . . . 9 64 7.3 Actpass . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 70 11.2 Informational References . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 72 Intellectual Property and Copyright Statements . . . . . . . . 13 74 1. Introduction 76 The Session Description Protocol [4] provides a general-purpose 77 format for describing multimedia sessions in announcements or 78 invitations. SDP uses an entirely textual data format (the US-ASCII 79 subset of UTF-8 [6]) to maximize portability among transports. SDP 80 does not define a protocol, but only the syntax to describe a 81 multimedia session with sufficient information to participate in that 82 session. Session descriptions may be sent using arbitrary existing 83 application protocols for transport (e.g., SAP [9], SIP [10], RTSP 84 [7], email, HTTP [8], etc.). 86 SDP [4] defines two protocol identifiers: RTP/AVP and UDP, both of 87 which represent unreliable connectionless protocols. While these 88 transports are appropriate choices for multimedia streams, there are 89 applications for which connection-oriented transports such as TCP are 90 more appropriate. We define two new protocol identifiers: TCP and 91 TCP/TLS. Both represent connection-oriented reliable transports. 93 Connection-oriented protocols introduce a new factor when describing 94 a session: how should end points perform the connection setup 95 procedure. We define two new attributes to describe connection setup: 96 setup and reconnect. 98 2. Terminology 100 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 101 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 102 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 103 described in BCP 14, RFC 2119 [2] and indicate requirement levels for 104 compliant implementations. 106 3. Protocol Identifiers 108 The following is the ABNF for an m= line, as specified by RFC 2327 109 [4]. 111 media-field = "m=" media space port ["/" integer] 112 space proto 1*(space fmt) CRLF 114 We define two new values for the proto field: TCP and TCP/TLS. 116 3.1 TCP 118 The TCP protocol identifier is similar to the UDP protocol identifier 119 in that it only describes the transport protocol, and not the 120 upper-layer protocol. An m= line that specifies "TCP" MUST further 121 qualify the application-layer protocol using an fmt identifier. 123 Media lines with the TCP protocol identifier are carried using TCP 124 [1]. 126 3.2 TCP/TLS 128 The TCP/TLS protocol identifier specifies that the session will use 129 the Transport Layer Security (TLS) protocol [3] on top on a TCP [1] 130 connection. 132 An m= line that contain the TCP/TLS protocol identifier MUST further 133 qualify the protocol using a fmt identifier. 135 4. Setup Attribute 137 The setup attribute indicates which of the end points should initiate 138 the connection establishment (e.g., send the initial TCP SYN). The 139 setup attribute is charset-independent and can be a session-level or 140 a media-level attribute. The following is the ABNF of the setup 141 attribute: 143 setup-attr = "a=setup:" role 144 role = "active" / "passive" / "actpass" 146 Active: The endpoint will initiate an outgoing connection. 147 Passive: The endpoint will accept an incoming connection. 148 ActPass: The endpoint will both accept an incoming connection and 149 will initiate an outgoing connection. 151 The default value of the setup attribute is actpass. That is, an m= 152 line without an associated setup line is considered to be actpass. 154 4.1 The Setup Attribute in the Offer/answer Model 156 The offer/answer model, defined in RFC 3264 [5], provides endpoints 157 with a means to obtain shared view of a session. Some session 158 parameters are negotiated (e.g., codecs to use), while others are 159 simply communicated from one endpoint to the other (e.g., IP 160 addresses). The value of the setup attribute falls into the first 161 category. That is, both endpoints negotiate its value using the 162 offer/answer model. 164 The negotiation of the value of the setup attribute takes places as 165 follows. The offerer states which role or roles is willing to perform 166 and the answerer, taking the offerer's willingness into 167 consideration, chooses which roles both endpoints will actually 168 perform during connection establishment. The following are the values 169 that the setup attribute can take in an offer/answer exchange: 171 Offer Answer 172 _______________ 173 active passive 174 passive active 175 actpass active / passive / actpass 177 The value active indicates that the endpoint SHOULD initiate a 178 connection to the port number on the m= line of the other endpoint. 179 The port number on its own m= line is irrelevant, and the opposite 180 endpoint MUST NOT attempt to initiate a connection to the port number 181 specified there. Nevertheless, since the m= line must contain a valid 182 port number, the endpoint specifying using the value active SHOULD 183 specify a port number of 9 (the discard port) on its m= line. The 184 endpoint MUST NOT specify a port number of zero, as that carries 185 other semantics in SDP. 187 The value passive indicates that the endpoint SHOULD be ready to 188 accept a connection on the port number specified in the m= line. 190 The value actpass indicates that the endpoint SHOULD initiate a 191 connection to the port number on the m= line of the other endpoint 192 and that the endpoint SHOULD be ready to accept a connection on the 193 port number specified in the m= line. It is RECOMMENDED that, if 194 possible, endpoints set the port number on their m= line to the 195 source port number which they will use to establish the connection 196 towards the remote endpoint. This way, the transport-layer protocol 197 (e.g., TCP) can take care of simultaneous opens. 199 Endpoints typically use the actpass value for the following reasons: 200 1. The offerer has no preference as to whether it accepts or 201 initiates the connection and, so, is letting the answerer choose. 202 2. The endpoints intend to use a single connection to transport the 203 media, but it is not known whether NAT (Network Address 204 Translator) issues will prevent either endpoint from initiating 205 or accepting the connection. So, both endpoints will attempt to 206 initiate a connection hoping that at least one will succeed. 208 4.2 Multiple-Connection Avoidance when Using Actpass 210 When an offer/answer exchange results in actpass, each endpoint 211 attempts to establish a transport connection towards the other 212 endpoint. If only one of the connections succeeds, this connection is 213 used to transfer media. Nevertheless, if both connections succeed, 214 one of them needs to be terminated so that both endpoints exchange 215 data over a single connection. In this section, we provide rules to 216 choose which of the two connections should be terminated (or not even 217 initiated). 219 First of all, if the endpoints follow the recommendation of setting 220 the port number in their m= line to the source port number which they 221 will use to establish the connection towards the remote endpoint, the 222 transport layer should take care of simultaneous opens (at least if 223 TCP is the transport protocol). If, for some reason, any of the 224 endpoints does not follow this recommendation, both endpoints should 225 follow the rules below. 227 If an endpoint is notified about a connection establishment attempt 228 from the other endpoint before performing its own connection attempt, 229 it SHOULD behave as a passive endpoint and SHOULD NOT attempt to 230 establish any other connection. 232 In case two connections are established, if an endpoint receives data 233 (i.e., media) over one of the connections before having sent any data 234 on any of the connections, the endpoint SHOULD terminate the 235 connection that has not carried any data. 237 When two connections are established and both endpoints start sending 238 data before receiving anything from the other endpoint, it may happen 239 that each of the endpoints choose a different connection to send 240 data. If the answerer receives data over a connection after having 241 sent data on the other connection, it SHOULD continue sending data on 242 the other connection until an application-layer data boundary. At 243 that point, the answerer SHOULD terminate this connection and start 244 using the connection on which the offerer was sending data. 246 Note that different applications may define application-layer 247 boundaries in different ways. A typical suitable point for the 248 answerer to change connections is the end of an application-layer 249 message and the beginning of the next one. 251 5. The Reconnect Attribute 253 The preceding description of the setup attribute has been in the 254 context of using SDP to initiate a session. Still, SDP may be 255 exchanged between endpoints at various stages of a session to 256 accomplish tasks such as terminating a session, redirecting media to 257 a new endpoint, or renegotiating the media parameters for a session. 258 After the initial session has been established, it may be ambiguous 259 as to whether subsequent SDP exchange represents a confirmation that 260 the endpoint is to continue using the current media connection 261 unchanged, or is a request to make a new media connection. The 262 reconnect attribute, which is charset-independent and can be a 263 session-level or a media-level attribute, is used to disambiguate 264 these two scenarios. The following is the ABNF of the reconnect 265 attribute: 267 reconnect-attr = "a=reconnect" 269 On reception of an m= line with a reconnect attribute, the endpoints 270 SHOULD close the existing connection, in case it was still up, and 271 SHOULD establish a new connection according to the setup attribute in 272 the m= line. 274 Either the offerer or the answerer can include a reconnect attribute 275 in an m= line. In any event, if the offer contained this attribute, 276 the answer MUST contain it as well. 278 6. Connection Lifetime 280 An endpoint that intends to initiate the connection SHOULD initiate 281 the connection immediately after it has sufficient information to do 282 so, even if it does not intend to immediately begin sending media to 283 the remote endpoint. This allows media to flow from the remote 284 endpoint. An endpoint SHOULD NOT close the connection until the 285 session has expired, been explicitly terminated, or the media stream 286 is redirected to a different address or port. 288 If the endpoint determines that the connection has been closed, it 289 MAY attempt to re-establish the connection. The decision to do so is 290 application and context dependant. 292 6.1 Session Renegotiation 294 There are scenarios where SDP is sent by an endpoint in order to 295 renegotiate an existing session. These include muting/unmuting a 296 session, renegotiating the attributes of the media used by the 297 session, or extending the length of a session about to expire. 298 Connection-oriented media introduces some ambiguities into session 299 renegotiation as to when the direction attribute must be obeyed and 300 when it is ignored. 302 The scenario of extending the duration of an existing session is a 303 good example: in order to extend an existing session, endpoints will 304 typically resend the original SDP with updated time information. In 305 connectionless media the result is no change to the existing media 306 streams. The problem with connection oriented media is that the 307 original SDP will contain a setup attribute which can be considered 308 as a request to create a new connection, as opposed to a request to 309 maintain steady state. The following rule help avoid this ambiguity: 311 If the transport section (the c= and m= lines) of an SDP 312 description describes an existing connection between two endpoints 313 and the m= line does not contain a reconnect attribute, the 314 endpoints SHOULD use that connection to carry the media described 315 in the remainder of the message. The endpoints SHOULD NOT attempt 316 to set up a new connection, regardless of what is specified in the 317 setup attribute. 318 Note that if the port number in the m= line changes, there is no 319 need to use the reconnect attribute because the new port will 320 trigger the establishment of a new connection anyway. 322 7. Examples 324 What follows are a number of examples that show the most common usage 325 of the setup attribute combined with TCP-based media descriptions. 326 For the purpose of brevity, the main portion of the session 327 description is omitted in the examples and is assumed to be the 328 following: 330 v=0 331 o=me 2890844526 2890842807 IN IP4 10.1.1.2 332 s=Call me using TCP 333 t=3034423619 3042462419 335 7.1 Passive/Active 337 An offerer at 192.0.2.2 signals its availability for a T.38 fax 338 session at port 54111: 340 c=IN IP4 192.0.2.2 341 m=image 54111 TCP t38 342 a=setup:passive 344 An answerer at 192.0.2.1 receiving this offer responds with the 345 following answer: 347 c=IN IP4 192.0.2.1 348 m=image 9 TCP t38 349 a=setup:active 351 The endpoint at 192.0.2.1 then initiates the TCP connection to port 352 54111 at 192.0.2.2. 354 7.2 Passive/Active with Reconnect 356 Continuing the preceding example, consider the scenario where the TCP 357 connection fails and the endpoints wish to reestablish the connection 358 for the session. The endpoint at 192.0.2.2 signals this intent with 359 the following SDP: 361 c=IN IP4 192.0.2.2 362 m=image 54111 TCP t38 363 a=setup:passive 364 a=reconnect 366 The reconnect attribute informs the endpoint at 192.0.2.1 that this 367 SDP represents the intent to establish a new connection for media 368 transport, rather than continuing with the original connection. 369 Because the endpoint at 192.0.2.1 may not yet be aware that the TCP 370 connection has failed, this eliminates any ambiguity. If 192.0.2.1 371 agrees to continue the session using a new connection, it responds 372 with: 374 c=IN IP4 192.0.2.1 375 m=image 9 TCP t38 376 a=setup:active IN IP4 377 a=reconnect 379 7.3 Actpass 381 An offerer at 192.0.2.2 signals its availability for a T.38 fax 382 session at TCP port 54111. Additionally, this offerer is also willing 383 to set up the media stream by initiating the TCP connection: 385 c=IN IP4 192.0.2.2 386 m=image 54111 TCP t38 387 a=setup:actpass 389 The endpoint at 192.0.2.1 responds with the following description: 391 c=IN IP4 192.0.2.1 392 m=image 54321 TCP t38 393 a=setup:actpass 395 This will cause the offerer (at 192.0.2.2) to initiate a connection 396 to port 54321 at 192.0.2.1 and the answerer (at 192.0.2.1) to 397 initiate a connection to port 54111 at 192.0.2.2. Ideally, the 398 offerer would use 192.0.2.2:5411 as the source of its connection 399 attempt and the answerer would use 192.0.2.1:54321 as its. 401 8. Security Considerations 403 See RFC 2327 [4] for security and other considerations specific to 404 the Session Description Protocol in general. 406 An attacker may attempt to substitute TCP/TLS with only TCP in a 407 session description. So, it is STRONGLY RECOMMENDED that integrity 408 protection be applied to the SDP session descriptions. For session 409 descriptions carried in SIP [10], S/MIME is the natural choice to 410 provide such end-to-end integrity protection, as described in RFC 411 3261 [10]. Other applications MAY use a different form of integrity 412 protection. 414 This document touches upon NAT traversal. Implementers should be 415 aware of some issues that relate to the use of private IP addresses 416 within the offer/answer model (i.e., they are not specific to this 417 document). 419 When an endpoint receives a session description with a private IP 420 address that belongs to a different address space, in most of the 421 cases, the endpoint will not be able to reach such an address. 422 Nevertheless, if this particular address also exists in the 423 endpoint's address space, the endpoint may end up reaching a 424 different peer than the one that generated the session description. 425 It is RECOMMENDED that endpoints authenticate their peer somehow 426 (e.g., using TLS [3]) or that they encrypt their media. 428 9. IANA Considerations 430 This document defines two session and media level SDP attributes: 431 setup and reconnect. Their formats are defined in Section 4 and 432 Section 5 respectively. These two attributes should be registered by 433 the IANA on http://www.iana.org/assignments/sdp-parameters under 434 "att-field (both session and media level)". 436 This document defines two proto values: TCP and TCP/TLS. Their 437 formats are defined in Section 3.1 and Section 3.2 respectively. 438 These two proto values should be registered by the IANA on http:// 439 www.iana.org/assignments/sdp-parameters under "proto". 441 10. Acknowledgements 443 The authors would like to thank Jonathan Rosenberg, Rohan Mahy, 444 Anders Kristensen, Joerg Ott, Paul Kyzivat, Robert 445 Fairlie-Cuninghame, and Colin Perkins for their valuable insights and 446 contributions. 448 11. References 450 11.1 Normative References 452 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 453 September 1981. 455 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 456 Levels", BCP 14, RFC 2119, March 1997. 458 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 459 2246, January 1999. 461 [4] Handley, M. and V. Jacobson, "SDP: Session Description 462 Protocol", RFC 2327, April 1998. 464 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 465 Session Description Protocol (SDP)", RFC 3264, June 2002. 467 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 468 63, RFC 3629, November 2003. 470 11.2 Informational References 472 [7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 473 Protocol (RTSP)", RFC 2326, April 1998. 475 [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 476 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 477 HTTP/1.1", RFC 2616, June 1999. 479 [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement 480 Protocol", RFC 2974, October 2000. 482 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 483 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 484 Session Initiation Protocol", RFC 3261, June 2002. 486 Authors' Addresses 488 David Yon 489 Dialout.Net, Inc 490 One Indian Head Plaza 491 Nashua, NH 03060 492 USA 494 EMail: yon@dialout.net 496 Gonzalo Camarillo 497 Ericsson 498 Hirsalantie 11 499 Jorvas 02420 500 Finland 502 EMail: Gonzalo.Camarillo@ericsson.com 504 Intellectual Property Statement 506 The IETF takes no position regarding the validity or scope of any 507 Intellectual Property Rights or other rights that might be claimed to 508 pertain to the implementation or use of the technology described in 509 this document or the extent to which any license under such rights 510 might or might not be available; nor does it represent that it has 511 made any independent effort to identify any such rights. Information 512 on the IETF's procedures with respect to rights in IETF Documents can 513 be found in BCP 78 and BCP 79. 515 Copies of IPR disclosures made to the IETF Secretariat and any 516 assurances of licenses to be made available, or the result of an 517 attempt made to obtain a general license or permission for the use of 518 such proprietary rights by implementers or users of this 519 specification can be obtained from the IETF on-line IPR repository at 520 http://www.ietf.org/ipr. 522 The IETF invites any interested party to bring to its attention any 523 copyrights, patents or patent applications, or other proprietary 524 rights that may cover technology that may be required to implement 525 this standard. Please address the information to the IETF at 526 ietf-ipr@ietf.org. 528 Disclaimer of Validity 530 This document and the information contained herein are provided on an 531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 533 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 534 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 535 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 538 Copyright Statement 540 Copyright (C) The Internet Society (2004). This document is subject 541 to the rights, licenses and restrictions contained in BCP 78, and 542 except as set forth therein, the authors retain all their rights. 544 Acknowledgment 546 Funding for the RFC Editor function is currently provided by the 547 Internet Society.