Internet Engineering Task Force S. Hollenbeck Internet-Draft VeriSign, Inc. November 10, 2000 Expires: May 10, 2001 Extensible Provisioning Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a connection-oriented, application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. 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. XML protocol elements are case sensitive. Hollenbeck Expires May 10, 2001 [Page 1] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Table of Contents 1. Introduction ................................................. 3 2. Protocol Description ......................................... 4 2.1 Protocol Identification ..................................... 5 2.2 Greeting Format ............................................. 5 2.3 Command Format .............................................. 6 2.4 Response Format ............................................. 7 2.5 Protocol Extension Framework ................................ 10 2.6 Protocol Commands ........................................... 11 2.6.1 Session Management Commands ............................... 11 2.6.1.1 EPP Command ..................................... 11 2.6.1.2 EPP Command .................................... 14 2.6.2 Object Query Commands ..................................... 15 2.6.2.1 EPP Command ...................................... 15 2.6.2.2 EPP Command ...................................... 17 2.6.2.3 EPP Query Command ............................ 19 2.6.3 Object Transform Commands ................................. 22 2.6.3.1 EPP Command .................................... 22 2.6.3.2 EPP Command .................................... 23 2.6.3.3 EPP Command ..................................... 25 2.6.3.4 EPP Command .................................. 27 2.6.3.5 EPP Command .................................... 30 3. Result Codes ................................................. 33 4. Formal Syntax ................................................ 35 5. Internationalization Considerations .......................... 40 6. IANA Considerations .......................................... 41 7. Security Considerations ...................................... 42 8. References ................................................... 43 9. Author's Address ............................................. 44 10. Full Copyright Statement .................................... 45 Appendix A: Object Mapping Outline .............................. 46 Hollenbeck Expires May 10, 2001 [Page 2] Internet-Draft Extensible Provisioning Protocol November 10, 2000 1. Introduction This document describes specifications for the Extensible Provisioning Protocol (EPP) version 1.0, an XML text protocol that permits multiple service providers to perform object provisioning operations using a shared central object repository. EPP is specified using the Extensible Markup Language (XML) 1.0 as described in [XML] and XML Schema notation as described in [XML-SD] and [XML-SS]. EPP meets and exceeds the requirements for a generic registry registrar protocol as described in [GRRP]. The referenced XML Schema documents recently progressed from Working Draft status to Candidate Recommendation status. The references to these documents and the URIs used to refer to XML Schema namespaces MUST be changed once XML parsers that support the updated specifications are available. It is important to note that XML is case sensitive. XML specifications and examples provided in this document MUST be interpreted in the exact character case presented to develop a conforming implementation. This document is being discussed on the "rrp" mailing list. To join the list, send a message to with the words "subscribe rrp" in the body of the message. There is a web site for the list archives at . Hollenbeck Expires May 10, 2001 [Page 3] Internet-Draft Extensible Provisioning Protocol November 10, 2000 2. Protocol Description EPP is a connection-oriented protocol that can be layered over multiple transport protocols. Clients establish a secure connection with a server, exchange identification, authentication, and option information, and then engage in a series of client-initiated command- response exchanges. All EPP commands are atomic and idempotent. Specified in XML, EPP provides four basic service elements: a greeting, commands, responses, and an extension framework that supports future definition of managed objects and the relationship of protocol requests and responses to those objects. An EPP server MUST respond to a successful connection by returning a greeting to the client. The client MUST wait for the greeting before sending an EPP command to the server. EPP commands and responses are exchanged serially between the client and the server. The server MUST respond to each EPP command with a coordinated response that describes the results of processing the command. EPP commands fall into three categories: session management commands, query commands, and data transform commands. Session management commands are used to establish and end sessions with an EPP server. Query commands are used to perform read-only, object-based information retrieval operations. Transform commands are used to perform read- write object management operations. EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects. All XML instances SHOULD begin with an processing instruction to identify the version of XML that is being used and to provide a hint to the XML parser that a schema file is needed to validate the XML instance. Use of character encodings other than those supported in Unicode MUST be noted by an "encoding" attribute within the XML processing instruction. Example XML processing instruction: This processing instruction identifies the XML version as "1.0", specifies default Unicode character encoding, and tells an XML parser that all of the information needed to validate the XML instance is not included in the XML instance. Hollenbeck Expires May 10, 2001 [Page 4] Internet-Draft Extensible Provisioning Protocol November 10, 2000 2.1 Protocol Identification All XML instances of EPP MUST begin with an element. This element identifies the start of an EPP protocol element, the namespace used within the protocol, and the location of the protocol schema. This start element and the associated ending element MUST be applied to all greetings, commands, and responses sent by both clients and servers. Example "start" and "end" XML elements: 2.2 Greeting Format An EPP server responds to a successful connection by returning a greeting to the client. An EPP greeting SHALL contain the following elements: - A element that identifies the start of the greeting. - A element that contains the name of the server. - A element that contains the server's current date and time in UTC. - A element that identifies the features supported by the server, including: - One or more elements that contain the protocol versions supported by the server. - One or more elements that contain the identifiers of the text response languages known by the server. Language identifiers MUST be structured as documented in [RFC1766]. Only language identifiers listed in [ISO639] MAY be used. - One or more object-specific elements that identify the objects that the server is capable of managing. A server MAY limit object management privileges on a per-client basis. Hollenbeck Expires May 10, 2001 [Page 5] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example greeting: S: S: S: S: Example Company EPP server epp.example.com S: 2000-06-08T22:00:00.0Z S: S: 1.0 S: en-US S: fr S: S: S: S: S: S: 2.3 Command Format Once connected, an EPP client interacts with the EPP server by sending a command to the server and waiting for a response to the command before sending the next command. In addition to an EPP identification element, an EPP command MUST contain the following elements: - A element that identifies the start of the command. - A command element whose name corresponds to one of the valid EPP commands described in this document. - A element that uniquely identifies the command to both the client and the server. A transaction identifier SHALL include the following child elements: - A element that contains the date of command execution. - A element that matches the identifier used by the client when establishing a session with the server. Client identifiers MUST be assigned by and unique to the server. - A element that is assigned by and MUST be unique to the client on a per-day basis. Code elements MUST contain a client-coded Hollenbeck Expires May 10, 2001 [Page 6] Internet-Draft Extensible Provisioning Protocol November 10, 2000 combination of letters, numbers, and dashes. Transaction identifiers provide command-response synchronization integrity. They MUST be logged, retained, and protected to ensure that both the client and the server have consistent transaction records. Their uniqueness and required longevity makes them useful as authorization identifiers for EPP commands that require inter-client knowledge of object sponsorship. Example command: S: C: C: C: C: C: example C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: 2.4 Response Format An EPP server responds to client commands by returning a response to the client. EPP commands are atomic, so a command must either succeed completely or fail completely. Success and failure results MUST NOT be mixed.In addition to an EPP identification element, an EPP response SHALL contain the following elements: - A element that identifies the start of the command. - One or more elements that document the success or failure of command execution. If the command was processed successfully, only one element SHALL be returned. If the command was not processed successfully, multiple elements MAY be returned to document failure conditions. Each element SHALL contain the following attribute and child elements: - A "code" attribute whose value is a four-digit, decimal number Hollenbeck Expires May 10, 2001 [Page 7] Internet-Draft Extensible Provisioning Protocol November 10, 2000 that describes the success or failure of the command. - A element containing a human-readable description of the response code. The language of the response is identified via an OPTIONAL "lang" attribute. If not specified, the default attribute value SHALL be "en-US". - An OPTIONAL element that returns a client-provided value that caused a server error condition. - An OPTIONAL element that contains child elements specific to the command and the object subjected to the command. - A element containing the transaction identifier provided with the command for which the response is being returned. The value of the transaction identifier elements MUST match those provided with the command for which the response is returned. Example response without or : S: S: S: S: S: Command completed successfully S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Hollenbeck Expires May 10, 2001 [Page 8] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response with : S: S: S: S: S: Command completed successfully S: S: S: S: example S: S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Hollenbeck Expires May 10, 2001 [Page 9] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response with error : S: S: S: S: S: Parameter value range error S: 2525 S: S: S: Parameter value syntax error S: ex(ample S: abc.ex(ample S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: 2.5 Protocol Extension Framework EPP provides an extensible object management framework that defines the syntax and semantics of protocol operations applied to a managed object. This framework pushes the definition of each protocol operation into the context of a specific object, providing the ability to add mappings for new objects without having to modify the base protocol. Protocol elements that contain data specific to objects are identified using XML namespace notation with a reference to an XML schema that defines the namespace. The schema for EPP supports use of dynamic object schemas on a per-command and per-response basis. For example, the start of an object-specific command element would be described in generic terms as follows: C: C: C: C: C: Hollenbeck Expires May 10, 2001 [Page 10] Internet-Draft Extensible Provisioning Protocol November 10, 2000 An object-specific response element would be described similarly: S: S: S: S: S: This document does not define mappings for specific objects. The mapping of EPP to an object MUST be described in separate documents that specifically address each command and response in the context of the object. A suggested object mapping outline is included as an appendix to this document. 2.6 Protocol Commands EPP provides commands to manage sessions, retrieve object information, and perform transformation operations on objects. All EPP commands are atomic and idempotent, either succeeding completely or failing completely and producing predictable results in case of repeated execution. This section describes each EPP command, including examples with representative server responses. 2.6.1 Session Management Commands EPP provides two commands for session management: to establish a session with a server, and to end a session with a server. 2.6.1.1 EPP Command The EPP command is used to establish a session with an EPP server in response to a greeting issued by the server. A command MUST be sent to a server before any other EPP command. A client identifier and initial password MUST be created on the server before a client can successfully complete a command. The client identifier and initial password MUST be delivered to the client using an out-of-band method that protects the identifier and password from inadvertent disclosure. In addition to the standard EPP command elements, the command SHALL contain the following child elements: - A element that contains the client identifier assigned to the client by the server. The value of this element is case insensitive. Hollenbeck Expires May 10, 2001 [Page 11] Internet-Draft Extensible Provisioning Protocol November 10, 2000 - A element that contains the client's plain text password. Note that EPP uses a variant of the PLAIN SASL authentication mechanism described in [RFC2595]. The value of this element is case sensitive. - An OPTIONAL element that contains a new plain text password to be assigned to the client for use with subsequent commands. The value of this element is case sensitive. - A element that contains the following child elements: - A element that contains the protocol version to be used during the session with the server. - A element that contains the text response language to be used during the session with the server. - One or more object elements that identify the objects to be managed during the session. The values of the and elements MUST exactly match one of the available values presented within the EPP greeting. The PLAIN SASL mechanism presented in [RFC2595] describes a format for providing a user identifier, an authorization identifier, and a password as part of a single plain text string. The EPP authentication mechanism is similar, though EPP does not require a separate authorization identifier and the user identifier and password are separated into distinct XML elements. Hollenbeck Expires May 10, 2001 [Page 12] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example command: C: C: C: C: C: ClientX C: foo-BAR2 C: bar-FOO2 C: C: 1.0 C: en-US C: C: C: C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: When a command has been processed successfully, a server MUST respond with an EPP response with no element. If successful, the server will respond by establishing a new session. Hollenbeck Expires May 10, 2001 [Page 13] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response: S: S: S: S: S: Command completed successfully S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Authorization: all clients MUST be authorized to use the command. A command MUST be rejected if issued during an established session. 2.6.1.2 EPP Command The EPP command is used to end a session with an EPP server. In addition to the standard EPP command elements, the command SHALL contain an empty command element. Example command: C: C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: When a command has been processed successfully, a server MUST respond with an EPP response with no element. If successful, the server MUST also end the current session. Hollenbeck Expires May 10, 2001 [Page 14] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response: S: S: S: S: S: Command completed successfully; ending session S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Authorization: all clients MUST be authorized to use the command. A command MUST NOT be accepted if issued outside the bounds of an established session. 2.6.2 Object Query Commands EPP provides three commands to retrieve object information: to retrieve detailed information associated with a known object, to determine if an object is known to the server, and to retrieve known object transfer status information. 2.6.2.1 EPP Command The EPP command is used to retrieve information associated with a known object. The elements needed to identify an object and the type of information associated with an object are both object- specific, so the child elements of the command are specified using the EPP extension framework. In addition to the standard EPP command elements, the command SHALL contain the following child elements: - An object-specific element that identifies the object to be queried. Hollenbeck Expires May 10, 2001 [Page 15] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example command: C: C: C: C: C: C: example C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: When an command has been processed successfully, a server MUST respond with an EPP element that MUST contain a child element that identifies the object namespace and the location of the object schema. The child elements of the element are object-specific. Hollenbeck Expires May 10, 2001 [Page 16] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response: S: S: S: S: S: Command completed successfully S: S: S: S: example S: ClientY S: ClientX S: 1999-04-03T22:00:00.0Z S: ClientX S: S: 1999-12-03T09:00:00.0Z S: S: S: 2000-04-08 S: ClientY S: ABC-98765-XYZ S: S: S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Authorization: all clients MUST be authorized to use the command. Access to object information MAY be restricted to the client that manages the object. Access to an object's authorization identifier, if present, MUST be restricted to the client that manages the object. 2.6.2.2 EPP Command The EPP command is used to determine if an object is known to the server. The elements needed to identify an object are object- specific, so the child elements of the command are specified Hollenbeck Expires May 10, 2001 [Page 17] Internet-Draft Extensible Provisioning Protocol November 10, 2000 using the EPP extension framework. In addition to the standard EPP command elements, the command SHALL contain the following child elements: - An object-specific element that identify the objects to be queried. Multiple objects of the same type MAY be queried within a single command. Example command: C: C: C: C: C: C: example1 C: example2 C: example3 C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: When an command has been processed successfully, a server MUST respond with an EPP element that MUST contain a child element that identifies the object namespace and the location of the object schema. The child elements of the element are object-specific. Hollenbeck Expires May 10, 2001 [Page 18] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response: S: S: S: S: S: Command completed successfully S: S: S: S: example1 S: example2 S: example3 S: S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Authorization: all clients MUST be authorized to use the command. 2.6.2.3 EPP Query Command The EPP command provides a query operation that allows a client to determine real-time status of pending and completed transfer requests. The elements needed to identify an object that is the subject of a transfer request are object-specific, so the child elements of the query command are specified using the EPP extension framework. In addition to the standard EPP command elements, the command SHALL contain an "op" attribute with value "query", and the following child elements: - An object-specific element that identifies the object whose transfer status is requested. - An element that contains the data from the element identifying the most recent sponsorship association. Hollenbeck Expires May 10, 2001 [Page 19] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example query command: C: C: C: C: C: C: example C: C: C: 1999-06-08 C: ClientX C: ABC-98765-XYZ C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: When an query command has been processed successfully, a server MUST respond with an EPP element that MUST contain a child element that identifies the object namespace and the location of the object schema. The child elements of the element are object-specific, but each response MUST include the following information: - An object-specific element that identifies the type of object whose transfer status is requested. - An object-specific element that provides the name or other identifier used to uniquely identify the object. - An object-specific element that provides the identifier of the client that initiated the transfer request. - An object-specific element that provides the identifier of the client that SHOULD respond to the transfer request. - An object-specific element that contains the state of the most recent transfer request. Valid values are Hollenbeck Expires May 10, 2001 [Page 20] Internet-Draft Extensible Provisioning Protocol November 10, 2000 "PENDING", "APPROVED", "REJECTED", "AUTO-APPROVED", "AUTO-REJECTED", and "CANCELLED". - An object-specific element that contains the date and time that the transfer was requested. - An object-specific element that contains the date and time of a required or completed response. For a PENDING request, the value contains the date and time by which a response is required before an automated response action SHALL be taken by the server. For all other status types, the value contains the date and time when the request was completed. Example query response: S: S: S: S: S: Command completed successfully S: S: S: S: example S: ClientX S: ClientY S: PENDING S: 2000-06-06T22:00:00.0Z S: 2000-06-11T22:00:00.0Z S: S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Authorization: all clients MUST be authorized to use the query command. A client MUST be authorized to query an object for which they are either the requesting or the responding client. A client MUST NOT be authorized to query an object for which they are neither the requesting or the responding client. Hollenbeck Expires May 10, 2001 [Page 21] Internet-Draft Extensible Provisioning Protocol November 10, 2000 2.6.3 Object Transform Commands EPP provides five commands to transform objects: to create an instance of an object with a server, to remove an instance of an object from a server, to extend the validity period of an object, to change information associated with an object, and to manage changes in client sponsorship of a known object. 2.6.3.1 EPP Command The EPP command is used to create an instance of an object. An object may be created for an indefinite period of time, or an object may be created for a specific validity period. The EPP mapping for an object MUST describe the status of an object with respect to time, to include expected client and server behavior if a validity period is used. The elements needed to identify an object and associated attributes are object-specific, so the child elements of the command are specified using the EPP extension framework. In addition to the standard EPP command elements, the command SHALL contain the following child elements: - An object-specific element that identifies the object to be created and the elements that are required to create the object. Example command: C: C: C: C: C: C: example C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: The child elements of the element provided by the client Hollenbeck Expires May 10, 2001 [Page 22] Internet-Draft Extensible Provisioning Protocol November 10, 2000 are also used to authorize transfer commands. If the command was performed on behalf of a third party, the client executing the command MUST provide the transaction identifier information to the third party for use in future transfer requests. This identifying information MUST NOT be available to anyone except the client and the third party. Only the third party MAY disclose this information to another client to authorize a transfer request. When a command has been processed successfully, a server MUST respond with an EPP element that MUST contain a child element that identifies the object namespace and the location of the object schema. Example response: S: S: S: S: S: Command completed successfully S: S: S: S: example S: S: 2002-06-08T22:00:00.0Z S: S: S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Authorization: all clients MUST be authorized to use the command. 2.6.3.2 EPP Command The EPP command is used to remove an instance of a known object. The elements needed to identify an object are object- specific, so the child elements of the command are specified Hollenbeck Expires May 10, 2001 [Page 23] Internet-Draft Extensible Provisioning Protocol November 10, 2000 using the EPP extension framework. In addition to the standard EPP command elements, the command SHALL contain the following child elements: - An object-specific element that identifies the object to be deleted. Example command: C: C: C: C: C: C: example C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: When a command has been processed successfully, a server MUST respond with an EPP response with no element. If successful, the server will respond by returning a response code that confirms that the command has been accepted. Hollenbeck Expires May 10, 2001 [Page 24] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response: S: S: S: S: S: Command completed successfully S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Authorization: all clients MUST be authorized to use the command. An object MAY be deleted only by the current sponsoring client. 2.6.3.3 EPP Command The EPP command is used to extend the validity period of an object. The elements needed to identify and extend the validity period of an object are object-specific, so the child elements of the command are specified using the EPP extension framework. In addition to the standard EPP command elements, the command SHALL contain the following child elements: - An object-specific element that identifies the object to be renewed and the elements that are required to extend the validity period of the object. Hollenbeck Expires May 10, 2001 [Page 25] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example command: C: C: C: C: C: C: example C: C: 2000 C: C: 2 C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: When an command has been processed successfully, a server MUST respond with an EPP element that MUST contain a child element that identifies the object namespace and the location of the object schema. Object-specific response elements SHALL be returned as child elements of a element. Hollenbeck Expires May 10, 2001 [Page 26] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response: S: S: S: S: S: Command completed successfully S: S: S: S: example S: S: 2005-04-03T22:00:00.0Z S: S: S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Authorization: all clients MUST be authorized to use the command. An object MAY be renewed only by the current sponsoring client. Object renewal MAY be limited to time limitations that are server-specific. 2.6.3.4 EPP Command The EPP command is used to manage changes in client sponsorship of a known object. Clients may initiate a transfer request, cancel a transfer request, approve a transfer request, and reject a transfer request using the "op" command attribute. Every command MUST include an authorization identifier to confirm transfer authority. This identifier is a copy of the transaction identifier associated with the most recent command causing a change of sponsorship, such as the most recently successful command or the original command. The identifier associated with the original command MUST be used to authorize the first transfer of an object. After an object has been successfully transferred at least once, the identifier associated wit Hollenbeck Expires May 10, 2001 [Page 27] Internet-Draft Extensible Provisioning Protocol November 10, 2000 the most recent successful command MUST be used to authorize transfer of an object. Clients performing a command on behalf of a third party MUST provide the third party with a copy of the transaction identifier used to request the transfer. Authorization identifier information MUST NOT be disclosed to any other client or third party. A client who wishes to transfer an object on behalf of a third party MUST receive authorization identifier information from the third party before a command can be successful. A client who wishes to assume sponsorship of a known object from another client uses the command with the value of the "op" attribute set to "request". Once a transfer has been requested, the same client may cancel the request using a command with the value of the "op" attribute set to "cancel". A request to cancel the transfer MUST be sent to the server before the current sponsoring client either approves or rejects the transfer request and before the server automatically processes the request due to responding client inactivity. Once a transfer request has been received by the server, the server MUST notify the current sponsoring client of the requested transfer. This notification MUST be done using an out-of-band communication mechanism such as offline reports and/or electronic mail. The current status of a pending command for any object MAY be found using the query command. The current sponsoring client MAY explicitly approve or reject the transfer request. The client may approve the request using a command with the value of the "op" attribute set to "approve". The client may reject the request using a command with the value of the "op" attribute set to "reject". A server MUST automatically approve or reject all transfer requests that are not explicitly approved or rejected by the current sponsoring client within a fixed amount of time. The amount of time to wait for explicit action and the default server behavior are local matters not specified by EPP, but they SHOULD be documented in a server-specific profile document that describes default server behavior for client information. EPP does not provide a mechanism to push notice of new transfer requests to clients. A server MUST provide out-of-band services to inform clients of a transfer for which a response is expected; electronic mail and/or offline reporting MAY be used to provide clients with transfer notices. Once a client is aware of a requested transfer, information about the request may be found using the Hollenbeck Expires May 10, 2001 [Page 28] Internet-Draft Extensible Provisioning Protocol November 10, 2000 query command. The elements needed to identify and complete the transfer of an object are object-specific, so the child elements of the command are specified using the EPP extension framework. In addition to the standard EPP command elements, the command SHALL contain the following child elements: - An object-specific element that identifies the object to be transferred and the elements that are required to process the transfer command. - An element that contains the data from the element identifying the most recent sponsorship association. Example request command: C: C: C: C: C: C: example C: C: C: 1999-06-08 C: ClientY C: ABC-98765-XYZ C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: When an command has been processed successfully, a server MUST respond with an EPP element that MUST contain a child element that identifies the object namespace and the location of the object schema. Object-specific response elements SHALL be returned as child elements of a element. Hollenbeck Expires May 10, 2001 [Page 29] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response: S: S: S: S: S: Command completed successfully S: S: S: S: example S: ClientX S: ClientY S: PENDING S: 2000-06-08T22:00:00.0Z S: 2000-06-13T22:00:00.0Z S: S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: Authorization: all clients MUST be authorized to use the command. All commands MUST be accompanied by the authorization identifier associated with the object. A request MUST only be accepted from a client other than the current sponsoring client. A approval request MUST only be accepted from the current sponsoring client. A cancellation request MUST be accepted ONLY from the original requesting client. 2.6.3.5 EPP Command The EPP command is used to change information associated with a known object. The elements needed to identify and modify an object are object-specific, so the child elements of the command are specified using the EPP extension framework. In addition to the standard EPP command elements, the command SHALL contain the following child elements: Hollenbeck Expires May 10, 2001 [Page 30] Internet-Draft Extensible Provisioning Protocol November 10, 2000 - An object-specific element that identifies the object to be renewed and the elements that are required to modify the object. Object-specific elements MUST identify values to be added, values to be removed, or values to be changed. Example command: C: C: C: C: C: C: example C: C: example C: C: C: example C: C: C: C: C: 2000-06-08 C: ClientX C: ABC-12345-XYZ C: C: C: When an command has been processed successfully, a server MUST respond with an EPP response with no element. If successful, the server will respond by returning a result code that confirms that the command has been accepted. Hollenbeck Expires May 10, 2001 [Page 31] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Example response: S: S: S: S: S: Command completed successfully S: S: S: 2000-06-08 S: ClientX S: ABC-12345-XYZ S: S: S: S: Authorization: all clients MUST be authorized to use the command. An object MAY be updated only by the current sponsoring client. Hollenbeck Expires May 10, 2001 [Page 32] Internet-Draft Extensible Provisioning Protocol November 10, 2000 3. Result Codes EPP result codes are based on the Theory of Reply Codes described in Appendix E of [RFC821]. EPP uses four decimal digits to describe the success or failure of each EPP command. The four digits of the reply each have special significance. The first digit denotes whether the response marks command success or failure. A client that wants to know approximately what kind of error occurred (command syntax error, security error, system error, etc.) may examine the second digit. The third and fourth digits are used to provide explicit information detail. There are two values for the first digit of the reply code: 1yzz Positive completion reply. The command has been accepted and processed by the system without error. 2yzz Negative completion reply. The command was not accepted and the requested action did not occur. The second digit groups responses into specific categories: x0zz Protocol Syntax x1zz Implementation-specific Rules x2zz Security x3zz Data Management X4zz Server System x5zz Connection Management The third and fourth digits provide response detail within the categories defined by the first and second digits. Every EPP response MUST include a result code and a human-readable description of the result code. The language used to represent the description MAY be identified using an instance of the "lang" attribute within the element. If not specified, the default language is US English, identified as "en-US". A description of the structure of valid values for the "lang" attribute is described in [RFC1766]. A list of valid values for the "lang" attribute is available in [ISO639]. Hollenbeck Expires May 10, 2001 [Page 33] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Successful command completion responses: Code Response text in US English ___________________________________ 1000 Command completed successfully 1500 Command completed successfully; ending session Command error responses: Code Response text in US English ___________________________________ 2000 Unknown command 2001 Invalid command sequence 2002 Invalid command structure 2003 Unknown parameter 2004 Required parameter missing 2005 Parameter value range error 2006 Parameter value syntax error 2100 Billing failure 2102 Object is not eligible for renewal 2103 Object is not eligible for transfer 2200 Authentication failure 2201 Authorization failure 2202 Invalid authorization identifier 2203 Object authorization failure 2300 Object pending transfer 2301 Object not pending transfer 2302 Object not unique 2303 Object not known 2304 Parent object not known 2305 Object status prohibits operation 2306 Parent object status prohibits operation 2307 Invalid parameter value 2308 Duplicate transaction identifier 2400 Command failed 2500 Command failed; server ending session 2501 Timeout; server ending session 2502 Connection limit exceeded; server ending session Hollenbeck Expires May 10, 2001 [Page 34] Internet-Draft Extensible Provisioning Protocol November 10, 2000 4. Formal Syntax EPP is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of EPP suitable for automated validation of EPP XML instances. Extensible Provisioning Protocol version 1.0 schema. Hollenbeck Expires May 10, 2001 [Page 35] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Hollenbeck Expires May 10, 2001 [Page 36] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Hollenbeck Expires May 10, 2001 [Page 37] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Hollenbeck Expires May 10, 2001 [Page 38] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Hollenbeck Expires May 10, 2001 [Page 39] Internet-Draft Extensible Provisioning Protocol November 10, 2000 5. Internationalization Considerations EPP is represented in XML, which provides native support for encoding information using the double-byte Unicode character set and its more compact representations including UTF-8. Compliant XML processors are required to understand both UTF-8 and raw Unicode character sets; XML also includes a provision for identifying other character sets through use of an "encoding" attribute in an processing instruction. The complete list of character set encoding identifiers is maintained by IANA and is described in [CHARSET] and [RFC1700]. EPP includes a provision for returning a human-readable message with every result code. This document describes result codes in US English, but the actual text returned with a result MAY be provided in a language negotiated when a session is established. Languages other than US English MUST be noted through specification of a "lang" attribute for text-based elements. Valid values for the "lang" attribute and "lang" negotiation elements are described in [RFC1766]. All date-time values presented via EPP MUST be expressed in Universal Coordinated Time. The XML Schema "date" format allows use of time zone identifiers to indicate offsets from the zero meridian, but this option MUST NOT be used within EPP. Both extended and truncated date and time forms defined in [ISO8601] MAY be used. Hollenbeck Expires May 10, 2001 [Page 40] Internet-Draft Extensible Provisioning Protocol November 10, 2000 6. IANA Considerations XML schemas require a URI for unique identification. Schemas MUST be registered to ensure URI uniqueness, but the IETF does not currently have a recommended repository for the registration of XML schemas. This document uses URNs to describe XML namespaces and XML schemas. IANA SHOULD maintain a registry of XML namespace and schema URI assignments. Per policies described in [IANA], URI assignment requests SHOULD be reviewed by a designated expert, and values SHOULD be assigned only as a result of standards action taken by the IESG. Hollenbeck Expires May 10, 2001 [Page 41] Internet-Draft Extensible Provisioning Protocol November 10, 2000 7. Security Considerations EPP provides only simple client authentication services. A passive attack is sufficient to recover client identifiers and passwords, allowing trivial command forgery. Protection against most common attacks must be provided by other protocols. EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595] to provide a simple application-layer authentication service. Where the PLAIN SASL mechanism specifies provision of an authorization identifier, authentication identifier, and password as a single string separated by ASCII NUL characters, EPP specifies use of a combined authorization and authentication identifier and a password provided as distinct XML elements. Repeated password guessing attempts can be discouraged by limiting the number of attempts that can be attempted on an open connection. A server MUST close an open connection if three attempts are made with either an invalid client identifier, an invalid password, or both an invalid client identifier and an invalid password. EPP uses transaction identifier information to authorize transfer commands. When an object is created or transferred on behalf of a third party, the identifier associated with the EPP or command MUST be provided to the third party using a facility that provides privacy services. Hollenbeck Expires May 10, 2001 [Page 42] Internet-Draft Extensible Provisioning Protocol November 10, 2000 8. References [CHARSET] ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets [GRRP] S. Hollenbeck: "Generic Registry-Registrar Protocol Requirements", draft-hollenbeck-grrp-05.txt, work in progress. [IANA] T. Narten, H. Alvestrand: "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [ISO639] ISO 639:1988 (E/F): "Code for the representation of names of languages - The International Organization for Standardization". [ISO8601] ISO 8601:1988 (E): "Data elements and interchange formats - Information interchange - Representation of dates and times - The International Organization for Standardization". [RFC821] J. Postel: "Simple Mail Transfer Protocol", RFC 821, August 1982. [RFC1700] J. Reynolds, J. Postel: "Assigned Numbers", STD 2, RFC 1700, October 1994. [RFC1766] H. Alvestrand: "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2595] C. Newman: "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0", http://www.w3.org/TR/REC-xml, W3C Recommendation February 1998 [XML-SD] Editors P. Biron and A. Malhotra: "XML Schema Part 2: Datatypes", http://www.w3.org/TR/xmlschema-2/, W3C Working Draft April 2000 [XML-SS] Editor H. Thompson et al.: "XML Schema Part 1: Structures", http://www.w3.org/TR/xmlschema-1/, W3C Working Draft April 2000 Hollenbeck Expires May 10, 2001 [Page 43] Internet-Draft Extensible Provisioning Protocol November 10, 2000 9. Author's Address Scott Hollenbeck VeriSign Global Registry Services 21345 Ridgetop Circle Dulles, VA 20166-6503 USA shollenbeck@verisign.com Hollenbeck Expires May 10, 2001 [Page 44] Internet-Draft Extensible Provisioning Protocol November 10, 2000 10. Full Copyright Statement Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hollenbeck Expires May 10, 2001 [Page 45] Internet-Draft Extensible Provisioning Protocol November 10, 2000 Appendix A: Object Mapping Outline This appendix describes a recommended outline for documenting the EPP mapping of an object. Documents that describe EPP object mappings SHOULD describe the mapping in a format similar to the one used here. Note that additional sections will be required if the object mapping is written in Internet-Draft format. 1. Introduction Provide an introduction that describes the object and an overview of the mapping to EPP. 2. Object Attributes Describe the attributes associated with the object, including references to syntax specifications as appropriate. Examples of object attributes include a name or identifier and dates associated with modification events. 3. EPP Command Mapping 3.1 EPP Query Commands 3.1.1 EPP Command Describe the object-specific mappings required to implement the EPP command. Include both sample commands and sample responses. 3.1.2 EPP Command Describe the object-specific mappings required to implement the EPP command. Include both sample commands and sample responses. 3.1.3 EPP Command Describe the object-specific mappings required to implement the EPP query command. Include both sample commands and sample responses. 3.2 EPP Transform Commands 3.2.1 EPP Command Describe the object-specific mappings required to implement the EPP command. Include both sample commands and sample responses. Describe the status of the object with respect to time, including expected client and server behavior if a validity period is used. Hollenbeck Expires May 10, 2001 [Page 46] Internet-Draft Extensible Provisioning Protocol November 10, 2000 3.2.2 EPP Command Describe the object-specific mappings required to implement the EPP command. Include both sample commands and sample responses. 3.2.3 EPP Command Describe the object-specific mappings required to implement the EPP command. Include both sample commands and sample responses. 3.2.4 EPP Command Describe the object-specific mappings required to implement the EPP command. Include both sample commands and sample responses. 3.2.5 EPP Command Describe the object-specific mappings required to implement the EPP command. Include both sample commands and sample responses. 4. Formal Syntax Provide the XML schema for the object mapping. An XML DTD MUST NOT be used as DTDs do not provide sufficient support for XML namespaces and strong data typing. Hollenbeck Expires May 10, 2001 [Page 47]