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/rfc3732.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc3732.txt (limited to 'doc/rfc/rfc3732.txt') 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 Command . . . . . . . . . . . . . . 6 + 3.1.2. EPP Command. . . . . . . . . . . . . . . 8 + 3.1.3. EPP Query Command. . . . . . . . . . 10 + 3.2. EPP Transform Commands. . . . . . . . . . . . . . . . . 11 + 3.2.1. EPP Command. . . . . . . . . . . . . . 11 + 3.2.2. EPP Command. . . . . . . . . . . . . . 13 + 3.2.3. EPP Command . . . . . . . . . . . . . . 14 + 3.2.4. EPP Command. . . . . . . . . . . . . 14 + 3.2.5. EPP 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 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 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: 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 and the location of the host schema. 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 + + + +Hollenbeck Standards Track [Page 6] + +RFC 3732 EPP Host Mapping March 2004 + + + C: + C: + + When a command has been processed successfully, the EPP + element MUST contain a child element that + identifies the host namespace and the location of the host schema. + The element contains one or more elements + that contain the following child elements: + + - 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 can + not be provisioned. + + - An OPTIONAL 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 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 + + + +Hollenbeck Standards Track [Page 7] + +RFC 3732 EPP Host Mapping March 2004 + + + S: + S: + S: ns3.example3.com + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + An EPP error response MUST be returned if a command can not + 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 and the location of the host schema. + 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: + + + + + +Hollenbeck Standards Track [Page 8] + +RFC 3732 EPP Host Mapping March 2004 + + + When an command has been processed successfully, the EPP + element MUST contain a child element that + identifies the host namespace and the location of the host schema. + 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. + + - 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. + + + + + + + +Hollenbeck Standards Track [Page 9] + +RFC 3732 EPP Host Mapping March 2004 + + + 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 + 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 can not + 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. + + + + + + +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: 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 + 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 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 and the location of the + host schema. 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 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 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: + 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 and the location of the host schema. + 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 can not + 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 and the location of the + host schema. The element contains the following child + elements: + + - A 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 command: + + C: + C: + + + +Hollenbeck Standards Track [Page 13] + +RFC 3732 EPP Host Mapping March 2004 + + + 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 can not + be processed for any reason. + +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. + + + +Hollenbeck Standards Track [Page 14] + +RFC 3732 EPP Host Mapping March 2004 + + +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 and the + location of the host schema. 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. 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. + + 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 + + + +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 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. + + Example response: + + S: + S: + S: + S: + + + +Hollenbeck Standards Track [Page 16] + +RFC 3732 EPP Host Mapping March 2004 + + + 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.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 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: + S: + + + +Hollenbeck Standards Track [Page 17] + +RFC 3732 EPP Host Mapping March 2004 + + + 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 by + queuing a service message for retrieval via the command. + + The service message MUST contain text in the , , + element that describes the notification. In addition, the EPP + element MUST contain a child element that + identifies the host namespace and the location of the host schema. + 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: + + + +Hollenbeck Standards Track [Page 18] + +RFC 3732 EPP Host Mapping March 2004 + + + S: + 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. + + BEGIN + + + + + + + + + + + + +Hollenbeck Standards Track [Page 19] + +RFC 3732 EPP Host Mapping March 2004 + + + + Extensible Provisioning Protocol v1.0 + host provisioning schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 20] + +RFC 3732 EPP Host Mapping March 2004 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 21] + +RFC 3732 EPP Host Mapping March 2004 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 22] + +RFC 3732 EPP Host Mapping March 2004 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 23] + +RFC 3732 EPP Host Mapping March 2004 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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 + + + +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] + -- cgit v1.2.3