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/rfc5732.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc5732.txt (limited to 'doc/rfc/rfc5732.txt') diff --git a/doc/rfc/rfc5732.txt b/doc/rfc/rfc5732.txt new file mode 100644 index 0000000..9613d32 --- /dev/null +++ b/doc/rfc/rfc5732.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group S. Hollenbeck +Request for Comments: 5732 VeriSign, Inc. +STD: 69 August 2009 +Obsoletes: 4932 +Category: Standards Track + + + Extensible Provisioning Protocol (EPP) Host Mapping + +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. + This document obsoletes RFC 4932. + +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) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 1] + +RFC 5732 EPP Host Mapping August 2009 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Relationship of Host Objects and Domain Objects ............3 + 1.2. Conventions Used in This Document ..........................4 + 2. Object Attributes ...............................................4 + 2.1. Host Names .................................................4 + 2.2. Client Identifiers .........................................4 + 2.3. Status Values ..............................................4 + 2.4. Dates and Times ............................................6 + 2.5. IP Addresses ...............................................6 + 3. EPP Command Mapping .............................................6 + 3.1. EPP Query Commands .........................................7 + 3.1.1. EPP Command .................................7 + 3.1.2. EPP Command ..................................9 + 3.1.3. EPP Query Command .......................11 + 3.2. EPP Transform Commands ....................................11 + 3.2.1. EPP Command ...............................12 + 3.2.2. EPP Command ...............................13 + 3.2.3. EPP Command ................................15 + 3.2.4. EPP Command .............................15 + 3.2.5. EPP Command ...............................15 + 3.3. Offline Review of Requested Actions .......................17 + 4. Formal Syntax ..................................................19 + 5. Internationalization Considerations ............................25 + 6. IANA Considerations ............................................25 + 7. Security Considerations ........................................26 + 8. Acknowledgements ...............................................26 + 9. References .....................................................26 + 9.1. Normative References ......................................26 + 9.2. Informative References ....................................27 + Appendix A. Changes from RFC 4932 ................................29 + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 2] + +RFC 5732 EPP Host Mapping August 2009 + + +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 [W3C.REC-xml-20040204] and XML Schema notation as described in + [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. + This document obsoletes RFC 4932 [RFC4932]. + + [RFC5730] 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 namespace 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. An internal + host is subordinate if the name of the host belongs to the domain + within the repository in which the host is being used for delegation + purposes. For example, host ns1.example1.com is a subordinate host + of domain example1.com, but it is 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. + + + + + + + +Hollenbeck Standards Track [Page 3] + +RFC 5732 EPP Host Mapping August 2009 + + +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 are provided only to illustrate element + relationships and are 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 + [RFC0952] 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 [RFC5730]. + +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 command. + Each status value MAY be accompanied by a string of human-readable + text that describes the rationale for the status applied to the + object. + + + + + + + + +Hollenbeck Standards Track [Page 4] + +RFC 5732 EPP Host Mapping August 2009 + + + 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 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 5] + +RFC 5732 EPP Host Mapping August 2009 + + + 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 + [W3C.REC-xmlschema-2-20041028] 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 [RFC0791]. The syntax for IPv6 addresses described in this + document MUST conform to [RFC4291]. Practical considerations for + publishing IPv6 address information in zone files are documented in + [RFC2874] and [RFC3596]. 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. + +3. EPP Command Mapping + + A detailed description of the EPP syntax and semantics can be found + in [RFC5730]. The command mappings described here are specifically + for use in provisioning and managing Internet host names via EPP. + + + + + +Hollenbeck Standards Track [Page 6] + +RFC 5732 EPP Host Mapping August 2009 + + +3.1. EPP Query Commands + + EPP provides two commands to retrieve host information: to + determine if a host object can be provisioned within a repository, + and to retrieve detailed information associated with a host + object. + +3.1.1. EPP Command + + The EPP 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 command, as object-provisioning requirements are + ultimately a matter of server policy. + + In addition to the standard EPP command elements, the command + MUST contain a element that identifies the host + namespace. The element contains the following child + elements: + + - One or more elements that contain the fully qualified + names of the host objects to be queried. + + Example command: + + C: + C: + C: + C: + C: + C: ns1.example.com + C: ns2.example.com + C: ns3.example.com + C: + C: + C: ABC-12345 + C: + C: + + When a command has been processed successfully, the EPP + element MUST contain a child element that + identifies the host namespace. The element contains + one or more elements that contain the following child + elements: + + + + + + +Hollenbeck Standards Track [Page 7] + +RFC 5732 EPP Host Mapping August 2009 + + + - A 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 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 + cannot be provisioned. + + - An OPTIONAL element that MAY be provided when an + object cannot be provisioned. If present, this element contains + server-specific text to help explain why the object cannot 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 response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: + S: ns1.example.com + S: + S: + S: ns2.example2.com + S: In use + S: + S: + S: ns3.example3.com + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + + + + +Hollenbeck Standards Track [Page 8] + +RFC 5732 EPP Host Mapping August 2009 + + + An EPP error response MUST be returned if a command cannot be + processed for any reason. + +3.1.2. EPP Command + + The EPP command is used to retrieve information associated + with a host object. In addition to the standard EPP command + elements, the command MUST contain a element that + identifies the host namespace. The element contains the + following child elements: + + - A element that contains the fully qualified name of + the host object for which information is requested. + + Example command: + + C: + C: + C: + C: + C: + C: ns1.example.com + C: + C: + C: ABC-12345 + C: + C: + + When an command has been processed successfully, the EPP + element MUST contain a child element that + identifies the host namespace. The element contains + the following child elements: + + - A element that contains the fully qualified name of + the host object. + + - A element that contains the Repository Object + IDentifier assigned to the host object when the object was + created. + + - One or more elements that describe the status of the + host object. + + - Zero or more elements that contain the IP addresses + associated with the host object. + + + + + +Hollenbeck Standards Track [Page 9] + +RFC 5732 EPP Host Mapping August 2009 + + + - A element that contains the identifier of the + sponsoring client. + + - A element that contains the identifier of the client + that created the host object. + + - A element that contains the date and time of host- + object creation. + + - A 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 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 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 command performed on the domain + object. + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: ns1.example.com + S: NS1_EXAMPLE1-REP + S: + S: + S: 192.0.2.2 + S: 192.0.2.29 + S: 1080:0:0:0:8:800:200C:417A + S: ClientY + S: ClientX + S: 1999-04-03T22:00:00.0Z + + + +Hollenbeck Standards Track [Page 10] + +RFC 5732 EPP Host Mapping August 2009 + + + S: ClientX + S: 1999-12-03T09:00:00.0Z + S: 2000-04-08T09:00:00.0Z + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + An EPP error response MUST be returned if an command cannot be + processed for any reason. + +3.1.3. EPP Query Command + + Transfer semantics do not directly apply to host objects, so there is + no mapping defined for the EPP query command. + +3.2. EPP Transform Commands + + EPP provides three commands to transform host objects: to + create an instance of a host object, to delete an instance + of a host object, and to change information associated with + a host object. This document does not define host-object mappings + for the EPP and 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 + that 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. + Other notification methods MAY be used in addition to the required + service message. + + Server operators SHOULD confirm that a client is authorized to + perform a transform command on a given object. Any attempt to + transform an object by an unauthorized client MUST be rejected, and + the server MUST return a 2201 response code to the client to note + that the client lacks privileges to execute the requested command. + + + +Hollenbeck Standards Track [Page 11] + +RFC 5732 EPP Host Mapping August 2009 + + +3.2.1. EPP Command + + The EPP command provides a transform operation that allows a + client to create a host object. In addition to the standard EPP + command elements, the command MUST contain a + element that identifies the host namespace. The + element contains the following child elements: + + - A element that contains the fully qualified name of + the host object to be created. + + - Zero or more 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 namespace 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 + "com" namespace 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 namespace 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 command: + + C: + C: + C: + C: + C: + C: ns1.example.com + C: 192.0.2.2 + C: 192.0.2.29 + C: 1080:0:0:0:8:800:200C:417A + C: + C: + + + +Hollenbeck Standards Track [Page 12] + +RFC 5732 EPP Host Mapping August 2009 + + + C: ABC-12345 + C: + C: + + When a command has been processed successfully, the EPP + element MUST contain a child element that + identifies the host namespace. The element contains + the following child elements: + + - A element that contains the fully qualified name of + the host object. + + - A element that contains the date and time of host- + object creation. + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: ns1.example.com + S: 1999-04-03T22:00:00.0Z + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + An EPP error response MUST be returned if a command cannot + be processed for any reason. + +3.2.2. EPP Command + + The EPP command provides a transform operation that allows a + client to delete a host object. In addition to the standard EPP + command elements, the command MUST contain a + element that identifies the host namespace. The + element contains the following child elements: + + + + +Hollenbeck Standards Track [Page 13] + +RFC 5732 EPP Host Mapping August 2009 + + + - A element that contains the fully qualified name of + the host object to be deleted. + + A host name object SHOULD 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 SHOULD NOT be + deleted until the existing association has been broken. Deleting a + host object without first breaking existing associations can cause + DNS resolution failure for domain objects that refer to the deleted + host object. + + Example command: + + C: + C: + C: + C: + C: + C: ns1.example.com + C: + C: + C: ABC-12345 + C: + C: + + When a command has been processed successfully, a server + MUST respond with an EPP response with no element. + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + + An EPP error response MUST be returned if a command cannot + be processed for any reason. + + + + + +Hollenbeck Standards Track [Page 14] + +RFC 5732 EPP Host Mapping August 2009 + + +3.2.3. EPP Command + + Renewal semantics do not apply to host objects, so there is no + mapping defined for the EPP command. + +3.2.4. EPP Command + + Transfer semantics do not directly apply to host objects, so there is + no mapping defined for the EPP 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. + +3.2.5. EPP Command + + The EPP 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 command MUST contain a + element that identifies the host namespace. The element contains the following child elements: + + - A element that contains the fully qualified name of + the host object to be updated. + + - An OPTIONAL element that contains attribute values to + be added to the object. + + - An OPTIONAL element that contains attribute values to + be removed from the object. + + - An OPTIONAL element that contains object attribute + values to be changed. + + At least one , , or element MUST be + provided if the command is not being extended. All of these elements + MAY be omitted if an extension is present. The + and elements contain the following child elements: + + - One or more elements that contain IP addresses to be + associated with or removed from the host object. IP address + restrictions described in the command mapping apply here + as well. + + - One or more 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. + + + + + +Hollenbeck Standards Track [Page 15] + +RFC 5732 EPP Host Mapping August 2009 + + + A element contains the following child elements: + + - A 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 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 any needed new attributes, and subsequently updating the + other objects sponsored by the client. + + Example command: + + C: + C: + C: + C: + C: + C: ns1.example.com + C: + C: 192.0.2.22 + C: + C: + C: + C: 1080:0:0:0:8:800:200C:417A + C: + C: + C: ns2.example.com + C: + C: + C: + C: ABC-12345 + C: + C: + + When an command has been processed successfully, a server + MUST respond with an EPP response with no element. + + + + + +Hollenbeck Standards Track [Page 16] + +RFC 5732 EPP Host Mapping August 2009 + + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + + An EPP error response MUST be returned if an command could + not be processed for any reason. + +3.3. 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 command that requires offline review + are included here. Note the result code and message returned in + response to the command. + + S: + S: + S: + S: + S: Command completed successfully; action pending + S: + S: + S: + S: ns1.example.com + S: 1999-04-03T22:00:00.0Z + S: + S: + + + +Hollenbeck Standards Track [Page 17] + +RFC 5732 EPP Host Mapping August 2009 + + + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + 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 either by + queuing a service message for retrieval via the command or by + using an out-of-band mechanism to inform the client of the request. + + The service message MUST contain text that describes the notification + in the child element of the response element. In + addition, the EPP element MUST contain a child element that identifies the host namespace. The element contains the following child elements: + + - A element that contains the fully qualified name of + the host object. The 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 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 command. + + - A element that contains the date and time describing + when review of the requested action was completed. + + Example "review completed" service message: + + S: + S: + S: + S: + S: Command completed successfully; ack to dequeue + S: + S: + S: 1999-04-04T22:01:00.0Z + S: Pending action completed successfully. + S: + S: + + + +Hollenbeck Standards Track [Page 18] + +RFC 5732 EPP Host Mapping August 2009 + + + S: + S: ns1.example.com + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: 1999-04-04T22:00:00.0Z + S: + S: + S: + S: BCD-23456 + S: 65432-WXY + S: + S: + S: + +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. + + Copyright (c) 2009 IETF Trust and the persons identified as authors + of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions + are met: + + o Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + + o Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in + the documentation and/or other materials provided with the + distribution. + + o Neither the name of Internet Society, IETF or IETF Trust, nor the + names of specific contributors, may be used to endorse or promote + products derived from this software without specific prior written + permission. + + + + + + +Hollenbeck Standards Track [Page 19] + +RFC 5732 EPP Host Mapping August 2009 + + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + BEGIN + + + + + + + + + + + Extensible Provisioning Protocol v1.0 + host provisioning schema. + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 20] + +RFC 5732 EPP Host Mapping August 2009 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 21] + +RFC 5732 EPP Host Mapping August 2009 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 22] + +RFC 5732 EPP Host Mapping August 2009 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 24] + +RFC 5732 EPP Host Mapping August 2009 + + + + + + + + + + + + + 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 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 + form using upper case "T" and "Z" characters defined in + [W3C.REC-xmlschema-2-20041028] 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. + + The syntax for domain and host names described in this document MUST + conform to [RFC0952] and [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. + + + + +Hollenbeck Standards Track [Page 25] + +RFC 5732 EPP Host Mapping August 2009 + + + 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 [RFC5730] or those caused by the protocol layers + used by EPP. + +8. Acknowledgements + + RFC 3732 is a product of the PROVREG working group, which suggested + improvements and provided many invaluable comments. The author + wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap + Akkerhuis for their process and editorial contributions. RFC 4932 + and this document are individual submissions, based on the work done + in RFC 3732. + + 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 + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet + host table specification", RFC 952, October 1985. + + + +Hollenbeck Standards Track [Page 26] + +RFC 5732 EPP Host Mapping August 2009 + + + [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. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, August 2009. + + [W3C.REC-xml-20040204] + Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J., + and T. Bray, "Extensible Markup Language (XML) 1.0 (Third + Edition)", World Wide Web Consortium FirstEdition REC-xml- + 20040204, February 2004, + . + + [W3C.REC-xmlschema-1-20041028] + Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, + "XML Schema Part 1: Structures Second Edition", World Wide + Web Consortium Recommendation REC-xmlschema-1-20041028, + October 2004, + . + + [W3C.REC-xmlschema-2-20041028] + Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes + Second Edition", World Wide Web Consortium + Recommendation REC-xmlschema-2-20041028, October 2004, + . + +9.2. Informative References + + [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO + 10646", RFC 2781, February 2000. + + + + + + +Hollenbeck Standards Track [Page 27] + +RFC 5732 EPP Host Mapping August 2009 + + + [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support + IPv6 Address Aggregation and Renumbering", RFC 2874, + July 2000. + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + RFC 3490, March 2003. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [RFC4932] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Host Mapping", RFC 4932, May 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 28] + +RFC 5732 EPP Host Mapping August 2009 + + +Appendix A. Changes from RFC 4932 + + 1. Changed "This document obsoletes RFC 3732" to "This document + obsoletes RFC 4932". + + 2. Replaced references to RFC 1886 with references to 3596. + + 3. Removed references to RFC 3152 since both it and 1886 have been + obsoleted by 3596. + + 4. Replaced references to RFC 3732 with references to 4932. + + 5. Replaced references to RFC 4930 with references to 5730. + + 6. Added "Other notification methods MAY be used in addition to the + required service message" in Section 3.2. + + 7. Added 2201 response code text in Section 3.2. + + 8. Added BSD license text to XML schema section. + + +Author's Address + + Scott Hollenbeck + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + US + + EMail: shollenbeck@verisign.com + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 29] + -- cgit v1.2.3