EPP Registrant Transfer Mapping J. Mitchell AusRegistry Pty Ltd September 2010 Registrant Transfer Mapping for the Extensible Provisioning Protocol (EPP) Abstract This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the transfer of a domain name registrant. Specified in XML, this mapping extends the core EPP protocol to provide one additional command required for the transfer of a domain name registrant. Status of This Document This document specifies an extension to the EPP protocol first implemented in AusRegistry's Domain Name Registry EPP service. Discussion and suggestions for improvements are welcome. Please refer to AusRegistry for more information on the status of this document. Distribution of this document and use of the protocol extensions defined within is unrestricted and unlimited. Copyright Notice Copyright (C) AusRegistry International Pty Ltd (2010) Mitchell [Page 1] EPP Registrant Transfer Mapping September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 2. EPP Protocol Extension . . . . . . . . . . . . . . . . . . . . 3 2.1. Command Format . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. EPP Command . . . . . . . . . . . 4 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Internationalization Considerations . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Mitchell [Page 2] EPP Registrant Transfer Mapping September 2010 1. Introduction This document describes an protocol extension for version 1.0 of the Extensible Provisioning Protocol (EPP) that allows for the transport of a domain name's registrant. This extension 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]. The EPP core protocol specification [RFC5730] provides a complete description of EPP command and response structures. A thorough understanding of the base protocol and specification of relevant extensions is necessary to understand the extension in this document. In addition, this document makes use of elements defined in [AR.KV-1.0] to represent key-value data associated with a domain name. 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 [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. EPP Protocol Extension A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The protocol extensions described here are specifically for use in supporting transfer of domain registrant. The EPP extension framework allows for definition of new protocol elements identified using XML namespace notation with a reference to an XML schema that defines the namespace. The element that identifies the beginning of a protocol instance includes multiple child element choices, one of which is an element whose children define the extension. For example, a protocol extension element would be described in generic terms as follows: 2.1. Command Format An EPP client interacts with an EPP server by sending a command to the server and receiving a response from the server. A detailed Mitchell [Page 3] EPP Registrant Transfer Mapping September 2010 description of the EPP syntax and semantics can be found in [RFC5730]. This document describes an additional EPP domain transform command, , specifically for use in transferring a domain name's registrant. 2.1.1. EPP Command This specification defines an additional EPP command to allow a client to request a transfer of domain registrant. In addition to the standard EPP elements, an EPP command contains the following elements: o A element. o An OPTIONAL (client transaction identifier) element that MAY be used to uniquely identify the command to the client. Clients are responsible for maintaining their own transaction identifier space to ensure uniqueness. The element contains the following child elements: o A element that contains the fully qualified name of the domain object for which the transfer of registrant is being requested. o A element that contains the date on which the current validity period ends. This value ensures that repeated commands do not result in multiple, unanticipated successful transfers of registrant. o An OPTIONAL element that contains the number of units to be added to the registration period of the domain object. The number of units available MAY be subject to limits imposed by the server. o A element that contain the list of key-value items to be associated with the specified domain. A MANDATORY "name" attribute MUST be present to identify the name of the key-value list. The element MUST identify the kv namespace, as defined in [AR.KV-1.0]. o An OPTIONAL element that explains the purpose of the update, e.g. a correction of a spelling mistake. Mitchell [Page 4] EPP Registrant Transfer Mapping September 2010 Example command: C: C: C: C: C: example.com.au C: 1999-04-03Z C: 2 C: C: AusRegistry Pty Ltd C: Company C: 1 C: C: Sale of business C: C: ABC12345 C: C: C: When a command has been processed successfully, the EPP element MUST contain an element that identifies the registrant namespace. The element contains the following child elements. o A element that contains the fully qualified name of the domain object. o An element that contains the date and time identifying the end of the domain object's registration period. Mitchell [Page 5] EPP Registrant Transfer Mapping September 2010 Example response: C: C: C: C: Command completed successfully C: C: C: C: example.com.au C: 2001-04-03T22:00:00.0Z C: C: C: C: ABC12345 C: XYZ54321 C: C: C: When a command has been processed successfully, the EPP element MUST contain an element identifying the registrant namespace. The element contains the following child elements. o A element that contains the fully qualified name of the domain object. o An element that contains the date and time identifying the end of the domain object's registration period. Mitchell [Page 6] EPP Registrant Transfer Mapping September 2010 Example response: C: C: C: C: Command completed successfully C: C: C: C: example.com C: 2001-04-03T22:00:00.0Z C: C: C: C: ABC12345 C: XYZ54321 C: C: C: 3. 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 Mitchell [Page 7] EPP Registrant Transfer Mapping September 2010 .au Domain Extensions to the Extensible Provisioning Protocol v1.0. schema. Mitchell [Page 8] EPP Registrant Transfer Mapping September 2010 END 4. 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 [RFC3629] . 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. As an extension of the EPP core protocol specification [RFC5730] , the elements, element content, attributes, and attribute values described in this document MUST inherit the internationalization conventions used to represent higher-layer domain and core protocol structures present in an XML instance that includes this extension. 5. 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. As with other domain object transforms, the EPP transform operations described in this document MUST be restricted to the sponsoring client as authenticated using the mechanisms described in Sections 2.9.1.1 and 7 of [RFC5730]. Any attempt to perform a transform operation on a domain object by any client other than the sponsoring client MUST be rejected with an appropriate EPP authorization error. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Mitchell [Page 9] EPP Registrant Transfer Mapping September 2010 RFC2119, March 1997, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [AR.KV-1.0] Mitchell, J. and C. Wright, "Key-Value Mapping for the Extensible Provisioning Protocol(EPP)", December 2012. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, . 6.2. Informative References [W3C.REC-xml-20040204] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC- xml-20040204, February 2004, . [W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, . Author's Address James Mitchell AusRegistry Pty Ltd Email: support@ausregistry.com.au Mitchell [Page 10]