Network Working Group J. Gould Internet-Draft L. Jia Intended status: Standards Track VeriSign, Inc. Expires: December 2, 2018 R. Carney J. Kolker GoDaddy Inc. May 31, 2018 Registry Mapping for the Extensible Provisioning Protocol (EPP) draft-gould-carney-regext-registry-00 Abstract This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning registry zones (e.g. top-level domains) in a Domain Name Registry. The attributes of a registry zone include the features and policies of the registry zone. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 2, 2018. Copyright Notice Copyright (c) 2018 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Gould, et al. Expires December 2, 2018 [Page 1] Internet-Draft registry May 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Zone Name . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Dates and Times . . . . . . . . . . . . . . . . . . . . . 4 2.3. Schedule . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Zone Object . . . . . . . . . . . . . . . . . . . . . . . 5 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 23 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 24 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 24 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 26 3.1.3. EPP Query Command . . . . . . . . . . . . 32 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 32 3.2.1. EPP Command . . . . . . . . . . . . . . . . 33 3.2.2. EPP Command . . . . . . . . . . . . . . . . 34 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 35 3.2.4. EPP Command . . . . . . . . . . . . . . . 35 3.2.5. EPP Command . . . . . . . . . . . . . . . . 36 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1. Registry Mapping Schema . . . . . . . . . . . . . . . . . 37 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 58 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 58 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 59 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 9.1. Normative References . . . . . . . . . . . . . . . . . . 59 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 1. Introduction This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This document describes a Domain Name Registry Mapping, referred to as Registry Mapping, for the Extensible Provisioning Protocol (EPP) [RFC5730]. A Domain Name Registry can service one or more registry zones (e.g. top-level domains) with a variety of supported services and policies. A registry zone, also referred to as a "zone" in this document, is a domain name that the Domain Name Registry supports provisioning operations to manage. The registry zone and the associated DNS zone Gould, et al. Expires December 2, 2018 [Page 2] Internet-Draft registry May 2018 has an overlapping data set, where the registry zone is the source for the generation of a DNS zone. A registry zone is typically a top-level domain name, but it can be a domain name at any domain name level. A registry zone can be the source for multiple resolution services like DNS and WHOIS. This mapping enables the provisioning of the features and policies of the registry zones in the Domain Name Registry. A Domain Name Registry MAY support a subset of all of the commands defined in this mapping and can authorize different clients to execute specific commands. For example, all clients may be capable of executing the EPP Query Commands (Section 3.1), while internal clients or pre- defined external clients may be capable of executing the EPP Transform Commands (Section 3.2) for a specific set of zones. It is up to server policy to define what clients are authorized to execute which commands on which registry zones. The server policy can be defined out-of-band or in a seperate EPP extension. 1.1. 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 RFC 2119 [RFC2119]. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. 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. The XML namespace prefix "registry" is used for the namespace "urn:ietf:params:xml:ns:registry-0.1", but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. 2. Object Attributes An EPP registry object has attributes and associated values that may 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. Gould, et al. Expires December 2, 2018 [Page 3] Internet-Draft registry May 2018 2.1. Zone Name The zone name is an element that includes an optional "form" attribute that defines the form of the zone name as either "aLabel" or "uLabel", with the default value of "aLabel". The "aLabel" form of a zone name contains all ASCII name labels that conform to [RFC0952] and [RFC1123]. The "uLabel" form of a zone name that includes one or more non-ASCII name labels that can be represented as ASCII labels using [RFC5890]. At the time of this writing, [RFC5890] 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 names. 2.2. 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 XML Schema Part 2 [1] 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.3. Schedule A schedule is defined using the element, in the time zone represented by the OPTIONAL "tz" attribute with the default of "UTC", and containing the first five crontab entry columns with the format: * * * * * - - - - - | | | | | | | | | +----- day of week (0 - 6) (Sunday=0) | | | +------- month (1 - 12) | | +--------- day of month (1 - 31) | +----------- hour (0 - 23) +------------- min (0 - 59) * indicates any legal value A column can include a list of in range values seperated by commas, as in 2,14 "hour" for 2 AM and 2 PM. A column can include an inclusive range of values using two values seperated by a hyphen, as in (1-5) "day of week" for weekdays. Gould, et al. Expires December 2, 2018 [Page 4] Internet-Draft registry May 2018 Example schedule of a batch job that executes at 2 PM Eastern time zone: pendingDelete Pending Delete Batch 0 14 * * * 2.4. Zone Object The Zone object, represented by the element, is the primary object managed by this mapping. The Zone object can apply to any zone level (top level, second level, third level, etc.). The element contains the following child elements: : The zone name that can be at any level (top level, second level, third level, etc.), as described in Section 2.1. : An OPTIONAL server defined grouping of zones where the zones belong to the same deployable unit. : The OPTIONAL EPP namespace URIs of the objects and object extensions supported by the server based on [RFC5730]. The element contains the following child elements: : One or more elements that contain namespace URIs representing the objects that the server is capable of managing for the zone with the required "required" attribute that defines whether the server requires the use of object represented by the URI. : An OPTIONAL element that contains one or more elements that contain namespace URIs representing object extensions support by the server for the zone with the required "required" attribute that defines whether the server requires the use of the object extension represented by the URI. : The OPTIONAL identifier of the client that created the zone. : The date and time of zone object creation. : The OPTIONAL identifier of the client that last updated the zone object. This element MUST NOT be present if the zone has never been modified. : The OPTIONAL date and time of the most recent zone object modification. This element MUST NOT be present if the domain object has never been modified. Gould, et al. Expires December 2, 2018 [Page 5] Internet-Draft registry May 2018 : The OPTIONAL list of batch jobs. The element contains the following child elements: : One or more elements containing the batch job information. The element contains the following child elements: : Name of the batch job, like "autoRenew" or "pendingDelete". : OPTIONAL freeform description of batch job, like "Auto Renew Batch" or "Pending Delete Batch". : Execution schedule for the batch job as defined in Section 2.3, like 0 14 * * *. : The OPTIONAL list of zones that makeup the system when the "perSystem" share policy is used for the internal hosts, external hosts, or contacts. The list of zones are listed independent of the client's privileges to provision domains in the zone. The element contains the following child elements: : One or more elements, as described in Section 2.1, containing the name of the zone that is a member of the system. : The domain name object policy information per [RFC5731]. The element contains the following child elements: : One or more that define the policies for a domain name label for a specific level, defined with the "level" attribute, with a minimum value of "2" for the second level domain name label level. The element contains the following child elements: : An OPTIONAL minimum length of the domain name label. : An OPTIONAL maximum length of the domain name label. Gould, et al. Expires December 2, 2018 [Page 6] Internet-Draft registry May 2018 : An OPTIONAL flag indicating whether the label must start with an alphanumeric character with a default of "false". : An OPTIONAL flag indicating whether the label must end with an alphanumeric character with a default value of "false". : An OPTIONAL flag indicating whether ASCII domain names are supported with a default value of "true". : An OPTIONAL flag indicating whether non-ASCII domain names are supported with a default value of "false". : Zero or more elements that contain a child element that defines the regular expression to apply to domain name label along with an OPTIONAL child element that describes the regular expression with an OPTIONAL "lang" attribute that defines the language of the description with a default value of "en" (English). : An OPTIONAL element that defines the set of reserved domain names starting from that label level. The reserved names can refer to values with more than one level which is relative to the level of the parent element. The element contains the following child elements: : Zero or more elements containing a reserved domain name relative to the level of the parent element. : An OPTIONAL URI that to an externally defined list of reserved domain name relative to the level of the parent element. : The OPTIONAL Internationalized Domain Name (IDN) policy information. The element contains the following child elements: : The OPTIONAL server unique version of the IDN language rules. : An Internationalizing Domain Names in Applications (IDNA) version supported by the server. IDNA represents a collection of documents that describe the protocol and usage for Internationalized Domain for Gould, et al. Expires December 2, 2018 [Page 7] Internet-Draft registry May 2018 Applications like IDNA 2003, with value of 2003, or IDNA 2008, with value of 2008. : The Unicode version supported by the server like the value of "6.0" for Unicode 6.0. : The OPTIONAL encoding for transforming Unicode characters uniquely and reversibly into DNS compatible characters with a default value of "Punycode". : An OPTIONAL boolean value that indicates whether commingling of scripts is allowed with a default value of "false". : Zero or more elements that defines the supported language codes and character code point policy. The required "code" attribute defines the language code for the supported language. The language code SHOULD be an ISO 639 (ISO 639-1 or ISO 639-2) value. The element contains the following child elements: : The OPTIONAL language table URI that contains the set of code points for the language. : An OPTIONAL strategy for the handling of variants for the language. If no element is specified then variants are not supported by the language. The possible values for the element include: "blocked": Variant registrations are blocked for all clients. "restricted": Variant registrations are allowed for client of the original IDN registration. "open": Variant registrations are open to all clients. : The OPTIONAL boolean value that indicates whether the server supports premium domain names with a default value of "false". : The OPTIONAL boolean value that indicates whether contacts are supported with a default value of "true". : Zero or more elements that defines the minimum and maximum number of contacts by contact type. The contact type is defined with the required "type" attribute with the possible values of "admin", "tech", and "billing", and "custom". The OPTIONAL "name" attribute is an identifier, represented in the 7-bit US-ASCII character set, that is used to define the name of the "custom" type. Gould, et al. Expires December 2, 2018 [Page 8] Internet-Draft registry May 2018 If "custom" is the contact "type" value, then the "name" attribute MUST be set. The OPTIONAL "description" attribute can be set with a description of the contact type. The element contains the following child elements: : The minimum number of contacts for the contact type. : The OPTIONAL maximum number of contacts for the contact type. If the element is not defined the maximum number is unbounded. The element MUST NOT be less than the element. : Defines the minimum and maximum number of delegated host objects (name servers) that can be associated with a domain object. The element contains the following child elements: : The minimum number of name servers associated with a domain object. : The OPTIONAL maximum number of name servers associated with a domain object. If the element is not defined the maximum number is unbounded. The element MUST NOT be less than the element. : Defines the minimum and maximum number of subordinate host objects (child hosts) for a domain object. The element contains the following child elements: : The minimum number of child hosts for a domain object. : The OPTIONAL maximum number of child hosts for a domain object. If the element is not defined the maximum number is unbounded. The element MUST NOT be less than the element. : Zero or more elements that defines the supported registration periods and default periods by command type. The required "command" attribute defines the command type with sample values of "create", "renew", and "transfer". The element contains one of the following elements: Gould, et al. Expires December 2, 2018 [Page 9] Internet-Draft registry May 2018 : The default, minimum, and maximum period length for the command type. The element contains the following child elements, where all of the child elements require the "unit" attribute with possible values of "y" for year and "m" for month: : The minimum supported period length. : The maximum supported period length. The element MUST NOT be less than the element. : The default period length if not defined by the client. or : The registration period is decided by the server based on the relationship to a related object that MUST have the same expiration date. : The period of time a domain object is in the pending transfer before the transfer is auto approved by the server. The element MUST have the "unit" attribute with the possible values of "y" for year, "m" for month, and "d" for day. : Zero or more elements that defines the grace periods by operation type. The required "command" attribute defines the operation type with the sample values of "create", "renew", "transfer", and "autoRenew". The element requires the "unit" attribute with the possible values of "d" for day, "h" for hour, and "m" for minute. : The OPTIONAL Registry Grace Period (RGP) status periods. The element contains the following child elements, where each child element supports the "unit" attribute with the possible values of "y" for year, "m" for month, "d" for day, and "h" for hour: : The length of time that a domain object will remain in the redemptionPeriod status unless the restore request command is received. : The length of time that the domain object will remain in the pendingRestore status unless the restore report command is received. : The length of time that the domain object will remain in the pendingDelete status prior to being purged. : The OPTIONAL DNS Security Extensions (DNSSEC) policies for the server. The element contains the following child elements: Gould, et al. Expires December 2, 2018 [Page 10] Internet-Draft registry May 2018 : Defines the DS Data Interface, as defined in [RFC5910], policies. The element contains the following child elements: : The minimum number of DS associated with the domain object. : The maximum number of DS associated with the domain object. The element MUST NOT be less than the element. : Zero or more elements that define the supported algorithms as described in section 5.1.2 of [RFC4034]. : Zero or more elements that define the supported digest types as described in section 5.1.3 of [RFC4034]. : Defines the Key Data Interface, as defined in [RFC5910], policies. The element contains the following child elements: : The minimum number of keys associated with the domain object. : The maximum number of keys associated with the domain object. The element MUST NOT be less than the element. : Zero or more elements that define the supported algorithms as described in section 2.1.3 of [RFC4034]. : Defines the maximum signature lifetime policies. The element contains the following child elements: : An OPTIONAL boolean flag indicating whether the client can set the maximum signature lifetime with a default value of "false". : The OPTIONAL default maximum signature lifetime set by the server. : An OPTIONAL minimum f signature lifetime supported. The element MUST NOT be defined if the element value is "false". : An OPTIONAL maximum signature lifetime supported. The element MUST NOT be Gould, et al. Expires December 2, 2018 [Page 11] Internet-Draft registry May 2018 defined if the element value is "false". The element MUST NOT be less than the element. : An OPTIONAL flag that of whether the client can specify the urgent attribute for DNSSEC updates with a default value of "false". : The maximum number of domain names ( elements) that can be included in a domain check command defined in [RFC5731]. : The OPTIONAL set of supported domain statuses defined in [RFC5731]. : The OPTIONAL regular expression used to validate the domain object authorization information value. : The OPTIONAL expiry policy used to define what happens when the domain object expires with a default value of "autoRenew". The possible values for the element include: "autoRenew": The domain object will auto-renew at expiry. The client can receive a credit for the auto-renew if the domain object is deleted within the auto-renew grace period. "autoDelete": The domain object will auto-delete at expiry. The client needs to explicitly renew the domain object prior to its expiry to ensure that it does not get deleted. "autoExpire": The domain object will auto-expire at expiry that may include the server placing the domain object on serverHold. "autoParked": The domain object will be auto-parked at expiry that results in the resolution of the domain object going to a parked page. : The host object policy information per [RFC5732]. The element contains the following child elements: : Defines the minimum and maximum number of IP addresses supported for an internal host. The elements contains the following child elements: : Minimum number of IP addresses supported for an internal host. Gould, et al. Expires December 2, 2018 [Page 12] Internet-Draft registry May 2018 : Maximum number of IP addresses supported for an internal host. The element MUST NOT be less than the element. : The OPTIONAL policy for the sharing of internal hosts in the server. The possible shared policy values include: "perZone": The internal hosts are shared across all domains of the zone. There is a single pool of internal hosts defined for the zone. "perSystem": The internal hosts are shared across all zones of the system. There is a single pool of internal hosts across all of the zones supported by the system. The system MUST be defined using the element. : The OPTIONAL boolean value that indicates that all of the IP addresses for the host object must be unique, with a default value of "false". : Defines the policies for external hosts. The elements contains the following child elements: : Minimum number of IP addresses supported for an external host. : Maximum number of IP addresses supported for an external host. The element MUST NOT be less than the element. : The OPTIONAL policy for the sharing of external hosts in the server. The possible shared policy values include: "perZone": The external hosts are shared across all domains of the zone. There is a single pool of external hosts defined for the zone. "perSystem": The external hosts are shared across all zones of the system. There is a single pool of external hosts across all of the zones supported by the system. The system MUST be defined using the element. : The OPTIONAL boolean value that indicates that all of the IP addresses for the host object must be unique, with a default value of "false". Gould, et al. Expires December 2, 2018 [Page 13] Internet-Draft registry May 2018 : Zero or more elements that define the regular expressions used to validate the host name value. : The maximum number of host names ( elements) that can be included in a host check command defined in [RFC5732]. : The OPTIONAL set of supported host statuses defined in [RFC5732]. : The OPTIONAL contact object policy information per [RFC5733]. The element contains the following child elements: : The OPTIONAL regular expression used to validate the element defined in [RFC5733]. : The OPTIONAL policy for the sharing of contacts in the server. The possible shared policy values include: "perZone": The contacts are shared across all objects of the zone. There is a single pool of contacts defined for the zone. "perSystem": The contacts are shared across all zones of the system. There is a single pool of contacts across all of the zones supported by the system. The system MUST be defined using the element. : The policy associated with the postal-address information, represented by the element in [RFC5733], supported with the following possible values: "loc": Indicates that a single element is supported with the type "loc". "int": Indicates that a single element is supported with the type "int". "locOrInt": Indicates that a single element is supported with the type "loc" or "int". "locAndInt": Indicates that up to two elements is supported for defining both the "loc" and the "int" type. This policy does not indicate that both must be provided. : The postal-address information policy information. The element contains the following child elements: Gould, et al. Expires December 2, 2018 [Page 14] Internet-Draft registry May 2018 : The minimum and maximum length of element defined [RFC5733] using the and child elements, respectively. : The minimum and maximum length of the element defined in [RFC5733] using the and child elements, respectively. : The address information policy information. The element contains the following child elements: : The minimum and maximum length and the minimum and maximum number of the elements defined in [RFC5733]. The element contains the following child elements: : The minimum length of the elements. : The maximum length of the elements. The element MUST NOT be less than the element. : The minimum number of elements. : The maximum number of elements. The element MUST NOT be less than the element. : The minimum and maximum length of the and child elements, respectively. : The minimum and maximum length of the element defined in [RFC5733] using the and child elements, respectively. : The minimum and maximum length of the element defined in [RFC5733] using the and child elements, respectively. : An OPTIONAL boolean flag indicating whether the server requires the element to be defined, with a default value of "false". Gould, et al. Expires December 2, 2018 [Page 15] Internet-Draft registry May 2018 : The OPTIONAL minimum and maximum length of the extension "x" attribute defined in [RFC5733] using the and child elements, respectively. : Zero or more elements that define the regular expressions used to validate the element defined in [RFC5733]. : The maximum number of contact identifiers ( elements) that can be included in a contact check command defined in [RFC5733]. : The OPTIONAL regular expression used to validate the contact object authorization information value. : The OPTIONAL flag that indicates whether the server supports the client to identify elements that require exception server-operator handling to allow or restrict disclosure to third parties defined in [RFC5733] with a default of "false". : The OPTIONAL set of supported contact statuses defined in [RFC5733]. : The OPTIONAL period of time a contact object is in the pending transfer before the transfer is auto approved by the server. The element MUST have the "unit" attribute with the possible values of "y" for year, "m" for month, and "d" for day. : An OPTIONAL boolean value that indicates whether a privacy contact is supported with a default value of "true". : An OPTIONAL boolean value that indicates whether a proxy contact is supported with a default value of "true". Example of a element: EXAMPLE STANDARD urn:ietf:params:xml:ns:domain-1.0 urn:ietf:params:xml:ns:host-1.0 urn:ietf:params:xml:ns:contact-1.0 Gould, et al. Expires December 2, 2018 [Page 16] Internet-Draft registry May 2018 urn:ietf:params:xml:ns:rgp-1.0 urn:ietf:params:xml:ns:secDNS-1.1 http://www.verisign-grs.com/epp/namestoreExt-1.1 http://www.verisign.com/epp/idnLang-1.0 clientX 2012-10-01T00:00:00.0Z clientY 2012-10-15T00:00:00.0Z pendingDelete Pending Delete Batch 0 14 * * * EXAMPLE EXAMPLE2 5 50 true false true Gould, et al. Expires December 2, 2018 [Page 17] Internet-Draft registry May 2018 false ^\w+.*$ Alphanumeric ^\d+.*$ reserved1 4.1 2008 6.0 Punycode false http://www.iana.org/idn-tables/test_tab1_1.1.txt blocked false 1 1 1 1 Gould, et al. Expires December 2, 2018 [Page 18] Internet-Draft registry May 2018 0 0 0 1 0 13 0 1 10 1 5 5 5 5 45 Gould, et al. Expires December 2, 2018 [Page 19] Internet-Draft registry May 2018 30 7 5 0 13 3 1 false 5 ok clientDeleteProhibited serverDeleteProhibited clientHold serverHold clientRenewProhibited serverRenewProhibited clientTransferProhibited serverTransferProhibited clientUpdateProhibited serverUpdateProhibited inactive pendingDelete Gould, et al. Expires December 2, 2018 [Page 20] Internet-Draft registry May 2018 pendingTransfer ^.*$ autoRenew 1 13 perSystem false 0 0 perSystem ^.*$ 5 ok clientDeleteProhibited serverDeleteProhibited clientUpdateProhibited serverUpdateProhibited linked pendingDelete pendingTransfer Gould, et al. Expires December 2, 2018 [Page 21] Internet-Draft registry May 2018 ^.*$ perZone int 5 15 2 40 1 40 1 3 1 40 1 40 1 40 false 1 40 1 40 Gould, et al. Expires December 2, 2018 [Page 22] Internet-Draft registry May 2018 ^.+\..+$ 5 ^.*$ false ok clientDeleteProhibited serverDeleteProhibited clientTransferProhibited serverTransferProhibited clientUpdateProhibited serverUpdateProhibited linked pendingDelete pendingTransfer 5 true true 3. EPP Command Mapping A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mappings described here are specifically for use in provisioning and managing TLD names via EPP. Gould, et al. Expires December 2, 2018 [Page 23] Internet-Draft registry May 2018 3.1. EPP Query Commands EPP [RFC5730] provides three commands to retrieve object information: to determine if an object is known to the server, to retrieve detailed information associated with an object, and to retrieve object transfer status information. 3.1.1. EPP Command The EPP command is used to determine if the server currently supports a zone. If the response indicates that the zone is not available, then it is currently supported; otherwise it MAY be available to be created by an authorized client. In addition to the standard EPP command elements, the command MUST contain a element that identifies the registry namespace. The element contains the following child elements: : One or more elements, as described in Section 2.1, that contain the fully qualified names of the zone objects to be queried. Example command: C: C: C: C: C: C: zone1 C: zone2 C: zone3 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 registry namespace. The element contains one or more elements that contain the following child elements: : element that contains the fully qualified name of the queried zone object, as described in Section 2.1. This Gould, et al. Expires December 2, 2018 [Page 24] Internet-Draft registry May 2018 element MUST contain an "avail" attribute whose value indicates zone is currently supported or availability at the moment the command was completed for an authorized client. A value of "1" or "true" means that the zone object is available for an authorized client. A value of "0" or "false" means that the zone object is currently supported by the server. : The OPTIONAL element that MAY be provided when a zone object is not available for provisioning. If present, this element contains server-specific text to help explain why the zone object is unavailable. 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 a default value of "en" (English). Gould, et al. Expires December 2, 2018 [Page 25] Internet-Draft registry May 2018 Example response: S: S: S: S: S: Command completed successfully S: S: S: S: S: zone1 S: Client not authorized S: S: S: S: zone2 S: S: Already supported S: S: S: S: zone3 S: S: 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.1.2. EPP Command The EPP command is used to retrieve information associated with a zone object. The response to this command MAY vary depending on the identity of the querying client, use of authorization information, and server policy towards unauthorized clients. Server policy determines which OPTIONAL elements are returned. Gould, et al. Expires December 2, 2018 [Page 26] Internet-Draft registry May 2018 In addition to the standard EPP command elements, the command MUST contain a element that identifies the registry namespace. The element contains one of the following three child elements: : Element that is empty and that indicates that a list of all of the supported zone objects are queried with a summary set of attributes per zone object. : Element that contains the fully qualified name of the zone object to be queried for a full set of attributes for the zone object. : Element that is empty and that indicates that the registry system attributes, like maximum connections and timeouts, are queried. Example command to query for a summary set of attributes for all of the supported zone objects: C: C: C: C: C: C: C: C: C: ABC-12345 C: C: Example command to query for the full set of "zone1" zone object attributes: C: C: C: C: C: C: zone1 C: C: C: ABC-12345 C: C: Gould, et al. Expires December 2, 2018 [Page 27] Internet-Draft registry May 2018 Example command to query for registry system attributes: C: C: C: C: C: C: 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 registry namespace. The element contains one of the three following child elements: : Element that contains the list of supported zones by the server with a set of summary attributes per zone. The element contains the following child elements: : Element that contains the fully qualified name of the queried zone object. : The date and time of zone object creation. : The OPTIONAL date and time of the most recent zone object modification. This element MUST NOT be present if the zone object has never been modified. or a : Element that contains the full set of attributes for the zone name as defined in Section 2.4. : Element that contains registry system attributes. The element contains the following child elements: : The OPTIONAL element that contains the maximum number of connections that the client can establish with the registry system. : The OPTIONAL element that contains the idle timeout for a connection in milliseconds. If a connection does not receive a command within milliseconds, the server will close the connection. Gould, et al. Expires December 2, 2018 [Page 28] Internet-Draft registry May 2018 : The OPTIONAL element that contains the absolute timeout for a connection in milliseconds. The absolute timeout represents the maximum duration in milliseconds that a connection can be established. The server will close a connection that has been established for more than milliseconds. : The OPTIONAL element that contains the command timeout for a connection in milliseconds. The server will close a connection that has an active command that exceeds milliseconds. : The OPTIONAL element that contains the maximum number of transactions that can be submitted on the connection per the "perMs" attribute milliseconds. It is up to server policy what to do with the connection when the client exceeds the . Gould, et al. Expires December 2, 2018 [Page 29] Internet-Draft registry May 2018 Example response to a query for a summary of all of the supported zone objects: S: S: S: S: S: Command completed successfully S: S: S: S: S: S: EXAMPLE1 S: 2012-10-01T00:00:00.0Z S: S: 2012-10-15T00:00:00.0Z S: S: S: S: EXAMPLE2 S: 2012-09-01T00:00:00.0Z S: S: 2012-09-19T00:00:00.0Z S: S: S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: Gould, et al. Expires December 2, 2018 [Page 30] Internet-Draft registry May 2018 Example response to query for the full set of "EXAMPLE" zone object attributes: S: S: S: S: S: Command completed successfully S: S: S: S: S: EXAMPLE S: ... S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: Gould, et al. Expires December 2, 2018 [Page 31] Internet-Draft registry May 2018 Example response to query for the registry system attributes: S: S: S: S: S: Command completed successfully S: S: S: S: S: 200 S: S: 600000 S: S: 86400000 S: S: 10000 S: S: 10 S: S: 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 zone objects, so there is no mapping defined for the EPP query command. 3.2. EPP Transform Commands EPP provides five commands to transform objects: to create an instance of an object, to delete an instance of an object, to extend the validity period of an object, to manage object sponsorship changes, and to change information associated with an object. Gould, et al. Expires December 2, 2018 [Page 32] Internet-Draft registry May 2018 3.2.1. EPP Command The EPP command provides a transform operation that allows a client to create a zone object. In addition to the standard EPP command elements, the command MUST contain a element that identifies the registry namespace. The element contains the following child elements: : Element that contains the full set of attributes for the zone to create as defined in Section 2.4. Example command: C: C: C: C: C: C: C: EXAMPLE C: ... C: 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 registry namespace. The element contains the following child elements: : element that contains the fully qualified name of the zone object. : element that contains the date and time of zone object creation. Gould, et al. Expires December 2, 2018 [Page 33] Internet-Draft registry May 2018 Example response: S: S: S: S: S: Command completed successfully S: S: S: S: zone1 S: 2012-10-30T22:00:00.0Z S: S: 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.2. EPP Command The EPP command provides a transform operation that allows a client to delete a zone object. In addition to the standard EPP command elements, the command MUST contain a element that identifies the registry namespace. The element contains the following child elements: : element that contains the fully qualified name of the zone object to be deleted. Gould, et al. Expires December 2, 2018 [Page 34] Internet-Draft registry May 2018 Example command: C: C: C: C: C: C: EXAMPLE C: C: C: ABC-12345 C: C: When a zone 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 Renew semantics do not directly apply to zone objects, so there is no mapping defined for the EPP command. 3.2.4. EPP Command Transfer semantics do not directly apply to zone objects, so there is no mapping defined for the EPP command. Gould, et al. Expires December 2, 2018 [Page 35] Internet-Draft registry May 2018 3.2.5. EPP Command The EPP command provides a transform operation that allows a client to modify the attributes of a zone object. In addition to the standard EPP command elements, the command MUST contain a element that identifies the registry namespace. The element contains the following child elements: : One or more elements that contain the full set of attributes for the zones as defined in Section 2.4. The update completely replaces the prior version of the zone. Example command: C: C: C: C: C: C: C: EXAMPLE C: ... 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 command: S: S: S: S: S: Command completed successfully S: S: S: ABC-12345 S: 54321-XYZ S: S: S: Gould, et al. Expires December 2, 2018 [Page 36] Internet-Draft registry May 2018 An EPP error response MUST be returned if an command can not be processed for any reason. 4. Formal Syntax One schema is presented here that is the EPP Registry Mapping Schema. 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. 4.1. Registry Mapping Schema BEGIN Extensible Provisioning Protocol v1.0 Registry Mapping Schema. Gould, et al. Expires December 2, 2018 [Page 39] Internet-Draft registry May 2018 Gould, et al. Expires December 2, 2018 [Page 42] Internet-Draft registry May 2018 Gould, et al. Expires December 2, 2018 [Page 44] Internet-Draft registry May 2018 Gould, et al. Expires December 2, 2018 [Page 45] Internet-Draft registry May 2018 Gould, et al. Expires December 2, 2018 [Page 46] Internet-Draft registry May 2018 Gould, et al. Expires December 2, 2018 [Page 47] Internet-Draft registry May 2018 Gould, et al. Expires December 2, 2018 [Page 49] Internet-Draft registry May 2018 Gould, et al. Expires December 2, 2018 [Page 50] Internet-Draft registry May 2018 Gould, et al. Expires December 2, 2018 [Page 51] Internet-Draft registry May 2018 Gould, et al. Expires December 2, 2018 [Page 54] Internet-Draft registry May 2018 END 5. IANA Considerations 5.1. XML Namespace This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Registration request for the registry namespace: URI: urn:ietf:params:xml:ns:registry-0.1 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification. Registration request for the registry XML schema: URI: urn:ietf:params:xml:ns:registry-0.1 Registrant Contact: IESG XML: See the "Formal Syntax" section of this document. 5.2. EPP Extension Registry The EPP extension described in this document should be registered by the IANA in the EPP Extension Registry described in [RFC7451]. The details of the registration are as follows: Gould, et al. Expires December 2, 2018 [Page 58] Internet-Draft registry May 2018 Name of Extension: "Registry Mapping for the Extensible Provisioning Protocol (EPP)" Document status: Standards Track Reference: (insert reference to RFC version of this document) Registrant Name and Email Address: IESG, TLDs: Any IPR Disclosure: TBD Status: Active Notes: None 6. Implementation Status TBD 7. Security Considerations The mapping extensions described in this document do not provide any security services beyond those described by EPP [RFC5730] and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well. 8. Acknowledgements TBD 9. References 9.1. Normative References [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, DOI 10.17487/RFC0952, October 1985, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . Gould, et al. Expires December 2, 2018 [Page 59] Internet-Draft registry May 2018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, . [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, DOI 10.17487/RFC5910, May 2010, . [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, . Gould, et al. Expires December 2, 2018 [Page 60] Internet-Draft registry May 2018 9.2. URIs [1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ Appendix A. Change History Authors' Addresses James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: jgould@verisign.com URI: http://www.verisigninc.com Lin Jia VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: ljia@verisign.com URI: http://www.verisigninc.com Roger Carney GoDaddy Inc. 14455 N. Hayden Rd. #219 Scottsdale, AZ 85260 US Email: rcarney@godaddy.com URI: http://www.godaddy.com Jody Kolker GoDaddy Inc. 14455 N. Hayden Rd. #219 Scottsdale, AZ 85260 US Email: jkolker@godaddy.com URI: http://www.godaddy.com Gould, et al. Expires December 2, 2018 [Page 61]