From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5076.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc5076.txt (limited to 'doc/rfc/rfc5076.txt') diff --git a/doc/rfc/rfc5076.txt b/doc/rfc/rfc5076.txt new file mode 100644 index 0000000..ff571f9 --- /dev/null +++ b/doc/rfc/rfc5076.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group B. Hoeneisen +Request for Comments: 5076 SWITCH +Category: Standards Track December 2007 + + + ENUM Validation Information Mapping + for the Extensible Provisioning Protocol + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes an Extensible Provisioning Protocol (EPP) + extension framework for mapping information about the validation + process that has been applied for the E.164 number (or number range) + that the E.164 Number Mapping (ENUM) domain name is based on. + Specified in the Extensible Markup Language (XML), this mapping + extends the EPP domain name mapping to provide an additional feature + required for the provisioning of ENUM Domain Names. + + + + + + + + + + + + + + + + + + + + + + + + + + +Hoeneisen Standards Track [Page 1] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +Table of Contents + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Requirements ....................................................4 + 4. Object Attributes ...............................................4 + 4.1. ENUM Domain Names ..........................................4 + 4.2. Validation Information Commands ............................4 + 4.3. Id .........................................................4 + 4.4. Validation Information .....................................5 + 4.5. Validation Elements in the Example .........................5 + 4.5.1. Method Identifier ...................................5 + 4.5.2. Validation Entity Identifier ........................5 + 4.5.3. Registrar Identifier ................................5 + 4.5.4. Execution Date ......................................6 + 4.5.5. Expiration Date .....................................6 + 5. EPP Command Mapping .............................................6 + 5.1. EPP Query Commands .........................................6 + 5.1.1. EPP Command .................................6 + 5.1.2. EPP Command ..................................6 + 5.1.3. EPP Command ..............................8 + 5.2. EPP Transform Commands .....................................9 + 5.2.1. EPP Command ................................9 + 5.2.2. EPP Command ...............................11 + 5.2.3. EPP Command ................................11 + 5.2.4. EPP Command .............................13 + 5.2.5. EPP Command ...............................15 + 6. Formal Syntax ..................................................16 + 7. IANA Considerations ............................................21 + 8. Security Considerations ........................................21 + 9. Acknowledgements ...............................................22 + 10. References ....................................................22 + 10.1. Normative References .....................................22 + 10.2. Informative References ...................................23 + +1. Introduction + + This document describes a framework for an ENUM [2] validation + information mapping for version 1.0 of EPP [3]. This mapping, an + extension of the EPP domain name mapping described in [4], is + specified using XML 1.0, as described in [5], and XML Schema + notation, as described in [6] and [7]. + + The EPP core protocol specification [3] provides a complete + description of EPP command and response structures. A thorough + understanding of the base protocol specification is necessary to + understand the mapping described in this document. + + + + + +Hoeneisen Standards Track [Page 2] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + ENUM [2] describes how the Domain Name System (DNS) can be used to + identify services associated with an E.164 number. + + As described in RFC 4725 [9], usually only the Assignee of the E.164 + number (or number range) has the right to register the corresponding + ENUM domain name. Therefore, an ENUM validation process has to be + applied before the ENUM domain name can be inserted into the DNS. + The validation process shall ensure that the holder of the ENUM + domain name coincides with the Assignee of the corresponding E.164 + number (or number range). However, the details of the ENUM + validation methods are beyond the scope of this document. + + The EPP extension described in this document specifies a framework + for the mapping of information about the ENUM validation process. As + the local legislation or the validation procedures may vary, the + content of the validation information itself is not part of this + specification. + + However, this document contains a working example (including XML + schema) to show how the validation information could look. This + example could even be used for a lightweight validation process. In + fact, it has been an integral part of the Swiss ENUM trial. + + Using this extension framework, the content of the validation + information can be specified according to the local requirements. + Such an extension is specified in [10]. + + More background information concerning the validation can be found in + RFC 4725 [9], which also describes a typical basic role model for the + ENUM registration process. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + In examples, "C:" represents lines sent by a protocol client and "S:" + represents lines returned by a protocol server. Indentation and + white space in examples are provided only to illustrate element + relationships and are not REQUIRED features of this specification. + + XML is case sensitive. Unless stated otherwise, XML specifications + and examples provided in this document MUST be interpreted in the + character case presented to develop a conforming implementation. + + + + + + +Hoeneisen Standards Track [Page 3] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +3. Requirements + + The following requirements are the basis for this work: + + 1. The design shall allow multiple policies and validation + procedures. + + 2. It shall be possible to transmit validation information with EPP + domain object requests and responses. + + 3. It shall be possible to add, modify, and remove validation + information. + + 4. It shall be possible to retrieve validation information stored in + the ENUM Registry. + +4. Object Attributes + + This extension adds additional elements to the EPP domain name + mapping [4]. Only new element descriptions are listed here. + +4.1. ENUM Domain Names + + An ENUM Domain Name is a representation of an E.164 number that has + been translated to conform to domain name syntax as described in the + ENUM specification [2]. + +4.2. Validation Information Commands + + The following commands are defined for handling validation + information at the registry: + + o add: to add new validation information + + o rem: to revoke validation information + + o chg: to change stored validation information + + o inf: to get information about stored validation information + +4.3. Id + + The "id" attribute, used to identify the validation, is represented + in this mapping using a character string. It MUST be unique at least + within the same ENUM Domain Name. To ensure uniqueness even after a + transfer of an ENUM Domain Name, it is RECOMMENDED that the "id" + attribute be unique per ENUM Registry. + + + + +Hoeneisen Standards Track [Page 4] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + The "id" attribute, usually assigned by the ENUM Registrar, is + required for revoking or changing stored validation information and + appears in the Validation Information Command elements (see Section + 4.2). + +4.4. Validation Information + + The element can contain any element containing + validation information that is documented adequately. It is + represented in this mapping using the XML schema element and + therefore, is extensible. + + The number of elements permitted per domain object + is subject to local policy. + +4.5. Validation Elements in the Example + + As described above, this document includes an example for a possible + content of validation information that is used in the EPP examples + throughout this document. + + This example is an optional part of this specification, i.e., a fully + compliant RFC 5076 implementation does not need to implement this + example. + +4.5.1. Method Identifier + + The element is represented in this mapping using a + character string with a maximum length of 63 characters. It contains + an identifier for the method used for the validation. As stated in + Section 1, the details of the ENUM validation methods are beyond the + scope of this document. + +4.5.2. Validation Entity Identifier + + The element is represented in this mapping using + a character string with a length of 3 to 16 characters. It contains + an identifier assigned to the ENUM Validation Entity, e.g., by the + ENUM Registry. + +4.5.3. Registrar Identifier + + The element is represented in this mapping using a + character string with a length of 3 to 16 characters. It contains an + identifier assigned to the ENUM Registrar by the ENUM Registry. + + + + + + +Hoeneisen Standards Track [Page 5] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +4.5.4. Execution Date + + The element, the execution date of the validation, is + represented in this mapping using the XML Schema 'date' data type. + +4.5.5. Expiration Date + + The element, the expiration date of the validation, + is represented in this mapping using the XML Schema 'date' data type. + +5. EPP Command Mapping + + A detailed description of the EPP syntax and semantics can be found + in the EPP core protocol specification [3], and the EPP domain name + mapping is described in [4]. The command mappings described here are + specifically for use in implementing ENUM validation information + provisioning processes via EPP. + + Note: Whether or not this extension is included into an EPP request + or response depends on local policy. For example, a local Registry + policy might require the use of this extension for EPP , + , and commands, but not support it for EPP + and commands. Therefore, this is beyond the scope of this + document. + +5.1. EPP Query Commands + + EPP provides three commands to retrieve object information: + to determine if an object is known to the server, to retrieve + detailed information associated with an object, and to + retrieve object transfer status information. + +5.1.1. EPP Command + + This extension does not add any elements to the EPP command + or response described in the EPP domain mapping [4]. + +5.1.2. EPP Command + + This extension does not add any elements to the EPP command + described in the EPP domain mapping [4]. Additional elements are + defined for the response. + + When an command has been processed successfully, the EPP + element MUST contain child elements as described in the EPP + domain mapping [4]. In addition, the EPP element MUST + contain an element that identifies the extension + namespace. The element contains one or more + + + +Hoeneisen Standards Track [Page 6] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + elements, each with an "id" attribute identifying the + validation. Each element contains an element, which contains the validation information as + child element. + + In the example below, the validation information consists of a + element that identifies the extension namespace. + The element contains the following child elements: + + o An element that contains an identifier of the + validation method. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Validation Entity. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Registrar by the ENUM Registry. + + o An element that contains the date that the + validation was performed. + + o An OPTIONAL element that contains the + date that the validation expires. + + Example for response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa + S: EXAMPLE1-REP + S: + S: jd1234 + S: sh8013 + S: sh8013 + S: + S: ns1.example.com + S: ns2.example.com + S: + S: ClientX + S: ClientY + + + +Hoeneisen Standards Track [Page 7] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + S: 1999-04-03T22:00:00.0Z + S: ClientX + S: 1999-12-03T09:00:00.0Z + S: 2005-04-03T22:00:00.0Z + S: 2000-04-08T09:00:00.0Z + S: + S: 2fooBAR + S: + S: + S: + S: + S: + S: + S: + S: + S: Validation-X + S: VE-NMQ + S: Client-X + S: 2004-04-08 + S: 2004-10-07 + S: + S: + S: + S: + S: + S: + S: ABC-23456 + S: 54321-XYZ + S: + S: + S: + + Figure 1 + +5.1.3. EPP Command + + This extension does not add any elements to the EPP + command or response described in the EPP domain mapping + [4]. + + + + + + + + + + +Hoeneisen Standards Track [Page 8] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +5.2. EPP Transform Commands + + EPP provides five commands to transform objects: to create + an instance of an object, to delete an instance of an + object, to extend the validity period of an object, + to manage object sponsorship changes, and to + change information associated with an object. + +5.2.1. EPP Command + + This extension defines additional elements for the EPP + command described in the EPP domain mapping [4]. No additional + elements are defined for the EPP response. + + The EPP command provides a transform operation that allows a + client to create a domain object. In addition to the EPP command + elements described in the EPP domain mapping [4], the command MUST + contain an element. The element MUST contain + an element that identifies the extension namespace. + The element contains one or more + elements, each with an "id" attribute identifying the validation. + Each element contains an + element, which contains the validation information as child element. + + In the example below, the validation information consists of a + element that identifies the extension namespace. + The element contains the following child elements: + + o An element that contains an identifier of the + validation method. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Validation Entity. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Registrar by the ENUM Registry. + + o An element that contains the date that the + validation was performed. + + o An OPTIONAL element that contains the + date that the validation expires. + + + + + + + + + +Hoeneisen Standards Track [Page 9] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + Example for command: + + C: + C: + C: + C: + C: + C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa + C: 1 + C: + C: ns1.example.com + C: ns2.example.com + C: + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: + C: + C: + C: Validation-X + C: VE-NMQ + C: Client-X + C: 2004-04-08 + C: 2004-10-07 + C: + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + Figure 2 + + When an extended command has been processed successfully, + the EPP response is as described in the EPP domain mapping [4]. + + + +Hoeneisen Standards Track [Page 10] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +5.2.2. EPP Command + + This extension does not add any elements to the EPP command + or response described in the EPP domain mapping [4]. + +5.2.3. EPP Command + + This extension defines additional elements for the EPP + command described in the EPP domain mapping [4]. No additional + elements are defined for the EPP response. + + The EPP command provides a transform operation that allows a + client to extend the validity period of a domain object. In addition + to the EPP command elements described in the EPP domain mapping [4], + the command MUST contain an element. The + element MUST contain an element that + identifies the extension namespace. The element + contains one or more elements, each with an "id" + attribute identifying the validation. Each element + contains an element, which contains the + validation information as child element. + + In the example below, the validation information consists of a + element that identifies the extension namespace. + The contains the following child elements: + + o An element that contains an identifier of the + validation method. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Validation Entity. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Registrar by the ENUM Registry. + + o An element that contains the date that the + validation was performed. + + o An OPTIONAL element that contains the + date that the validation expires. + + + + + + + + + + + +Hoeneisen Standards Track [Page 11] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + Example for command: + + C: + C: + C: + C: + C: + C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa + C: 2005-04-09 + C: 1 + C: + C: + C: + C: + C: + C: + C: + C: Validation-X + C: VE-NMQ + C: Client-X + C: 2005-03-30 + C: 2005-09-29 + C: + C: + C: + C: + C: + C: ABC-45678 + C: + C: + + Figure 3 + + When an extended command has been processed successfully, the + EPP response is as described in the EPP domain mapping [4]. + + + + + + + + + + + + +Hoeneisen Standards Track [Page 12] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +5.2.4. EPP Command + + This extension defines additional elements for the EPP + command described in the EPP domain mapping [4]. No additional + elements are defined for the EPP response. + + The EPP command provides a transform operation that allows + a client to manage requests to transfer the sponsorship of a domain + object. Clients can initiate, cancel, approve, and reject a transfer + request. + + In case of a transfer request, in addition to the EPP command + elements described in the EPP domain mapping [4], the command MUST + contain an element. The element MUST contain + an element that identifies the extension + namespace. The element contains one or more + elements, each with an "id" attribute identifying the + validation. Each element contains an element, which contains the validation information as + child element. + + In the example below, the validation information consists of a + element that identifies the extension namespace. + The contains the following child elements: + + o An element that contains an identifier of the + validation method. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Validation Entity. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Registrar by the ENUM Registry. + + o An element that contains the date that the + validation was performed. + + o An OPTIONAL element that contains the + date that the validation expires. + + + + + + + + + + + + +Hoeneisen Standards Track [Page 13] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + Example for command: + + C: + C: + C: + C: + C: + C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: + C: + C: + C: Validation-Y + C: VE2-LMQ + C: Client-Y + C: 2005-01-22 + C: 2005-07-21 + C: + C: + C: + C: + C: + C: XYZ-54789 + C: + C: + + Figure 4 + + When an extended command has been processed successfully, + the EPP response is as described in the EPP domain mapping [4]. + + + + + + + + + + + +Hoeneisen Standards Track [Page 14] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +5.2.5. EPP Command + + This extension defines additional elements for the EPP + command described in the EPP domain mapping [4]. No additional + elements are defined for the EPP response. The EPP + command provides a transform operation that allows a client to change + the state of a domain object. In addition to the EPP command + elements described in the EPP domain mapping [4], the + command MUST contain an element. The element + MUST contain an element that identifies the + extension namespace. The element contains one or + more , , or elements, each + with an "id" attribute identifying the validation. Each + and element contains an element, which contains the validation information as + child element. elements do not have child elements. + + In the example below, the validation information consists of a + element that identifies the extension namespace. + The contains the following child elements: + + o An element that contains an identifier of the + validation method. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Validation Entity. + + o An OPTIONAL element that contains an + identifier assigned to the ENUM Registrar by the ENUM Registry. + + o An element that contains the date that the + validation was performed. + + o An OPTIONAL element that contains the + date that the validation expires. + + + + + + + + + + + + + + + + +Hoeneisen Standards Track [Page 15] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + Example for command: + + C: + C: + C: + C: + C: + C: 5.1.5.1.8.6.2.4.4.1.4.e164.arpa + C: + C: + C: + C: + C: + C: + C: + C: Validation-X + C: VE-NMQ + C: Client-X + C: 2004-10-02 + C: 2005-04-01 + C: + C: + C: + C: + C: + C: + C: ABC-34567 + C: + C: + + Figure 5 + + When an extended command has been processed successfully, + the EPP response is as described in the EPP domain mapping [4]. + +6. Formal Syntax + + An EPP object mapping is specified in XML Schema notation. The + formal syntax presented here is a complete schema representation of + the object mapping suitable for automated validation of EPP XML + instances. The BEGIN and END tags are not part of the schemas; they + are used to note the beginning and ending of the schema for URI + registration purposes. + + + + +Hoeneisen Standards Track [Page 16] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + Formal syntax for Framework: + + BEGIN + + + + + + + + + Extensible Provisioning Protocol v1.0 + domain name extension schema for framework for + provisioning of E.164 number validation information. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + END + + Figure 6 + + Formal syntax for a simple validation (example): + + BEGIN + + + + + + +Hoeneisen Standards Track [Page 19] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + + + + + + Example for E.164 number validation information. + + + + + + + + + + + + + + + + + + + + + + + + + + END + + Figure 7 + + + + + + + + + +Hoeneisen Standards Track [Page 20] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +7. IANA Considerations + + This document uses Uniform Resource Names (URNs) to describe XML + namespaces and XML schemas conforming to the registry mechanism + described in RFC 3688 [8]. Four URI assignments have been made: + + 1. Registration for the extension namespace: + * URI: urn:ietf:params:xml:ns:e164val-1.0 + * Registrant Contact: See the "Author's Address" section of this + document. + * XML: None. Namespace URIs do not represent an XML + specification. + + 2. Registration for the extension XML schema: + * URI: urn:ietf:params:xml:schema:e164val-1.0 + * Registrant Contact: See the "Author's Address" section of this + document. + * XML: See Section 6, "Formal Syntax", of this document. + + 3. Registration for the extension namespace: + * URI: urn:ietf:params:xml:ns:e164valex-1.1 + * Registrant Contact: See the "Author's Address" section of this + document. + * XML: None. Namespace URIs do not represent an XML + specification. + + 4. Registration for the extension XML schema: + * URI: urn:ietf:params:xml:schema:e164valex-1.1 + * Registrant Contact: See the "Author's Address" section of this + document. + * XML: See Section 6, "Formal Syntax", of this document. + +8. Security Considerations + + The mapping extensions described in this document do not provide any + security services beyond those described by EPP [3], the EPP domain + name mapping [4], and protocol layers used by EPP. Security + considerations related to ENUM are described in the "Security + Considerations" section of the ENUM specification [2]. The security + considerations described in these other specifications apply to this + specification as well. + + Validation information often contains sensitive personal information. + It is RECOMMENDED that validation information in the response + is only provided to the sponsoring client. + + + + + + +Hoeneisen Standards Track [Page 21] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +9. Acknowledgements + + The author would like to thank the following people who have provided + feedback or significant contributions to the development of this + document: Alfred Hoenes, Helena Malmborg, Alexander Mayrhofer, Andrew + Newton, Marcel Parodi, Patrik Schaefer, and Patrick Zenklusen. + + RFC 4114 [11] has been used as a template for this document. The + structure and those paragraphs that apply to both documents have + been taken over from [11]. The author would like to thank Scott + Hollenbeck for this great spadework. + +10. References + +10.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource + Identifiers (URI) Dynamic Delegation Discovery System (DDDS) + Application (ENUM)", RFC 3761, April 2004. + + [3] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC + 3730, March 2004. + + [4] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain + Name Mapping", RFC 3731, March 2004. + + [5] Paoli, J., Maler, E., Bray, T., and C. Sperberg-McQueen, + "Extensible Markup Language (XML) 1.0 (Second Edition)", World + Wide Web Consortium FirstEdition REC-xml-20001006, October + 2000, . + + [6] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML + Schema Part 1: Structures Second Edition", World Wide Web + Consortium Recommendation REC-xmlschema-1-20041028, October + 2004, . + + [7] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes + Second Edition", World Wide Web Consortium Recommendation REC- + xmlschema-2-20041028, October 2004, + . + + [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + + + + +Hoeneisen Standards Track [Page 22] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +10.2. Informative References + + [9] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation + Architecture", RFC 4725, November 2006. + + [10] Lendl, O., "ENUM Validation Token Format Definition", Work in + Progress. + + [11] Hollenbeck, S., "E.164 Number Mapping for the Extensible + Provisioning Protocol (EPP)", RFC 4114, June 2005. + +Author's Address + + Bernie Hoeneisen + SWITCH + Werdstrasse 2 + CH-8004 Zuerich + Switzerland + + Phone: +41 44 268 1515 + EMail: bernhard.hoeneisen@switch.ch, bernie@ietf.hoeneisen.ch + URI: http://www.switch.ch/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hoeneisen Standards Track [Page 23] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Hoeneisen Standards Track [Page 24] + -- cgit v1.2.3