diff options
Diffstat (limited to 'doc/rfc/rfc3732.txt')
| -rw-r--r-- | doc/rfc/rfc3732.txt | 1571 |
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc3732.txt b/doc/rfc/rfc3732.txt new file mode 100644 index 0000000..d1851bf --- /dev/null +++ b/doc/rfc/rfc3732.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group S. Hollenbeck +Request for Comments: 3732 VeriSign, Inc. +Category: Standards Track March 2004 + + + Extensible Provisioning Protocol (EPP) Host Mapping + +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. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes an Extensible Provisioning Protocol (EPP) + mapping for the provisioning and management of Internet host names + stored in a shared central repository. Specified in XML, the mapping + defines EPP command syntax and semantics as applied to host names. + +Table of Contents + + 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Relationship of Host Objects and Domain Objects . . . . 2 + 1.2. Conventions Used In This Document . . . . . . . . . . . 3 + 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Host Names. . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Client Identifiers. . . . . . . . . . . . . . . . . . . 3 + 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . 3 + 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . 5 + 2.5. IP Addresses. . . . . . . . . . . . . . . . . . . . . . 5 + 3. EPP Command Mapping. . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. EPP Query Commands. . . . . . . . . . . . . . . . . . . 6 + 3.1.1. EPP <check> Command . . . . . . . . . . . . . . 6 + 3.1.2. EPP <info> Command. . . . . . . . . . . . . . . 8 + 3.1.3. EPP <transfer> Query Command. . . . . . . . . . 10 + 3.2. EPP Transform Commands. . . . . . . . . . . . . . . . . 11 + 3.2.1. EPP <create> Command. . . . . . . . . . . . . . 11 + 3.2.2. EPP <delete> Command. . . . . . . . . . . . . . 13 + 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . 14 + 3.2.4. EPP <transfer> Command. . . . . . . . . . . . . 14 + 3.2.5. EPP <update> Command. . . . . . . . . . . . . . 15 + + + +Hollenbeck Standards Track [Page 1] + +RFC 3732 EPP Host Mapping March 2004 + + + 3.2.6. Offline Review of Requested Actions . . . . . . 17 + 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5. Internationalization Considerations . . . . . . . . . . . . . 24 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 25 + 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 9.1. Normative References. . . . . . . . . . . . . . . . . . 26 + 9.2. Informative References. . . . . . . . . . . . . . . . . 27 + 10. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 27 + 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28 + +1. Introduction + + This document describes an Internet host name mapping for version 1.0 + of the Extensible Provisioning Protocol (EPP). This mapping is + specified using the Extensible Markup Language (XML) 1.0 as described + in [XML] and XML Schema notation as described in [XMLS-1] and [XMLS- + 2]. + + [RFC3730] 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. + + 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. + +1.1. Relationship of Host Objects and Domain Objects + + This document assumes that host name objects have a subordinate + relationship to a superordinate domain name object. For example, + host name "ns1.example.com" has a subordinate relationship to domain + name "example.com". EPP actions (such as object transfers) that do + not preserve this relationship MUST be explicitly disallowed. + + A host name object can be created in a repository for which no + superordinate domain name object exists. For example, host name + "ns1.example.com" can be created in the ".example" repository so that + DNS domains in ".example" can be delegated to the host. Such hosts + are described as "external" hosts in this specification since the + name of the host does not belong to the name space of the repository + in which the host is being used for delegation purposes. + + Whether a host is external or internal relates to the repository in + which the host is being used for delegation purposes. Whether an + internal host is subordinate or not relates to a domain within the + + + +Hollenbeck Standards Track [Page 2] + +RFC 3732 EPP Host Mapping March 2004 + + + repository. For example, host ns1.example1.com is a subordinate host + of domain example1.com, but it is a not a subordinate host of domain + example2.com. ns1.example1.com can be used as a name server for + example2.com. In this case, ns1.example1.com MUST be treated as an + internal host, subject to the rules governing operations on + subordinate hosts within the same repository. + +1.2. Conventions Used In This Document + + 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 [RFC2119]. + + 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 is provided only to illustrate element + relationships and is not a REQUIRED feature of this protocol. + +2. Object Attributes + + An EPP host object has attributes and associated values that can be + viewed and modified by the sponsoring client or the server. This + section describes each attribute type in detail. The formal syntax + for the attribute values described here can be found in the "Formal + Syntax" section of this document and in the appropriate normative + references. + +2.1. Host Names + + The syntax for host names described in this document MUST conform to + [RFC952] as updated by [RFC1123]. At the time of this writing, RFC + 3490 [RFC3490] describes a standard to use certain ASCII name labels + to represent non-ASCII name labels. These conformance requirements + might change in the future as a result of progressing work in + developing standards for internationalized host names. + +2.2. Client Identifiers + + All EPP clients are identified by a server-unique identifier. Client + identifiers conform to the "clIDType" syntax described in [RFC3730]. + +2.3. Status Values + + A host object MUST always have at least one associated status value. + Status values MAY be set only by the client that sponsors a host + object and by the server on which the object resides. A client can + change the status of a host object using the EPP <update> command. + Each status value MAY be accompanied by a string of human-readable + + + +Hollenbeck Standards Track [Page 3] + +RFC 3732 EPP Host Mapping March 2004 + + + text that describes the rationale for the status applied to the + object. + + A client MUST NOT alter status values set by the server. A server + MAY alter or override status values set by a client subject to local + server policies. The status of an object MAY change as a result of + either a client-initiated transform command or an action performed by + a server operator. + + Status values that can be added or removed by a client are prefixed + with "client". Corresponding status values that can be added or + removed by a server are prefixed with "server". Status values that + do not begin with either "client" or "server" are server-managed. + + Status Value Descriptions: + + - clientDeleteProhibited, serverDeleteProhibited + + Requests to delete the object MUST be rejected. + + - clientUpdateProhibited, serverUpdateProhibited + + Requests to update the object (other than to remove this status) MUST + be rejected. + + - linked + + The host object has at least one active association with another + object, such as a domain object. Servers SHOULD provide services to + determine existing object associations. + + - ok + + This is the normal status value for an object that has no pending + operations or prohibitions. This value is set and removed by the + server as other status values are added or removed. + + - pendingCreate, pendingDelete, pendingTransfer, pendingUpdate + + A transform command has been processed for the object (or in the case + of a <transfer> command, for the host object's superordinate domain + object), but the action has not been completed by the server. Server + operators can delay action completion for a variety of reasons, such + as to allow for human review or third-party action. A transform + command that is processed, but whose requested action is pending, is + noted with response code 1001. + + + + + +Hollenbeck Standards Track [Page 4] + +RFC 3732 EPP Host Mapping March 2004 + + + Transform commands MUST be rejected when a pendingCreate, + pendingDelete, pendingTransfer, or pendingUpdate status is set. + + When the requested action has been completed, the pendingCreate, + pendingDelete, pendingTransfer, or pendingUpdate status value MUST be + removed. All clients involved in the transaction MUST be notified + using a service message that the action has been completed and that + the status of the object has changed. + + "ok" status MAY only be combined with "linked" status. + + "linked" status MAY be combined with any status. + + "pendingDelete" status MUST NOT be combined with either + "clientDeleteProhibited" or "serverDeleteProhibited" status. + + "pendingUpdate" status MUST NOT be combined with either + "clientUpdateProhibited" or "serverUpdateProhibited" status. + + The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate + status values MUST NOT be combined with each other. + + Other status combinations not expressly prohibited MAY be used. + +2.4. Dates and Times + + Date and time attribute values MUST be represented in Universal + Coordinated Time (UTC) using the Gregorian calendar. The extended + date-time form using upper case "T" and "Z" characters defined in + [RFC3339] MUST be used to represent date-time values as XML Schema + does not support truncated date-time forms or lower case "T" and "Z" + characters. + +2.5. IP Addresses + + The syntax for IPv4 addresses described in this document MUST conform + to [RFC791]. The syntax for IPv6 addresses described in this + document MUST conform to [RFC3513]. Practical considerations for + publishing IPv6 address information in zone files are documented in + [RFC1886], [RFC2874], and [RFC3152]. A server MAY reject IP + addresses that have not been allocated for public use by IANA. When + a host object is provisioned for use as a DNS name server, IP + addresses SHOULD be required only as needed to generate DNS glue + records. + + + + + + + +Hollenbeck Standards Track [Page 5] + +RFC 3732 EPP Host Mapping March 2004 + + +3. EPP Command Mapping + + A detailed description of the EPP syntax and semantics can be found + in [RFC3730]. The command mappings described here are specifically + for use in provisioning and managing Internet host names via EPP. + +3.1. EPP Query Commands + + EPP provides two commands to retrieve host information: <check> to + determine if a host object can be provisioned within a repository, + and <info> to retrieve detailed information associated with a host + object. + +3.1.1. EPP <check> Command + + The EPP <check> command is used to determine if an object can be + provisioned within a repository. It provides a hint that allows a + client to anticipate the success or failure of provisioning an object + using the <create> command as object provisioning requirements are + ultimately a matter of server policy. + + In addition to the standard EPP command elements, the <check> command + MUST contain a <host:check> element that identifies the host + namespace and the location of the host schema. The <host:check> + element contains the following child elements: + + - One or more <host:name> elements that contain the fully qualified + names of the host objects to be queried. + + Example <check> command: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + C: epp-1.0.xsd"> + C: <command> + C: <check> + C: <host:check + C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + C: host-1.0.xsd"> + C: <host:name>ns1.example.com</host:name> + C: <host:name>ns2.example.com</host:name> + C: <host:name>ns3.example.com</host:name> + C: </host:check> + C: </check> + C: <clTRID>ABC-12345</clTRID> + + + +Hollenbeck Standards Track [Page 6] + +RFC 3732 EPP Host Mapping March 2004 + + + C: </command> + C:</epp> + + When a <check> command has been processed successfully, the EPP + <resData> element MUST contain a child <host:chkData> element that + identifies the host namespace and the location of the host schema. + The <host:chkData> element contains one or more <host:cd> elements + that contain the following child elements: + + - A <host:name> element that contains the fully qualified name of + the queried host object. This element MUST contain an "avail" + attribute whose value indicates object availability (can it be + provisioned or not) at the moment the <check> command was + completed. A value of "1" or "true" means that the object can be + provisioned. A value of "0" or "false" means that the object can + not be provisioned. + + - An OPTIONAL <host:reason> element that MAY be provided when an + object can not be provisioned. If present, this element contains + server-specific text to help explain why the object can not be + provisioned. This text MUST be represented in the response + language previously negotiated with the client; an OPTIONAL "lang" + attribute MAY be present to identify the language if the + negotiated value is something other than the default value of "en" + (English). + + Example <check> response: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + S: epp-1.0.xsd"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <host:chkData + S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + S: host-1.0.xsd"> + S: <host:cd> + S: <host:name avail="1">ns1.example.com</host:name> + S: </host:cd> + S: <host:cd> + S: <host:name avail="0">ns2.example2.com</host:name> + S: <host:reason>In use</host:reason> + + + +Hollenbeck Standards Track [Page 7] + +RFC 3732 EPP Host Mapping March 2004 + + + S: </host:cd> + S: <host:cd> + S: <host:name avail="1">ns3.example3.com</host:name> + S: </host:cd> + S: </host:chkData> + S: </resData> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + An EPP error response MUST be returned if a <check> command can not + be processed for any reason. + +3.1.2. EPP <info> Command + + The EPP <info> command is used to retrieve information associated + with a host object. In addition to the standard EPP command + elements, the <info> command MUST contain a <host:info> element that + identifies the host namespace and the location of the host schema. + The <host:info> element contains the following child elements: + + - A <host:name> element that contains the fully qualified name of + the host object for which information is requested. + + Example <info> command: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + C: epp-1.0.xsd"> + C: <command> + C: <info> + C: <host:info + C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + C: host-1.0.xsd"> + C: <host:name>ns1.example.com</host:name> + C: </host:info> + C: </info> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + + + + +Hollenbeck Standards Track [Page 8] + +RFC 3732 EPP Host Mapping March 2004 + + + When an <info> command has been processed successfully, the EPP + <resData> element MUST contain a child <host:infData> element that + identifies the host namespace and the location of the host schema. + The <host:infData> element contains the following child elements: + + - A <host:name> element that contains the fully qualified name of + the host object. + + - A <host:roid> element that contains the Repository Object + IDentifier assigned to the host object when the object was + created. + + - One or more <host:status> elements that describe the status of the + host object. + + - Zero or more <host:addr> elements that contain the IP addresses + associated with the host object. + + - A <host:clID> element that contains the identifier of the + sponsoring client. + + - A <host:crID> element that contains the identifier of the client + that created the host object. + + - A <host:crDate> element that contains the date and time of host + object creation. + + - A <host:upID> element that contains the identifier of the client + that last updated the host object. This element MUST NOT be + present if the host object has never been modified. + + - A <host:upDate> element that contains the date and time of the + most recent host object modification. This element MUST NOT be + present if the host object has never been modified. + + - A <host:trDate> element that contains the date and time of the + most recent successful host object transfer. This element MUST + NOT be provided if the host object has never been transferred. + Note that host objects MUST NOT be transferred directly; host + objects MUST be transferred implicitly when the host object's + superordinate domain object is transferred. Host objects that are + subject to transfer when transferring a domain object are listed + in the response to an EPP <info> command performed on the domain + object. + + + + + + + +Hollenbeck Standards Track [Page 9] + +RFC 3732 EPP Host Mapping March 2004 + + + Example <info> response: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + S: epp-1.0.xsd"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <host:infData + S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + S: host-1.0.xsd"> + S: <host:name>ns1.example.com</host:name> + S: <host:roid>NS1_EXAMPLE1-REP</host:roid> + S: <host:status s="linked"/> + S: <host:status s="clientUpdateProhibited"/> + S: <host:addr ip="v4">192.0.2.2</host:addr> + S: <host:addr ip="v4">192.0.2.29</host:addr> + S: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr> + S: <host:clID>ClientY</host:clID> + S: <host:crID>ClientX</host:crID> + S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate> + S: <host:upID>ClientX</host:upID> + S: <host:upDate>1999-12-03T09:00:00.0Z</host:upDate> + S: <host:trDate>2000-04-08T09:00:00.0Z</host:trDate> + S: </host:infData> + S: </resData> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + An EPP error response MUST be returned if an <info> command can not + be processed for any reason. + +3.1.3. EPP <transfer> Query Command + + Transfer semantics do not directly apply to host objects, so there is + no mapping defined for the EPP <transfer> query command. + + + + + + +Hollenbeck Standards Track [Page 10] + +RFC 3732 EPP Host Mapping March 2004 + + +3.2. EPP Transform Commands + + EPP provides three commands to transform host objects: <create> to + create an instance of a host object, <delete> to delete an instance + of a host object, and <update> to change information associated with + a host object. This document does not define host object mappings + for the EPP <renew> and <transfer> commands. + + Transform commands are typically processed and completed in real + time. Server operators MAY receive and process transform commands, + but defer completing the requested action if human or third-party + review is required before the requested action can be completed. In + such situations the server MUST return a 1001 response code to the + client to note that the command has been received and processed, but + the requested action is pending. The server MUST also manage the + status of the object that is the subject of the command to reflect + the initiation and completion of the requested action. Once the + action has been completed, all clients involved in the transaction + MUST be notified using a service message that the action has been + completed and that the status of the object has changed. + +3.2.1. EPP <create> Command + + The EPP <create> command provides a transform operation that allows a + client to create a host object. In addition to the standard EPP + command elements, the <create> command MUST contain a <host:create> + element that identifies the host namespace and the location of the + host schema. The <host:create> element contains the following child + elements: + + - A <host:name> element that contains the fully qualified name of + the host object to be created. + + - Zero or more <host:addr> elements that contain the IP addresses to + be associated with the host. Each element MAY contain an "ip" + attribute to identify the IP address format. Attribute value "v4" + is used to note IPv4 address format. Attribute value "v6" is used + to note IPv6 address format. If the "ip" attribute is not + specified, "v4" is the default attribute value. + + Hosts can be provisioned for use as name servers in the Domain Name + System (DNS), described in [RFC1034] and [RFC1035]. Hosts + provisioned as name servers might be subject to server operator + policies that require or prohibit specification of IP addresses + depending on the name of the host and the name space in which the + server will be used as a name server. When provisioned for use as a + name server, IP addresses are REQUIRED only as needed to produce DNS + glue records. For example, if the server is authoritative for the + + + +Hollenbeck Standards Track [Page 11] + +RFC 3732 EPP Host Mapping March 2004 + + + "com" name space and the name of the server is "ns1.example.net", the + server is not required to produce DNS glue records for the name + server and IP addresses for the server are not required by the DNS. + + If the host name exists in a name space for which the server is + authoritative, then the superordinate domain of the host MUST be + known to the server before the host object can be created. + + Example <create> command: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + C: epp-1.0.xsd"> + C: <command> + C: <create> + C: <host:create + C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + C: host-1.0.xsd"> + C: <host:name>ns1.example.com</host:name> + C: <host:addr ip="v4">192.0.2.2</host:addr> + C: <host:addr ip="v4">192.0.2.29</host:addr> + C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr> + C: </host:create> + C: </create> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + When a <create> command has been processed successfully, the EPP + <resData> element MUST contain a child <host:creData> element that + identifies the host namespace and the location of the host schema. + The <host:creData> element contains the following child elements: + + - A <host:name> element that contains the fully qualified name of + the host object. + + - A <host:crDate> element that contains the date and time of host + object creation. + + Example <create> response: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + + + +Hollenbeck Standards Track [Page 12] + +RFC 3732 EPP Host Mapping March 2004 + + + S: epp-1.0.xsd"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <host:creData + S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + S: host-1.0.xsd"> + S: <host:name>ns1.example.com</host:name> + S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate> + S: </host:creData> + S: </resData> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + An EPP error response MUST be returned if a <create> command can not + be processed for any reason. + +3.2.2. EPP <delete> Command + + The EPP <delete> command provides a transform operation that allows a + client to delete a host object. In addition to the standard EPP + command elements, the <delete> command MUST contain a <host:delete> + element that identifies the host namespace and the location of the + host schema. The <host:delete> element contains the following child + elements: + + - A <host:name> element that contains the fully qualified name of + the host object to be deleted. + + A host name object MUST NOT be deleted if the host object is + associated with any other object. For example, if the host object is + associated with a domain object, the host object MUST NOT be deleted + until the existing association has been broken. + + Example <delete> command: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + C: epp-1.0.xsd"> + + + +Hollenbeck Standards Track [Page 13] + +RFC 3732 EPP Host Mapping March 2004 + + + C: <command> + C: <delete> + C: <host:delete + C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + C: host-1.0.xsd"> + C: <host:name>ns1.example.com</host:name> + C: </host:delete> + C: </delete> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + When a <delete> command has been processed successfully, a server + MUST respond with an EPP response with no <resData> element. + + Example <delete> response: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + S: epp-1.0.xsd"> + S: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54321-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + An EPP error response MUST be returned if a <delete> command can not + be processed for any reason. + +3.2.3. EPP <renew> Command + + Renewal semantics do not apply to host objects, so there is no + mapping defined for the EPP <renew> command. + +3.2.4. EPP <transfer> Command + + Transfer semantics do not directly apply to host objects, so there is + no mapping defined for the EPP <transfer> command. Host objects are + subordinate to an existing superordinate domain object, and as such + they are subject to transfer when a domain object is transferred. + + + +Hollenbeck Standards Track [Page 14] + +RFC 3732 EPP Host Mapping March 2004 + + +3.2.5. EPP <update> Command + + The EPP <update> command provides a transform operation that allows a + client to modify the attributes of a host object. In addition to the + standard EPP command elements, the <update> command MUST contain a + <host:update> element that identifies the host namespace and the + location of the host schema. The <host:update> element contains the + following child elements: + + - A <host:name> element that contains the fully qualified name of + the host object to be updated. + + - An OPTIONAL <host:add> element that contains attribute values to + be added to the object. + + - An OPTIONAL <host:rem> element that contains attribute values to + be removed from the object. + + - An OPTIONAL <host:chg> element that contains object attribute + values to be changed. + + At least one <host:add>, <host:rem>, or <host:chg> element MUST be + provided. The <host:add> and <host:rem> elements contain the + following child elements: + + - One or more <host:addr> elements that contain IP addresses to be + associated with or removed from the host object. IP address + restrictions described in the <create> command mapping apply here + as well. + + - One or more <host:status> elements that contain status values to + be associated with or removed from the object. When specifying a + value to be removed, only the attribute value is significant; + element text is not required to match a value for removal. + + A <host:chg> element contains the following child elements: + + - A <host:name> element that contains a new fully qualified host + name by which the host object will be known. + + Host name changes MAY require the addition or removal of IP addresses + to be accepted by the server. IP address association MAY be subject + to server policies for provisioning hosts as name servers. + + Host name changes can have an impact on associated objects that refer + to the host object. A host name change SHOULD NOT require additional + updates of associated objects to preserve existing associations, with + one exception: changing an external host object that has + + + +Hollenbeck Standards Track [Page 15] + +RFC 3732 EPP Host Mapping March 2004 + + + associations with objects that are sponsored by a different client. + Attempts to update such hosts directly MUST fail with EPP error code + 2305. The change can be provisioned by creating a new external host + with a new name and needed new attributes and subsequently updating + the other objects sponsored by the client. + + Example <update> command: + + C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + C: epp-1.0.xsd"> + C: <command> + C: <update> + C: <host:update + C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + C: host-1.0.xsd"> + C: <host:name>ns1.example.com</host:name> + C: <host:add> + C: <host:addr ip="v4">192.0.2.22</host:addr> + C: <host:status s="clientUpdateProhibited"/> + C: </host:add> + C: <host:rem> + C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr> + C: </host:rem> + C: <host:chg> + C: <host:name>ns2.example.com</host:name> + C: </host:chg> + C: </host:update> + C: </update> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + When an <update> command has been processed successfully, a server + MUST respond with an EPP response with no <resData> element. + + Example <update> response: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + S: epp-1.0.xsd"> + S: <response> + S: <result code="1000"> + + + +Hollenbeck Standards Track [Page 16] + +RFC 3732 EPP Host Mapping March 2004 + + + S: <msg>Command completed successfully</msg> + S: </result> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54321-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + An EPP error response MUST be returned if an <update> command could + not be processed for any reason. + +3.2.6. Offline Review of Requested Actions + + Commands are processed by a server in the order they are received + from a client. Though an immediate response confirming receipt and + processing of the command is produced by the server, a server + operator MAY perform an offline review of requested transform + commands before completing the requested action. In such situations + the response from the server MUST clearly note that the transform + command has been received and processed, but the requested action is + pending. The status of the corresponding object MUST clearly reflect + processing of the pending action. The server MUST notify the client + when offline processing of the action has been completed. + + Examples describing a <create> command that requires offline review + are included here. Note the result code and message returned in + response to the <create> command. + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + S: epp-1.0.xsd"> + S: <response> + S: <result code="1001"> + S: <msg>Command completed successfully; action pending</msg> + S: </result> + S: <resData> + S: <host:creData + S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + S: host-1.0.xsd"> + S: <host:name>ns1.example.com</host:name> + S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate> + S: </host:creData> + S: </resData> + S: <trID> + + + +Hollenbeck Standards Track [Page 17] + +RFC 3732 EPP Host Mapping March 2004 + + + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + The status of the host object after returning this response MUST + include "pendingCreate". The server operator reviews the request + offline, and informs the client of the outcome of the review by + queuing a service message for retrieval via the <poll> command. + + The service message MUST contain text in the <response>, <msgQ>, + <msg> element that describes the notification. In addition, the EPP + <resData> element MUST contain a child <host:panData> element that + identifies the host namespace and the location of the host schema. + The <host:panData> element contains the following child elements: + + - A <host:name> element that contains the fully qualified name of + the host object. The <host:name> element contains a REQUIRED + "paResult" attribute. A positive boolean value indicates that the + request has been approved and completed. A negative boolean value + indicates that the request has been denied and the requested + action has not been taken. + + - A <host:paTRID> element that contains the client transaction + identifier and server transaction identifier returned with the + original response to process the command. The client transaction + identifier is OPTIONAL and will only be returned if the client + provided an identifier with the original <create> command. + + - A <host:paDate> element that contains the date and time describing + when review of the requested action was completed. + + Example "review completed" service message: + + S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> + S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" + S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 + S: epp-1.0.xsd"> + S: <response> + S: <result code="1301"> + S: <msg>Command completed successfully; ack to dequeue</msg> + S: </result> + S: <msgQ count="5" id="12345"> + S: <qDate>1999-04-04T22:01:00.0Z</qDate> + S: <msg>Pending action completed successfully.</msg> + S: </msgQ> + + + +Hollenbeck Standards Track [Page 18] + +RFC 3732 EPP Host Mapping March 2004 + + + S: <resData> + S: <host:panData + S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" + S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 + S: host-1.0.xsd"> + S: <host:name paResult="1">ns1.example.com</host:name> + S: <host:paTRID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </host:paTRID> + S: <host:paDate>1999-04-04T22:00:00.0Z</host:paDate> + S: </host:panData> + S: </resData> + S: <trID> + S: <clTRID>BCD-23456</clTRID> + S: <svTRID>65432-WXY</svTRID> + S: </trID> + S: </response> + S:</epp> + +4. 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 schema; they + are used to note the beginning and ending of the schema for URI + registration purposes. + + BEGIN + <?xml version="1.0" encoding="UTF-8"?> + + <schema targetNamespace="urn:ietf:params:xml:ns:host-1.0" + xmlns:host="urn:ietf:params:xml:ns:host-1.0" + xmlns:epp="urn:ietf:params:xml:ns:epp-1.0" + xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" + xmlns="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified"> + + <!-- + Import common element types. + --> + <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" + schemaLocation="eppcom-1.0.xsd"/> + <import namespace="urn:ietf:params:xml:ns:epp-1.0" + schemaLocation="epp-1.0.xsd"/> + + <annotation> + + + +Hollenbeck Standards Track [Page 19] + +RFC 3732 EPP Host Mapping March 2004 + + + <documentation> + Extensible Provisioning Protocol v1.0 + host provisioning schema. + </documentation> + </annotation> + + <!-- + Child elements found in EPP commands. + --> + <element name="check" type="host:mNameType"/> + <element name="create" type="host:createType"/> + <element name="delete" type="host:sNameType"/> + <element name="info" type="host:sNameType"/> + <element name="update" type="host:updateType"/> + + <!-- + Child elements of the <create> command. + --> + <complexType name="createType"> + <sequence> + <element name="name" type="eppcom:labelType"/> + <element name="addr" type="host:addrType" + minOccurs="0" maxOccurs="unbounded"/> + </sequence> + </complexType> + + <complexType name="addrType"> + <simpleContent> + <extension base="host:addrStringType"> + <attribute name="ip" type="host:ipType" + default="v4"/> + </extension> + </simpleContent> + </complexType> + + <simpleType name="addrStringType"> + <restriction base="token"> + <minLength value="3"/> + <maxLength value="45"/> + </restriction> + </simpleType> + + <simpleType name="ipType"> + <restriction base="token"> + <enumeration value="v4"/> + <enumeration value="v6"/> + </restriction> + </simpleType> + + + +Hollenbeck Standards Track [Page 20] + +RFC 3732 EPP Host Mapping March 2004 + + + <!-- + Child elements of the <delete> and <info> commands. + --> + <complexType name="sNameType"> + <sequence> + <element name="name" type="eppcom:labelType"/> + </sequence> + </complexType> + + <!-- + Child element of commands that accept multiple names. + --> + <complexType name="mNameType"> + <sequence> + <element name="name" type="eppcom:labelType" + maxOccurs="unbounded"/> + </sequence> + </complexType> + <!-- + Child elements of the <update> command. + --> + <complexType name="updateType"> + <sequence> + <element name="name" type="eppcom:labelType"/> + <element name="add" type="host:addRemType" + minOccurs="0"/> + <element name="rem" type="host:addRemType" + minOccurs="0"/> + <element name="chg" type="host:chgType" + minOccurs="0"/> + </sequence> + </complexType> + + <!-- + Data elements that can be added or removed. + --> + <complexType name="addRemType"> + <sequence> + <element name="addr" type="host:addrType" + minOccurs="0" maxOccurs="unbounded"/> + <element name="status" type="host:statusType" + minOccurs="0" maxOccurs="7"/> + </sequence> + </complexType> + + <!-- + Data elements that can be changed. + --> + + + +Hollenbeck Standards Track [Page 21] + +RFC 3732 EPP Host Mapping March 2004 + + + <complexType name="chgType"> + <sequence> + <element name="name" type="eppcom:labelType"/> + </sequence> + </complexType> + + <!-- + Child response elements. + --> + <element name="chkData" type="host:chkDataType"/> + <element name="creData" type="host:creDataType"/> + <element name="infData" type="host:infDataType"/> + <element name="panData" type="host:panDataType"/> + + <!-- + <check> response elements. + --> + <complexType name="chkDataType"> + <sequence> + <element name="cd" type="host:checkType" + maxOccurs="unbounded"/> + </sequence> + </complexType> + + <complexType name="checkType"> + <sequence> + <element name="name" type="host:checkNameType"/> + <element name="reason" type="eppcom:reasonType" + minOccurs="0"/> + </sequence> + </complexType> + + <complexType name="checkNameType"> + <simpleContent> + <extension base="eppcom:labelType"> + <attribute name="avail" type="boolean" + use="required"/> + </extension> + </simpleContent> + </complexType> + + <!-- + <create> response elements. + --> + <complexType name="creDataType"> + <sequence> + <element name="name" type="eppcom:labelType"/> + <element name="crDate" type="dateTime"/> + + + +Hollenbeck Standards Track [Page 22] + +RFC 3732 EPP Host Mapping March 2004 + + + </sequence> + </complexType> + + <!-- + <info> response elements. + --> + <complexType name="infDataType"> + <sequence> + <element name="name" type="eppcom:labelType"/> + <element name="roid" type="eppcom:roidType"/> + <element name="status" type="host:statusType" + maxOccurs="7"/> + <element name="addr" type="host:addrType" + minOccurs="0" maxOccurs="unbounded"/> + <element name="clID" type="eppcom:clIDType"/> + <element name="crID" type="eppcom:clIDType"/> + <element name="crDate" type="dateTime"/> + <element name="upID" type="eppcom:clIDType" + minOccurs="0"/> + <element name="upDate" type="dateTime" + minOccurs="0"/> + <element name="trDate" type="dateTime" + minOccurs="0"/> + </sequence> + </complexType> + + <!-- + Status is a combination of attributes and an optional human-readable + message that may be expressed in languages other than English. + --> + <complexType name="statusType"> + <simpleContent> + <extension base="normalizedString"> + <attribute name="s" type="host:statusValueType" + use="required"/> + <attribute name="lang" type="language" + default="en"/> + </extension> + </simpleContent> + </complexType> + + <simpleType name="statusValueType"> + <restriction base="token"> + <enumeration value="clientDeleteProhibited"/> + <enumeration value="clientUpdateProhibited"/> + <enumeration value="linked"/> + <enumeration value="ok"/> + <enumeration value="pendingCreate"/> + + + +Hollenbeck Standards Track [Page 23] + +RFC 3732 EPP Host Mapping March 2004 + + + <enumeration value="pendingDelete"/> + <enumeration value="pendingTransfer"/> + <enumeration value="pendingUpdate"/> + <enumeration value="serverDeleteProhibited"/> + <enumeration value="serverUpdateProhibited"/> + </restriction> + </simpleType> + + <!-- + Pending action notification response elements. + --> + <complexType name="panDataType"> + <sequence> + <element name="name" type="host:paNameType"/> + <element name="paTRID" type="epp:trIDType"/> + <element name="paDate" type="dateTime"/> + </sequence> + </complexType> + <complexType name="paNameType"> + <simpleContent> + <extension base="eppcom:labelType"> + <attribute name="paResult" type="boolean" + use="required"/> + </extension> + </simpleContent> + </complexType> + + <!-- + End of schema. + --> + </schema> + END + +5. Internationalization Considerations + + EPP is represented in XML, which provides native support for encoding + information using the Unicode character set and its more compact + representations including UTF-8. Conformant XML processors recognize + both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to + identify and use other character encodings through use of an + "encoding" attribute in an <?xml?> declaration, use of UTF-8 is + RECOMMENDED in environments where parser encoding support + incompatibility exists. + + All date-time values presented via EPP MUST be expressed in Universal + Coordinated Time using the Gregorian calendar. XML Schema allows use + of time zone identifiers to indicate offsets from the zero meridian, + but this option MUST NOT be used with EPP. The extended date-time + + + +Hollenbeck Standards Track [Page 24] + +RFC 3732 EPP Host Mapping March 2004 + + + form using upper case "T" and "Z" characters defined in [RFC3339] + MUST be used to represent date-time values as XML Schema does not + support truncated date-time forms or lower case "T" and "Z" + characters. + + This document requires host name syntax as specified in [RFC952] as + updated by [RFC1123]. At the time of this writing, RFC 3490 + [RFC3490] describes a standard to use certain ASCII name labels to + represent non-ASCII name labels. These conformance requirements + might change as a result of progressing work in developing standards + for internationalized host names. + +6. IANA Considerations + + This document uses URNs to describe XML namespaces and XML schemas + conforming to a registry mechanism described in [RFC3688]. Two URI + assignments have been registered by the IANA. + + Registration request for the host namespace: + + URI: urn:ietf:params:xml:ns:host-1.0 + + Registrant Contact: See the "Author's Address" section of this + document. + + XML: None. Namespace URIs do not represent an XML specification. + + Registration request for the host XML schema: + + URI: urn:ietf:params:xml:schema:host-1.0 + + Registrant Contact: See the "Author's Address" section of this + document. + + XML: See the "Formal Syntax" section of this document. + +7. Security Considerations + + The object mapping described in this document does not provide any + security services or introduce any additional considerations beyond + those described by [RFC3730] and protocol layers used by EPP. + +8. Acknowledgements + + This document was originally written as an individual submission + Internet-Draft. The provreg working group later adopted it as a + working group document and provided many invaluable comments and + suggested improvements. The author wishes to acknowledge the efforts + + + +Hollenbeck Standards Track [Page 25] + +RFC 3732 EPP Host Mapping March 2004 + + + of WG chairs Edward Lewis and Jaap Akkerhuis for their process and + editorial contributions. + + Specific suggestions that have been incorporated into this document + were provided by Chris Bason, Jordyn Buchanan, Dave Crocker, Anthony + Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, + Patrick Mevzek, and Rick Wesson. + +9. References + +9.1. Normative References + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September + 1981. + + [RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DOD Internet + Host Table Specification", RFC 952, October 1985. + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC1123] Braden, R., "Requirements for Internet Hosts -- + Application and Support", STD 3, RFC 1123, October 1989. + + [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, July 2002. + + [RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 3513, April 2003. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + RFC 3730, March 2004. + + [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) + 1.0 (Second Edition)", W3C Recommendation 6 October 2000. + + [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: + Structures", W3C Recommendation 2 May 2001. + + + + +Hollenbeck Standards Track [Page 26] + +RFC 3732 EPP Host Mapping March 2004 + + + [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: + Datatypes", W3C Recommendation 2 May 2001. + +9.2. Informative References + + [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, December 1995. + + [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO + 10646", RFC 2781, February 2000. + + [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support + IPv6 Address Aggregation and Renumbering", RFC 2874, July + 2000. + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + RFC 3490, March 2003. + +10. Author's Address + + Scott Hollenbeck + VeriSign Global Registry Services + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: shollenbeck@verisign.com + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 27] + +RFC 3732 EPP Host Mapping March 2004 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2004). 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 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Hollenbeck Standards Track [Page 28] + |