idnits 2.17.1 draft-livingood-enum-voicemsg-01.txt: -(360): 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 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 630. 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 6067 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 507, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 510, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 533, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 539, 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') Summary: 3 errors (**), 0 flaws (~~), 8 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 Voice Messaging 18 draft-livingood-enum-voicemsg-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 "voicemsg" 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 voice 55 communications to a voice 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 voicemsg.........................4 63 4.1 ENUM Service Registration for "voicemsg" with Subtype "sip"4 64 4.2 ENUM Service Registration for "voicemsg" with Subtype "tel"5 65 4.3 ENUM Service Registration for "voicemsg" with Subtype "http"6 66 4.4 ENUM Service Registration for "voicemsg" with Subtype "https" 67 ...............................................................7 68 5. Examples.......................................................8 69 5.1 Example of a calling party send to a voice messaging system, 70 Using a 'sip' URI Scheme.......................................8 71 5.2 Example of a calling party send to a voice 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 send to a voice 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 Voice messaging systems are used widely with telephony and voice 114 communication services. The need for a voice messaging service type 115 has become clear in order to provide certain applications with direct 116 access to various voice messaging services, for example voicemail, 117 most typically via the use of SIP. 119 The authors considered the use of VPIM [11] but found that VPIM was 120 best suited to the non-real-time and non-session-based routing of a 121 voice message once it had been deposited into a voice messaging 122 system. Thus, VPIM was a good solution for the non-real-time and 123 non-session-based routing of voice messages between and within 124 domains, but it did not enable real-time interaction with a voice 125 messaging system. 127 Thus, a need has been identified for this voice messaging service 128 type that would enable, for example some of the following use cases: 130 * A called party is busy or does not answer a call. A client or 131 server then determines that a voice messaging service should be used 132 and sends the calling party�s session to such a service. The client 133 or server needs to be able to determine which server to direct this 134 real-time session to, whether that is within or outside of the called 135 party�s domain. 137 * Similar to the above use case, a real-time session is attempted to 138 a voice messaging system, but that system is currently unavailable. 139 Since multiple voice messaging service type records may be returned 140 by the original ENUM query, the client or server could then attempt 141 to initiate a session with one or more backup voice messaging servers 142 in a manner which is transparent to the calling party, and which 143 supports better overall availability of a voice messaging service. 145 * Similar to the above use case, this voice message service type 146 could be used to balance load across multiple voice messaging 147 servers, whether those are in the same or in different physical 148 locations. 150 * A user with an account on a voice messaging service needs to 151 connect to a voice messaging service in order to retrieve voice 152 messages. They initiate a real-time session and an ENUM query is 153 performed to discover the voice messaging server that holds their 154 mailbox. 156 The authors considered whether this service type could simply use the 157 SIP Enumservice type [16], but found that it does not satisfy their 158 voice messaging requirements. For example, a request for access to 159 such a service could be extended to the requesting SIP client, or 160 User Agent Client (UAC), rather than relying upon the local policy of 161 a SIP server, or User Agent Server (UAS), which means that special 162 routing logic within a UAS cannot be relied upon to solve this 163 problem. More importantly, however, the authors have found that 164 without this service type, a UAC or UAS will be presented with 165 multiple SIP URIs, with no ability other than in non-standards-based 166 routing rules or application logic to recognize which one is related 167 to a voice messaging service. This is due in part to the fact that 168 the IANA registration for the SIP Enumservice does not register any 169 subtypes. 171 3. Distribution of Data 173 The authors believe that it is more likely that these records will be 174 distributed on a purely private basis, but they may also be 175 distributed in public ENUM trees. Distribution of this NAPTR data 176 could be either (a) on a private basis (within a service provider's 177 internal network, or on a private basis between one or more parties 178 using a variety of security mechanisms to prohibit general public 179 access) or (b) openly available. 181 4. ENUM Service Registration for voicemsg 183 4.1 ENUM Service Registration for "voicemsg" with Subtype "sip" 185 Enumservice Name: "voicemsg" 187 Enumservice Type: "voicemsg" 189 Enumservice Subtypes: "sip" 191 URI Schemes: 'sip:' 192 Functional Specification: 194 This Enumservice indicates that the remote resource identified can be 195 addressed by the associated URI scheme in order to initiate a voice 196 communication session to a voice messaging system. 198 Security Considerations: See Section 9. 200 Intended Usage: COMMON 202 Authors: 204 Jason Livingood (jason_livingood@cable.comcast.com) 205 Tong Zhou (tong_zhou@cable.comcast.com) 206 Richard Ferrise (rich_ferrise@cable.comcast.com) 207 Chris Harvey (chris_harvey@cable.comcast.com) 208 Don Troshynski (dtroshynski@acmepacket.com) 209 Hadriel Kaplan (hkaplan@acmepacket.com) 211 Any other information the author deems interesting: 213 Implementers should review a non-exclusive list of examples below in 214 Section 5. 216 4.2 ENUM Service Registration for "voicemsg" with Subtype "tel" 218 Enumservice Name: "voicemsg" 220 Enumservice Type: "voicemsg" 222 Enumservice Subtype: "tel" 224 URI Schemes: 'tel:' 226 Functional Specification: 228 This Enumservice indicates that the remote resource identified can be 229 addressed by the associated URI scheme in order to initiate a voice 230 communication session to a voice messaging system. 232 Security Considerations: See Section 9. 234 Intended Usage: COMMON 236 Authors: 238 Jason Livingood (jason_livingood@cable.comcast.com) 239 Tong Zhou (tong_zhou@cable.comcast.com) 240 Richard Ferrise (rich_ferrise@cable.comcast.com) 241 Chris Harvey (chris_harvey@cable.comcast.com) 242 Don Troshynski (dtroshynski@acmepacket.com) 243 Hadriel Kaplan (hkaplan@acmepacket.com) 245 Any other information the author deems interesting: 247 Implementers should review a non-exclusive list of examples below in 248 Section 5. 250 4.3 ENUM Service Registration for "voicemsg" with Subtype "http" 252 Enumservice Name: "voicemsg" 254 Enumservice Type: "voicemsg" 256 Enumservice Subtype: "http" 258 URI Schemes: 'http:' 260 Functional Specification: 262 This Enumservice indicates that the remote resource identified by the 263 associated URI scheme is capable of being a source of information. 265 Note that the kind of information retrieved can be manifold. 266 Usually, contacting a resource by an 'http:' [11] URI provides a 267 document. This document can contain references that will trigger the 268 download of many different kinds of information, such as text, audio, 269 video, executable code, or even voice message files. Thus, one 270 cannot be more specific about the kind of information expected when 271 contacting the resource. 273 Security Considerations: See Section 9. 275 Intended Usage: COMMON 277 Authors: 279 Jason Livingood (jason_livingood@cable.comcast.com) 280 Tong Zhou (tong_zhou@cable.comcast.com) 281 Richard Ferrise (rich_ferrise@cable.comcast.com) 282 Chris Harvey (chris_harvey@cable.comcast.com) 283 Don Troshynski (dtroshynski@acmepacket.com) 284 Hadriel Kaplan (hkaplan@acmepacket.com) 286 Any other information the author deems interesting: 288 Implementers should review a non-exclusive list of examples below in 289 Section 5. 291 4.4 ENUM Service Registration for "voicemsg" with Subtype "https" 293 Enumservice Name: "voicemsg" 295 Enumservice Type: "voicemsg" 297 Enumservice Subtype: "https" 299 URI Schemes: 'https:' 301 Functional Specification: 303 This Enumservice indicates that the remote resource identified by the 304 associated URI scheme is capable of being a source of information, 305 which can be contacted using TLS or the Secure Socket Layer protocol. 307 Note that the kind of information retrieved can be manifold. 308 Usually, contacting a resource by an 'https:' [12] URI provides a 309 document. This document can contain references that will trigger the 310 download of many different kinds of information, such as text, audio, 311 video, executable code, or even voice message files. Thus, one 312 cannot be more specific about the kind of information expected when 313 contacting the resource. 315 Security Considerations: See Section 9. 317 Intended Usage: COMMON 319 Authors: 321 Jason Livingood (jason_livingood@cable.comcast.com) 322 Tong Zhou (tong_zhou@cable.comcast.com) 323 Richard Ferrise (rich_ferrise@cable.comcast.com) 324 Chris Harvey (chris_harvey@cable.comcast.com) 325 Don Troshynski (dtroshynski@acmepacket.com) 326 Hadriel Kaplan (hkaplan@acmepacket.com) 328 Any other information the author deems interesting: 330 Implementers should review a non-exclusive list of examples below in 331 Section 5. 333 5. Examples 335 The following sub-sections document several examples for illustrative 336 purposes. These examples shall in no way limit the various forms 337 that this Enumservice may take. 339 5.1 Example of a calling party send to a voice messaging system, Using a 340 'sip' URI Scheme 342 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 343 NAPTR 10 100 "u" "E2U+voicemsg:sip" 344 "!^.*$!sip:12155550123@gw.example.com!". 346 In this example, a calling party has attempted a session which has 347 gone unanswered after a certain period of time. The calling party�s 348 session is sent to the appropriate voice messaging server, a 349 personalized greeting is played to the calling party, after which 350 they record a voice message to the called party. 352 5.2 Example of a calling party send to a voice messaging system, Using a 353 'tel' URI Scheme 355 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 356 NAPTR 10 100 "u" "E2U+voicemsg:tel" 357 "!^.*$!tel:1-215-555-0123!". 359 In this example, a calling party has attempted a session which has 360 gone unanswered after a certain period of time. The calling party�s 361 session is sent to the appropriate voice messaging server, a 362 personalized greeting is played to the calling party, after which 363 they record a voice message to the called party. 365 5.3 Example Using a Regular Expression 367 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 368 NAPTR 10 100 "u" "E2U+voicemsg:sip" 369 "!(^.*)$!sip:\1!". 371 In this example, a regular expression replacement function is used to 372 reduce the size of the NAPTR record. The sip URI uses "\1" which 373 would dynamically replace the expression with the TN, in this case 374 +12155550123. 376 5.4 Example of a calling party send to a voice messaging system, Using a 377 'sip' URI Scheme where the URI does not contain a telephone number 379 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 380 NAPTR 10 100 "u" "E2U+voicemsg:sip" 381 "!^.*$!sip:johndoe@gw.example.com!". 383 In this example, a calling party has attempted a session which has 384 gone unanswered after a certain period of time. The calling party�s 385 session is sent to the appropriate voice messaging server, a 386 personalized greeting is played to the calling party, after which 387 they record a voice message to the called party. The URI that this 388 session is directed to does not include a telephone number, as this 389 user has multiple service that are not particularly tied to telephone 390 numbers whereby text, audio, video and other multimedia messages can 391 be received and accessed. 393 6. Implementation Recommendations 395 6.1 Call Processing When Multiple Records Are Returned 397 It is likely that that both E2U+sip and E2U+voicemsg Enumservice type 398 records will be returned for a given query. In this case, this could 399 result in what is essentially E2U+sip records for real-time 400 communications with an end user, while the E2U+voicemsg records will 401 be used for real-time communications with a voice messaging service, 402 when the called party is not available or does not wish to be 403 disturbed. Therefore, the network element that receives the results 404 of this ENUM query will need to know enough information in order to 405 select the voicemsg service type, rather than the sip service type. 407 In addition, it is likely that multiple E2U+voicemsg Enumservice type 408 records will be returned for a given query. In this case, multiple 409 records may include order and preference to allow recursion or load 410 balancing. Order could be used to designate a primary and a backup 411 voice messaging service. Preference could be used to load balance 412 across multiple voice messaging servers by weight. 414 Finally, as with multiple records resulting from a typical ENUM query 415 of the e164.arpa tree, it is up to the application using an ENUM 416 resolver to determine which record(s) to use and which record(s) to 417 ignore. Implementers should take this into consideration and build 418 logic into their applications that can select appropriately from 419 multiple records based on business, network, or other rules. 421 6.2 NAPTR Configuration issues 423 Implementers may wish to consider using regular expressions in order 424 to reduce the size of individual NAPTRs. This will have a 425 significant effect on the overall size of the database involved. 427 7. Security Considerations 429 DNS, as used by ENUM, is a global, distributed database. Should 430 implementers of this specification use e164.arpa or any other 431 publicly available domain as the tree for maintaining voicemsg 432 Enumservice data, this information would be visible to anyone 433 anonymously. While this is not qualitatively different from 434 publication in a Telephone Directory, it does open or ease access to 435 such data without any indication that such data has been accessed or 436 by whom it has been accessed. 438 Such data harvesting by third parties is often used to generate lists 439 of targets for unsolicited information. Thus, a third party could use 440 this to generate a list that they can use to make unsolicited 441 "telemarketing" phone calls, or so-called SPAM over Internet 442 Telephony (SPIT). Many countries have do-not-call registries or other 443 legal or regulatory mechanisms in place to deal with such abuses. 445 As noted earlier carriers, service providers, and other users may 446 simply choose not to publish such information in the public e164.arpa 447 tree, but may instead simply publish this in their internal ENUM 448 routing database that is only able to be queried by trusted elements 449 of their network and/or partner networks, such as softswitches and 450 SIP proxy servers. They may also choose to publish such information 451 in a carrier-only branch of the e164.arpa tree, should one be 452 created. 454 Although an E.164 telephone number does not appear to reveal as much 455 identity information about a user as a name in the format 456 sip:username@hostname or email:username@hostname, the information is 457 still publicly available, thus there is still the risk of unwanted 458 communication. 460 An analysis of threats specific to the dependence of ENUM on the DNS 461 and the applicability of DNSSEC [13] to this is provided in RFC 3761 462 [1]. A thorough analysis of threats to the DNS itself is covered in 463 RFC 3833 [14]. 465 8. IANA Considerations 467 This document registers the 'voicemsg' Enumservice type and the 468 subtype "tel" and "sip" under the Enumservice registry described in 469 the IANA considerations in RFC 3761. Details of this registration 470 are provided in Section 4 of this document. 472 9. Acknowledgements 474 TBD 476 10. References 478 10.1 Normative References 480 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 481 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 482 Application (ENUM)", RFC 3761, April 2004. 484 [2] ITU-T, "The International Public Telecommunication Number Plan", 485 Recommendation E.164, May 1997. 487 [3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 488 1034, November 1987. 490 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 491 Three: The Domain Name System (DNS) Database", RFC 3403, October 492 2002. 494 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 495 One: The Comprehensive DDDS", RFC 3401, October 2002. 497 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 498 Two: The Algorithm", RFC 3402, October 2002. 500 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 501 Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 502 2002. 504 [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 505 Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. 507 [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 508 December 2004. 510 [10] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 511 3261, June 2002. 513 [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 514 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 515 HTTP/1.1", RFC 2616, June 1999. 517 [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 519 10.2 Informative References 521 [11] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, 522 October 2005. 524 [12] Bradner, et al., "IANA Registration for Enumservices email, fax, 525 mms, ems and sms", RFC 4355, January 2006. 527 [13] Arends, R. and et al., "Protocol Modifications for the DNS 528 Security Extensions", RFC 4035, March 2005. 530 [14] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name 531 System (DNS)", RFC 3833, August 2004. 533 [15] Foster, M., McGarry, T., and Yu, J., "Number Portability in the 534 GSTN: An Overview", RFC 3482, February 2003. 536 [16] Peterson, J., "enumservice Registration for Session Initiation 537 Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. 539 [17] Bradner, et al., "IANA Registration for Enumservice 'web' and 540 'ft', RFC 4022, February 2005. 542 Authors' Addresses 544 Jason Livingood 545 Comcast Cable Communications 546 1500 Market Street 547 Philadelphia, PA 19102 548 USA 550 Phone: +1-215-981-7813 551 Email: jason_livingood@cable.comcast.com 553 Tong Zhou 554 Comcast Cable Communications 555 1500 Market Street 556 Philadelphia, PA 19102 557 USA 559 Phone: +1-215-286-7301 560 Email: tong_zhou@cable.comcast.com 562 Richard Ferrise 563 Comcast Cable Communications 564 1500 Market Street 565 Philadelphia, PA 19102 566 USA 568 Phone: +1-215-320-8880 569 Email: rich_ferrise@cable.comcast.com 571 Chris Harvey 572 Comcast Cable Communications 573 1500 Market Street 574 Philadelphia, PA 19102 575 USA 577 Phone: +1-215-981-7813 578 Email: chris_harvey@cable.comcast.com 580 Donald Troshynski 581 Acme Packet 583 Email: dtroshynski@acmepacket.com 585 Hadriel Kaplan 586 Acme Packet 588 Email: hkaplan@acmepacket.com 590 Intellectual Property and Copyright Statements 592 Full Copyright Statement 594 Copyright (C) The IETF Trust (2007). 596 This document is subject to the rights, licenses and restrictions 597 contained in BCP 78, and except as set forth therein, the authors 598 retain all their rights. 600 This document and the information contained herein are provided on an 601 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 602 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 603 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 604 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 605 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 606 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 608 Intellectual Property 610 The IETF takes no position regarding the validity or scope of any 611 Intellectual Property Rights 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; nor does it represent that it has 615 made any independent effort to identify any such rights. Information 616 on the procedures with respect to rights in RFC documents can be 617 found in BCP 78 and BCP 79. 619 Copies of IPR disclosures made to the IETF Secretariat and any 620 assurances of licenses to be made available, or the result of an 621 attempt made to obtain a general license or permission for the use of 622 such proprietary rights by implementers or users of this 623 specification can be obtained from the IETF on-line IPR repository at 624 http://www.ietf.org/ipr. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights that may cover technology that may be required to implement 629 this standard. Please address the information to the IETF at ietf- 630 ipr@ietf.org. 632 Acknowledgment 634 Funding for the RFC Editor function is currently provided by the IETF 635 Administrative Support Activity (IASA).