idnits 2.17.1 draft-livingood-enum-videomsg-01.txt: -(352): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 621. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (September 2007) is 6065 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) == Unused Reference: '9' is defined on line 499, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 502, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 519, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 525, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 528, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 531, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3761 (ref. '1') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '5') ** Obsolete normative reference: RFC 2616 (ref. '11') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (ref. '12') (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM Working Group J. Livingood 3 Internet-Draft Comcast Cable Communications 4 Expires: March 14, 2008 T. Zhou 5 Comcast Cable Communications 6 R. Ferrise 7 Comcast Cable Communications 8 C. Harvey 9 Comcast Cable Communications 10 D. Troshynski 11 Acme Packet 12 H. Kaplan 13 Acme Packet 14 September 2007 16 IANA Registration for an Enumservice 17 for Video Messaging 18 draft-livingood-enum-videomsg-01 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 14, 2008. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Abstract 49 This document registers the Enumservice type "videomsg" with the 50 subtype "sip" using the URI scheme 'sip', the subtype "tel" using the 51 URI scheme 'tel', the subtype "http" using the URI scheme 'http', and 52 the subtype "https" using the URI scheme 'https' as per the IANA 53 registration process defined in the ENUM specification, RFC 3761. 54 This Enumservice is used to facilitate the real-time routing of video 55 communications to a video messaging system. 57 Table of Contents 59 1. Terminology....................................................2 60 2. Introduction...................................................2 61 3. Distribution of Data...........................................4 62 4. ENUM Service Registration for videomsg.........................4 63 4.1 ENUM Service Registration for "videomsg" with Subtype "sip"4 64 4.2 ENUM Service Registration for "videomsg" with Subtype "tel"5 65 4.3 ENUM Service Registration for "videomsg" with Subtype "http"6 66 4.4 ENUM Service Registration for "videomsg" with Subtype "https" 67 ...............................................................6 68 5. Examples.......................................................7 69 5.1 Example of a calling party sent to a video messaging system, 70 Using a 'sip' URI Scheme.......................................7 71 5.2 Example of a calling party sent to a video messaging system, 72 Using a 'tel' URI Scheme.......................................8 73 5.3 Example Using a Regular Expression.........................8 74 5.4 Example of a calling party sent to a video messaging system, 75 Using a 'sip' URI Scheme where the URI does not contain a 76 telephone number...............................................8 77 6. Implementation Recommendations.................................9 78 6.1 Call Processing When Multiple Records Are Returned.........9 79 6.2 NAPTR Configuration issues.................................9 80 7. Security Considerations........................................9 81 8. IANA Considerations...........................................10 82 9. Acknowledgements..............................................10 83 10. References...................................................10 84 10.1 Normative References.....................................10 85 10.2 Informative References...................................11 86 Authors' Addresses...............................................12 87 Intellectual Property and Copyright Statements...................13 89 1. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in BCP 14, RFC-2119 [1]. 95 2. Introduction 96 ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that 97 transforms E.164 numbers (The International Public Telecommunication 98 Numbering Plan, ITU-T Recommendation E.164 [2]) into domain names and 99 then uses DNS (Domain Name System, RFC 1034 [3]) delegation through 100 NS records and NAPTR records (Dynamic Delegation Discovery System 101 (DDDS) Part Three: The Domain Name System (DNS) Database, RFC 3403 102 [4]) to look up what services are available for a specific domain 103 name. 105 This document registers Enumservices according to the guidelines 106 given in RFC 3761 [1] to be used for provisioning in the services 107 field of a NAPTR [4] resource record to indicate the types of 108 functionality associated with an end point and/or telephone number. 109 The registration is defined within the DDDS (Dynamic Delegation 110 Discovery System [4][5][6][7][8]) hierarchy, for use with the "E2U" 111 DDDS Application defined in RFC 3761. 113 Video messaging systems, sometimes called visual voice messaging 114 systems, are beginning to be used with real-time communication 115 services. The need for a video messaging service type has become 116 clear in order to provide certain applications with direct access to 117 various video messaging services, most typically via the use of SIP. 119 Thus, a need has been identified for this video messaging service 120 type that would enable, for example some of the following use cases: 122 * A called party is busy or does not answer a call. A client or 123 server then determines that a video messaging service should be used 124 and sends the calling party�s session to such a service. The client 125 or server needs to be able to determine which server to direct this 126 real-time session to, whether that is within or outside of the called 127 party�s domain. 129 * Similar to the above use case, a real-time session is attempted to 130 a video messaging system, but that system is currently unavailable. 131 Since multiple video messaging service type records may be returned 132 by the original ENUM query, the client or server could then attempt 133 to initiate a session with one or more backup video messaging servers 134 in a manner which is transparent to the calling party, and which 135 supports better overall availability of a video messaging service. 137 * Similar to the above use case, this video message service type 138 could be used to balance load across multiple video messaging 139 servers, whether those are in the same or in different physical 140 locations. 142 * A user with an account on a video messaging service needs to 143 connect to a video messaging service in order to retrieve video 144 messages. They initiate a real-time session and an ENUM query is 145 performed to discover the video messaging server that holds their 146 mailbox. 148 The authors considered whether this service type could simply use the 149 SIP Enumservice type [16], but found that it does not satisfy their 150 video messaging requirements. For example, a request for access to 151 such a service could be extended to the requesting SIP client, or 152 User Agent Client (UAC), rather than relying upon the local policy of 153 a SIP server, or User Agent Server (UAS), which means that special 154 routing logic within a UAS cannot be relied upon to solve this 155 problem. More importantly, however, the authors have found that 156 without this service type, a UAC or UAS will be presented with 157 multiple SIP URIs, with no ability other than in non-standards-based 158 routing rules or application logic to recognize which one is related 159 to a video messaging service. This is due in part to the fact that 160 the IANA registration for the SIP Enumservice does not register any 161 subtypes. 163 3. Distribution of Data 165 The authors believe that it is more likely that these records will be 166 distributed on a purely private basis, but they may also be 167 distributed in public ENUM trees. Distribution of this NAPTR data 168 could be either (a) on a private basis (within a service provider's 169 internal network, or on a private basis between one or more parties 170 using a variety of security mechanisms to prohibit general public 171 access) or (b) openly available. 173 4. ENUM Service Registration for videomsg 175 4.1 ENUM Service Registration for "videomsg" with Subtype "sip" 177 Enumservice Name: "videomsg" 179 Enumservice Type: "videomsg" 181 Enumservice Subtypes: "sip" 183 URI Schemes: 'sip:' 185 Functional Specification: 187 This Enumservice indicates that the remote resource identified can be 188 addressed by the associated URI scheme in order to initiate a video 189 communication session to a video messaging system. 191 Security Considerations: See Section 9. 193 Intended Usage: COMMON 195 Authors: 197 Jason Livingood (jason_livingood@cable.comcast.com) 198 Tong Zhou (tong_zhou@cable.comcast.com) 199 Richard Ferrise (rich_ferrise@cable.comcast.com) 200 Chris Harvey (chris_harvey@cable.comcast.com) 201 Don Troshynski (dtroshynski@acmepacket.com) 202 Hadriel Kaplan (hkaplan@acmepacket.com) 204 Any other information the author deems interesting: 206 Implementers should review a non-exclusive list of examples below in 207 Section 5. 209 4.2 ENUM Service Registration for "videomsg" with Subtype "tel" 211 Enumservice Name: "videomsg" 213 Enumservice Type: "videomsg" 215 Enumservice Subtype: "tel" 217 URI Schemes: 'tel:' 219 Functional Specification: 221 This Enumservice indicates that the remote resource identified can be 222 addressed by the associated URI scheme in order to initiate a video 223 communication session to a video messaging system. 225 Security Considerations: See Section 9. 227 Intended Usage: COMMON 229 Authors: 231 Jason Livingood (jason_livingood@cable.comcast.com) 232 Tong Zhou (tong_zhou@cable.comcast.com) 233 Richard Ferrise (rich_ferrise@cable.comcast.com) 234 Chris Harvey (chris_harvey@cable.comcast.com) 235 Don Troshynski (dtroshynski@acmepacket.com) 236 Hadriel Kaplan (hkaplan@acmepacket.com) 238 Any other information the author deems interesting: 240 Implementers should review a non-exclusive list of examples below in 241 Section 5. 243 4.3 ENUM Service Registration for "videomsg" with Subtype "http" 245 Enumservice Name: "videomsg" 247 Enumservice Type: "videomsg" 249 Enumservice Subtype: "http" 251 URI Schemes: 'http:' 253 Functional Specification: 255 This Enumservice indicates that the remote resource identified by the 256 associated URI scheme is capable of being a source of information. 258 Note that the kind of information retrieved can be manifold. 259 Usually, contacting a resource by an 'http:' [11] URI provides a 260 document. This document can contain references that will trigger the 261 download of many different kinds of information, such as text, audio, 262 video, executable code, or even video message files. Thus, one 263 cannot be more specific about the kind of information expected when 264 contacting the resource. 266 Security Considerations: See Section 9. 268 Intended Usage: COMMON 270 Authors: 272 Jason Livingood (jason_livingood@cable.comcast.com) 273 Tong Zhou (tong_zhou@cable.comcast.com) 274 Richard Ferrise (rich_ferrise@cable.comcast.com) 275 Chris Harvey (chris_harvey@cable.comcast.com) 276 Don Troshynski (dtroshynski@acmepacket.com) 277 Hadriel Kaplan (hkaplan@acmepacket.com) 279 Any other information the author deems interesting: 281 Implementers should review a non-exclusive list of examples below in 282 Section 5. 284 4.4 ENUM Service Registration for "videomsg" with Subtype "https" 286 Enumservice Name: "videomsg" 288 Enumservice Type: "videomsg" 289 Enumservice Subtype: "https" 291 URI Schemes: 'https:' 293 Functional Specification: 295 This Enumservice indicates that the remote resource identified by the 296 associated URI scheme is capable of being a source of information, 297 which can be contacted using TLS or the Secure Socket Layer protocol. 299 Note that the kind of information retrieved can be manifold. 300 Usually, contacting a resource by an 'https:' [12] URI provides a 301 document. This document can contain references that will trigger the 302 download of many different kinds of information, such as text, audio, 303 video, executable code, or even video message files. Thus, one 304 cannot be more specific about the kind of information expected when 305 contacting the resource. 307 Security Considerations: See Section 9. 309 Intended Usage: COMMON 311 Authors: 313 Jason Livingood (jason_livingood@cable.comcast.com) 314 Tong Zhou (tong_zhou@cable.comcast.com) 315 Richard Ferrise (rich_ferrise@cable.comcast.com) 316 Chris Harvey (chris_harvey@cable.comcast.com) 317 Don Troshynski (dtroshynski@acmepacket.com) 318 Hadriel Kaplan (hkaplan@acmepacket.com) 320 Any other information the author deems interesting: 322 Implementers should review a non-exclusive list of examples below in 323 Section 5. 325 5. Examples 327 The following sub-sections document several examples for illustrative 328 purposes. These examples shall in no way limit the various forms 329 that this Enumservice may take. 331 5.1 Example of a calling party sent to a video messaging system, Using a 332 'sip' URI Scheme 334 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 335 NAPTR 10 100 "u" "E2U+videomsg:sip" 336 "!^.*$!sip:12155550123@gw.example.com!". 338 In this example, a calling party has attempted a session which has 339 gone unanswered after a certain period of time. The calling party�s 340 session is sent to the appropriate video messaging server, a 341 personalized greeting is played to the calling party, after which 342 they record a video message to the called party. 344 5.2 Example of a calling party sent to a video messaging system, Using a 345 'tel' URI Scheme 347 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 348 NAPTR 10 100 "u" "E2U+videomsg:tel" 349 "!^.*$!tel:1-215-555-0123!". 351 In this example, a calling party has attempted a session which has 352 gone unanswered after a certain period of time. The calling party�s 353 session is sent to the appropriate video messaging server, a 354 personalized greeting is played to the calling party, after which 355 they record a video message to the called party. 357 5.3 Example Using a Regular Expression 359 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 360 NAPTR 10 100 "u" "E2U+videomsg:sip" 361 "!(^.*)$!sip:\1!". 363 In this example, a regular expression replacement function is used to 364 reduce the size of the NAPTR record. The sip URI uses "\1" which 365 would dynamically replace the expression with the TN, in this case 366 +12155550123. 368 5.4 Example of a calling party sent to a video messaging system, Using a 369 'sip' URI Scheme where the URI does not contain a telephone number 371 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 372 NAPTR 10 100 "u" "E2U+videomsg:sip" 373 "!^.*$!sip:johndoe@gw.example.com!". 375 In this example, a calling party has attempted a session which has 376 gone unanswered after a certain period of time. The calling party�s 377 session is sent to the appropriate video messaging server, a 378 personalized greeting is played to the calling party, after which 379 they record a video message to the called party. The URI that this 380 session is directed to does not include a telephone number, as this 381 user has multiple services that are not particularly tied to 382 telephone numbers whereby text, audio, video and other multimedia 383 messages can be received and accessed. 385 6. Implementation Recommendations 387 6.1 Call Processing When Multiple Records Are Returned 389 It is likely that that both E2U+sip and E2U+videomsg Enumservice type 390 records will be returned for a given query. In this case, this could 391 result in what is essentially E2U+sip records for real-time 392 communications with an end user, while the E2U+videomsg records will 393 be used for real-time communications with a video messaging service, 394 when the called party is not available or does not wish to be 395 disturbed. Therefore, the network element that receives the results 396 of this ENUM query will need to know enough information in order to 397 select the videomsg service type, rather than the sip service type. 399 In addition, it is likely that multiple E2U+videomsg Enumservice type 400 records will be returned for a given query. In this case, multiple 401 records may include order and preference to allow recursion or load 402 balancing. Order could be used to designate a primary and a backup 403 video messaging service. Preference could be used to load balance 404 across multiple video messaging servers by weight. 406 Finally, as with multiple records resulting from a typical ENUM query 407 of the e164.arpa tree, it is up to the application using an ENUM 408 resolver to determine which record(s) to use and which record(s) to 409 ignore. Implementers should take this into consideration and build 410 logic into their applications that can select appropriately from 411 multiple records based on business, network, or other rules. 413 6.2 NAPTR Configuration issues 415 Implementers may wish to consider using regular expressions in order 416 to reduce the size of individual NAPTRs. This will have a 417 significant effect on the overall size of the database involved. 419 7. Security Considerations 421 DNS, as used by ENUM, is a global, distributed database. Should 422 implementers of this specification use e164.arpa or any other 423 publicly available domain as the tree for maintaining videomsg 424 Enumservice data, this information would be visible to anyone 425 anonymously. While this is not qualitatively different from 426 publication in a Telephone Directory, it does open or ease access to 427 such data without any indication that such data has been accessed or 428 by whom it has been accessed. 430 Such data harvesting by third parties is often used to generate lists 431 of targets for unsolicited information. Thus, a third party could use 432 this to generate a list that they can use to make unsolicited 433 "telemarketing" phone calls, or so-called SPAM over Internet 434 Telephony (SPIT). Many countries have do-not-call registries or other 435 legal or regulatory mechanisms in place to deal with such abuses. 437 As noted earlier carriers, service providers, and other users may 438 simply choose not to publish such information in the public e164.arpa 439 tree, but may instead simply publish this in their internal ENUM 440 routing database that is only able to be queried by trusted elements 441 of their network and/or partner networks, such as softswitches and 442 SIP proxy servers. They may also choose to publish such information 443 in a carrier-only branch of the e164.arpa tree, should one be 444 created. 446 Although an E.164 telephone number does not appear to reveal as much 447 identity information about a user as a name in the format 448 sip:username@hostname or email:username@hostname, the information is 449 still publicly available, thus there is still the risk of unwanted 450 communication. 452 An analysis of threats specific to the dependence of ENUM on the DNS 453 and the applicability of DNSSEC [13] to this is provided in RFC 3761 454 [1]. A thorough analysis of threats to the DNS itself is covered in 455 RFC 3833 [14]. 457 8. IANA Considerations 459 This document registers the 'videomsg' Enumservice type and the 460 subtype "tel" and "sip" under the Enumservice registry described in 461 the IANA considerations in RFC 3761. Details of this registration 462 are provided in Section 4 of this document. 464 9. Acknowledgements 466 TBD 468 10. References 470 10.1 Normative References 472 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 473 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 474 Application (ENUM)", RFC 3761, April 2004. 476 [2] ITU-T, "The International Public Telecommunication Number Plan", 477 Recommendation E.164, May 1997. 479 [3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 480 1034, November 1987. 482 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 483 Three: The Domain Name System (DNS) Database", RFC 3403, October 484 2002. 486 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 487 One: The Comprehensive DDDS", RFC 3401, October 2002. 489 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 490 Two: The Algorithm", RFC 3402, October 2002. 492 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 493 Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 494 2002. 496 [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 497 Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. 499 [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 500 December 2004. 502 [10] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 503 3261, June 2002. 505 [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 506 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 507 HTTP/1.1", RFC 2616, June 1999. 509 [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 511 10.2 Informative References 513 [13] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, 514 October 2005. 516 [14] Bradner, et al., "IANA Registration for Enumservices email, fax, 517 mms, ems and sms", RFC 4355, January 2006. 519 [15] Arends, R. and et al., "Protocol Modifications for the DNS 520 Security Extensions", RFC 4035, March 2005. 522 [16] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name 523 System (DNS)", RFC 3833, August 2004. 525 [17] Foster, M., McGarry, T., and Yu, J., "Number Portability in the 526 GSTN: An Overview", RFC 3482, February 2003. 528 [18] Peterson, J., "enumservice Registration for Session Initiation 529 Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. 531 [19] Bradner, et al., "IANA Registration for Enumservice 'web' and 532 'ft', RFC 4022, February 2005. 534 Authors' Addresses 536 Jason Livingood 537 Comcast Cable Communications 538 1500 Market Street 539 Philadelphia, PA 19102 540 USA 542 Phone: +1-215-981-7813 543 Email: jason_livingood@cable.comcast.com 545 Tong Zhou 546 Comcast Cable Communications 547 1500 Market Street 548 Philadelphia, PA 19102 549 USA 551 Phone: +1-215-286-7301 552 Email: tong_zhou@cable.comcast.com 554 Richard Ferrise 555 Comcast Cable Communications 556 1500 Market Street 557 Philadelphia, PA 19102 558 USA 560 Phone: +1-215-320-8880 561 Email: rich_ferrise@cable.comcast.com 563 Chris Harvey 564 Comcast Cable Communications 565 1500 Market Street 566 Philadelphia, PA 19102 567 USA 569 Phone: +1-215-981-7813 570 Email: chris_harvey@cable.comcast.com 571 Donald Troshynski 572 Acme Packet 574 Email: dtroshynski@acmepacket.com 576 Hadriel Kaplan 577 Acme Packet 579 Email: hkaplan@acmepacket.com 581 Intellectual Property and Copyright Statements 583 Full Copyright Statement 585 Copyright (C) The IETF Trust (2007). 587 This document is subject to the rights, licenses and restrictions 588 contained in BCP 78, and except as set forth therein, the authors 589 retain all their rights. 591 This document and the information contained herein are provided on an 592 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 593 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 594 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 595 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 596 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 599 Intellectual Property 601 The IETF takes no position regarding the validity or scope of any 602 Intellectual Property Rights or other rights that might be claimed to 603 pertain to the implementation or use of the technology described in 604 this document or the extent to which any license under such rights 605 might or might not be available; nor does it represent that it has 606 made any independent effort to identify any such rights. Information 607 on the procedures with respect to rights in RFC documents can be 608 found in BCP 78 and BCP 79. 610 Copies of IPR disclosures made to the IETF Secretariat and any 611 assurances of licenses to be made available, or the result of an 612 attempt made to obtain a general license or permission for the use of 613 such proprietary rights by implementers or users of this 614 specification can be obtained from the IETF on-line IPR repository at 615 http://www.ietf.org/ipr. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights that may cover technology that may be required to implement 620 this standard. Please address the information to the IETF at ietf- 621 ipr@ietf.org. 623 Acknowledgment 625 Funding for the RFC Editor function is currently provided by the IETF 626 Administrative Support Activity (IASA).