Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3730

Extensible Provisioning Protocol (EPP)

Pages: 69
Obsoleted by:  4930
Part 3 of 3 – Pages 42 to 69
First   Prev   None

ToP   noToC   RFC3730 - Page 42   prevText

3. Result Codes

EPP result codes are based on the theory of reply codes described in section 4.2.1 of [RFC2821]. EPP uses four decimal digits to describe the success or failure of each EPP command. Each of the digits of the reply have special significance. The first digit denotes command success or failure. The second digit denotes the response category, such as command syntax or security. The third and fourth digits provide explicit response detail within each response category. 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.
ToP   noToC   RFC3730 - Page 43
   The second digit groups responses into one of six 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.  Specific result
   codes are listed in the table below.

   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 <msg> element.  If not specified, the default
   language is English, identified as "en".  A description of the
   structure of valid values for the "lang" attribute is described in
   [RFC3066].

   Response text MAY be translated into other languages, though the
   translation MUST preserve the meaning of the code as described here.
   Response code values MUST NOT be changed when translating text.

   Response text in the table below is enclosed in quotes to clearly
   mark the beginning and ending of each response string.  Quotes MUST
   NOT be used to delimit these strings when returning response text via
   the protocol.
ToP   noToC   RFC3730 - Page 44
   Successful command completion responses:

   Code    Response text in English
   ___________________________________

   1000    "Command completed successfully"
   This is the usual response code for a successfully completed command
   that is not addressed by any other 1xxx-series response code.

   1001    "Command completed successfully; action pending"
   This response code MUST be returned when responding to a command the
   requires offline activity before the requested action can be
   completed.  See section 2 for a description of other processing
   requirements.

   1300    "Command completed successfully; no messages"
   This response code MUST be returned when responding to a <poll>
   request command and the server message queue is empty.

   1301    "Command completed successfully; ack to dequeue"
   This response code MUST be returned when responding to a <poll>
   request command and a message has been retrieved from the server
   message queue.

   1500    "Command completed successfully; ending session"
   This response code MUST be returned when responding to a successful
   <logout> command.
ToP   noToC   RFC3730 - Page 45
   Command error responses:

   Code    Response text in English
   ___________________________________

   2000    "Unknown command"
   This response code MUST be returned when a server receives a command
   element that is not defined by EPP.

   2001    "Command syntax error"
   This response code MUST be returned when a server receives an
   improperly formed command element.

   2002    "Command use error"
   This response code MUST be returned when a server receives a properly
   formed command element, but the command can not be executed due to a
   sequencing or context error.  For example, a <logout> command can not
   be executed without having first completed a <login> command.

   2003    "Required parameter missing"
   This response code MUST be returned when a server receives a command
   for which a required parameter value has not been provided.

   2004    "Parameter value range error"
   This response code MUST be returned when a server receives a command
   parameter whose value is outside the range of values specified by the
   protocol.  The error value SHOULD be returned via a <value> element
   in the EPP response.

   2005    "Parameter value syntax error"
   This response code MUST be returned when a server receives a command
   containing a parameter whose value is improperly formed.  The error
   value SHOULD be returned via a <value> element in the EPP response.

   2100    "Unimplemented protocol version"
   This response code MUST be returned when a server receives a command
   element specifying a protocol version that is not implemented by the
   server.

   2101    "Unimplemented command"
   This response code MUST be returned when a server receives a valid
   EPP command element that is not implemented by the server.  For
   example, a <transfer> command can be unimplemented for certain object
   types.
ToP   noToC   RFC3730 - Page 46
   2102    "Unimplemented option"
   This response code MUST be returned when a server receives a valid
   EPP command element that contains a protocol option that is not
   implemented by the server.

   2103    "Unimplemented extension"
   This response code MUST be returned when a server receives a valid
   EPP command element that contains a protocol command extension that
   is not implemented by the server.

   2104    "Billing failure"
   This response code MUST be returned when a server attempts to execute
   a billable operation and the command can not be completed due to a
   client billing failure.

   2105    "Object is not eligible for renewal"
   This response code MUST be returned when a client attempts to <renew>
   an object that is not eligible for renewal in accordance with server
   policy.

   2106    "Object is not eligible for transfer"
   This response code MUST be returned when a client attempts to
   <transfer> an object that is not eligible for transfer in accordance
   with server policy.

   2200    "Authentication error"
   This response code MUST be returned when a server notes an error when
   validating client credentials.

   2201    "Authorization error"
   This response code MUST be returned when a server notes a client
   authorization error when executing a command.  This error is used to
   note that a client lacks privileges to execute the requested command.

   2202    "Invalid authorization information"
   This response code MUST be returned when a server receives invalid
   command authorization information required to confirm authorization
   to execute a command.  This error is used to note that a client has
   the privileges required to execute the requested command, but the
   authorization information provided by the client does not match the
   authorization information archived by the server.

   2300    "Object pending transfer"
   This response code MUST be returned when a server receives a command
   to transfer an object that is pending transfer due to an earlier
   transfer request.
ToP   noToC   RFC3730 - Page 47
   2301    "Object not pending transfer"
   This response code MUST be returned when a server receives a command
   to confirm, reject, or cancel the transfer an object when no command
   has been made to transfer the object.

   2302    "Object exists"
   This response code MUST be returned when a server receives a command
   to create an object that already exists in the repository.

   2303    "Object does not exist"
   This response code MUST be returned when a server receives a command
   to query or transform an object that does not exist in the
   repository.

   2304    "Object status prohibits operation"
   This response code MUST be returned when a server receives a command
   to transform an object that can not be completed due to server policy
   or business practices.  For example, a server can disallow <transfer>
   commands under terms and conditions that are matters of local policy,
   or the server might have received a <delete> command for an object
   whose status prohibits deletion.

   2305    "Object association prohibits operation"
   This response code MUST be returned when a server receives a command
   to transform an object that can not be completed due to dependencies
   on other objects that are associated with the target object.  For
   example, a server can disallow <delete> commands while an object has
   active associations with other objects.

   2306    "Parameter value policy error"
   This response code MUST be returned when a server receives a command
   containing a parameter value that is syntactically valid, but
   semantically invalid due to local policy.  For example, the server
   can support a subset of a range of valid protocol parameter values.
   The error value SHOULD be returned via a <value> element in the EPP
   response.

   2307    "Unimplemented object service"
   This response code MUST be returned when a server receives a command
   to operate on an object service that is not supported by the server.

   2308    "Data management policy violation"
   This response code MUST be returned when a server receives a command
   whose execution results in a violation of server data management
   policies.  For example, removing all attribute values or object
   associations from an object might be a violation of a server's data
   management policies.
ToP   noToC   RFC3730 - Page 48
   2400    "Command failed"
   This response code MUST be returned when a server is unable to
   execute a command due to an internal server error that is not related
   to the protocol.  The failure can be transient.  The server MUST keep
   any ongoing session active.

   2500    "Command failed; server closing connection"
   This response code MUST be returned when a server receives a command
   that can not be completed due to an internal server error that is not
   related to the protocol.  The failure is not transient, and will
   cause other commands to fail as well.  The server MUST end the active
   session and close the existing connection.

   2501    "Authentication error; server closing connection"
   This response code MUST be returned when a server notes an error when
   validating client credentials and a server-defined limit on the
   number of allowable failures has been exceeded.  The server MUST
   close the existing connection.

   2502    "Session limit exceeded; server closing connection"
   This response code MUST be returned when a server receives a <login>
   command, and the command can not be completed because the client has
   exceeded a system-defined limit on the number of sessions that the
   client can establish.  It might be possible to establish a session by
   ending existing unused sessions and closing inactive connections.

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. Two schemas are presented here. The first schema is the base EPP schema. The second schema defines elements and structures that can be used by both the base EPP schema and object mapping schemas. 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.
ToP   noToC   RFC3730 - Page 49

4.1. Base Schema

BEGIN <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="urn:ietf:params:xml:ns:epp-1.0" xmlns:epp="urn:ietf:params:xml:ns:epp-1.0" xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <!-- Import common element types. --> <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" schemaLocation="eppcom-1.0.xsd"/> <annotation> <documentation> Extensible Provisioning Protocol v1.0 schema. </documentation> </annotation> <!-- Every EPP XML instance must begin with this element. --> <element name="epp" type="epp:eppType"/> <!-- An EPP XML instance must contain a greeting, hello, command, response, or extension. --> <complexType name="eppType"> <choice> <element name="greeting" type="epp:greetingType"/> <element name="hello"/> <element name="command" type="epp:commandType"/> <element name="response" type="epp:responseType"/> <element name="extension" type="epp:extAnyType"/> </choice> </complexType> <!-- A greeting is sent by a server in response to a client connection or <hello>. --> <complexType name="greetingType"> <sequence>
ToP   noToC   RFC3730 - Page 50
           <element name="svID" type="epp:sIDType"/>
           <element name="svDate" type="dateTime"/>
           <element name="svcMenu" type="epp:svcMenuType"/>
           <element name="dcp" type="epp:dcpType"/>
         </sequence>
       </complexType>

     <!--
     Server IDs are strings with minimum and maximum length
     restrictions.
     -->
       <simpleType name="sIDType">
         <restriction base="normalizedString">
           <minLength value="3"/>
           <maxLength value="64"/>
         </restriction>
       </simpleType>

     <!--
     A server greeting identifies available object services.
     -->
       <complexType name="svcMenuType">
         <sequence>
           <element name="version" type="epp:versionType"
            maxOccurs="unbounded"/>
           <element name="lang" type="language"
            maxOccurs="unbounded"/>
           <element name="objURI" type="anyURI"
            maxOccurs="unbounded"/>
           <element name="svcExtension" type="epp:extURIType"
            minOccurs="0"/>
         </sequence>
       </complexType>

     <!--
     Data Collection Policy types.
     -->
       <complexType name="dcpType">
         <sequence>
           <element name="access" type="epp:dcpAccessType"/>
           <element name="statement" type="epp:dcpStatementType"
            maxOccurs="unbounded"/>
           <element name="expiry" type="epp:dcpExpiryType"
            minOccurs="0"/>
         </sequence>
       </complexType>

       <complexType name="dcpAccessType">
ToP   noToC   RFC3730 - Page 51
         <choice>
           <element name="all"/>
           <element name="none"/>
           <element name="null"/>
           <element name="other"/>
           <element name="personal"/>
           <element name="personalAndOther"/>
         </choice>
       </complexType>

       <complexType name="dcpStatementType">
         <sequence>
           <element name="purpose" type="epp:dcpPurposeType"/>
           <element name="recipient" type="epp:dcpRecipientType"/>
           <element name="retention" type="epp:dcpRetentionType"/>
         </sequence>
       </complexType>

       <complexType name="dcpPurposeType">
         <sequence>
           <element name="admin"
            minOccurs="0"/>
           <element name="contact"
            minOccurs="0"/>
           <element name="other"
            minOccurs="0"/>
           <element name="prov"
            minOccurs="0"/>
         </sequence>
       </complexType>

       <complexType name="dcpRecipientType">
         <sequence>
           <element name="other"
            minOccurs="0"/>
           <element name="ours" type="epp:dcpOursType"
            minOccurs="0" maxOccurs="unbounded"/>
           <element name="public"
            minOccurs="0"/>
           <element name="same"
            minOccurs="0"/>
           <element name="unrelated"
            minOccurs="0"/>
         </sequence>
       </complexType>

       <complexType name="dcpOursType">
         <sequence>
ToP   noToC   RFC3730 - Page 52
           <element name="recDesc" type="epp:dcpRecDescType"
            minOccurs="0"/>
         </sequence>
       </complexType>

       <simpleType name="dcpRecDescType">
         <restriction base="token">
           <minLength value="1"/>
           <maxLength value="255"/>
         </restriction>
       </simpleType>

       <complexType name="dcpRetentionType">
         <choice>
           <element name="business"/>
           <element name="indefinite"/>
           <element name="legal"/>
           <element name="none"/>
           <element name="stated"/>
         </choice>
       </complexType>

       <complexType name="dcpExpiryType">
         <choice>
           <element name="absolute" type="dateTime"/>
           <element name="relative" type="duration"/>
         </choice>
       </complexType>

     <!--
     Extension framework types.
     -->
       <complexType name="extAnyType">
         <sequence>
           <any namespace="##other"
            maxOccurs="unbounded"/>
         </sequence>
       </complexType>

       <complexType name="extURIType">
         <sequence>
           <element name="extURI" type="anyURI"
            maxOccurs="unbounded"/>
         </sequence>
       </complexType>

     <!--
   An EPP version number is a dotted pair of decimal numbers.
ToP   noToC   RFC3730 - Page 53
   -->
     <simpleType name="versionType">
       <restriction base="token">
         <pattern value="[1-9]+\.[0-9]+"/>
         <enumeration value="1.0"/>
       </restriction>
     </simpleType>

   <!--
   Command types.
   -->
     <complexType name="commandType">
       <sequence>
         <choice>
           <element name="check" type="epp:readWriteType"/>
           <element name="create" type="epp:readWriteType"/>
           <element name="delete" type="epp:readWriteType"/>
           <element name="info" type="epp:readWriteType"/>
           <element name="login" type="epp:loginType"/>
           <element name="logout"/>
           <element name="poll" type="epp:pollType"/>
           <element name="renew" type="epp:readWriteType"/>
           <element name="transfer" type="epp:transferType"/>
           <element name="update" type="epp:readWriteType"/>
         </choice>
         <element name="extension" type="epp:extAnyType"
          minOccurs="0"/>
         <element name="clTRID" type="epp:trIDStringType"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   The <login> command.
   -->
     <complexType name="loginType">
       <sequence>
         <element name="clID" type="eppcom:clIDType"/>
         <element name="pw" type="epp:pwType"/>
         <element name="newPW" type="epp:pwType"
          minOccurs="0"/>
         <element name="options" type="epp:credsOptionsType"/>
         <element name="svcs" type="epp:loginSvcType"/>
       </sequence>
     </complexType>

     <complexType name="credsOptionsType">
       <sequence>
ToP   noToC   RFC3730 - Page 54
         <element name="version" type="epp:versionType"/>
         <element name="lang" type="language"/>
       </sequence>
     </complexType>

     <simpleType name="pwType">
       <restriction base="token">
         <minLength value="6"/>
         <maxLength value="16"/>
       </restriction>
     </simpleType>

     <complexType name="loginSvcType">
       <sequence>
         <element name="objURI" type="anyURI"
          maxOccurs="unbounded"/>
         <element name="svcExtension" type="epp:extURIType"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   The <poll> command.
   -->
     <complexType name="pollType">
       <attribute name="op" type="epp:pollOpType"
        use="required"/>
       <attribute name="msgID" type="token"/>
     </complexType>

     <simpleType name="pollOpType">
       <restriction base="token">
         <enumeration value="ack"/>
         <enumeration value="req"/>
       </restriction>
     </simpleType>
   <!--
   The <transfer> command.  This is object-specific, and uses attributes
   to identify the requested operation.
   -->
     <complexType name="transferType">
       <sequence>
         <any namespace="##other"/>
       </sequence>
       <attribute name="op" type="epp:transferOpType"
        use="required"/>
     </complexType>
ToP   noToC   RFC3730 - Page 55
     <simpleType name="transferOpType">
       <restriction base="token">
         <enumeration value="approve"/>
         <enumeration value="cancel"/>
         <enumeration value="query"/>
         <enumeration value="reject"/>
         <enumeration value="request"/>
       </restriction>
     </simpleType>

   <!--
   All other object-centric commands. EPP doesn't specify the syntax or
   semantics of object-centric command elements.  The elements MUST be
   described in detail in another schema specific to the object.
   -->
     <complexType name="readWriteType">
       <sequence>
         <any namespace="##other"/>
       </sequence>
     </complexType>

     <complexType name="trIDType">
       <sequence>
         <element name="clTRID" type="epp:trIDStringType"
          minOccurs="0"/>
         <element name="svTRID" type="epp:trIDStringType"/>
       </sequence>
     </complexType>

     <simpleType name="trIDStringType">
       <restriction base="token">
         <minLength value="3"/>
         <maxLength value="64"/>
       </restriction>
     </simpleType>
   <!--
   Response types.
   -->
     <complexType name="responseType">
       <sequence>
         <element name="result" type="epp:resultType"
          maxOccurs="unbounded"/>
         <element name="msgQ" type="epp:msgQType"
          minOccurs="0"/>
         <element name="resData" type="epp:extAnyType"
          minOccurs="0"/>
         <element name="extension" type="epp:extAnyType"
          minOccurs="0"/>
ToP   noToC   RFC3730 - Page 56
         <element name="trID" type="epp:trIDType"/>
       </sequence>
     </complexType>

     <complexType name="resultType">
       <sequence>
         <element name="msg" type="epp:msgType"/>
         <choice minOccurs="0" maxOccurs="unbounded">
           <element name="value" type="epp:errValueType"/>
           <element name="extValue" type="epp:extErrValueType"/>
         </choice>
       </sequence>
       <attribute name="code" type="epp:resultCodeType"
        use="required"/>
     </complexType>

     <complexType name="errValueType" mixed="true">
       <sequence>
         <any namespace="##any" processContents="skip"/>
       </sequence>
       <anyAttribute namespace="##any" processContents="skip"/>
     </complexType>

     <complexType name="extErrValueType">
       <sequence>
         <element name="value" type="epp:errValueType"/>
         <element name="reason" type="epp:msgType"/>
       </sequence>
     </complexType>

     <complexType name="msgQType">
       <sequence>
         <element name="qDate" type="dateTime"
          minOccurs="0"/>
         <element name="msg" type="epp:mixedMsgType"
          minOccurs="0"/>
       </sequence>
       <attribute name="count" type="unsignedLong"
        use="required"/>
       <attribute name="id" type="eppcom:minTokenType"
        use="required"/>
     </complexType>

     <complexType name="mixedMsgType" mixed="true">
       <sequence>
         <any processContents="skip"
          minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
ToP   noToC   RFC3730 - Page 57
       <attribute name="lang" type="language"
        default="en"/>
     </complexType>

   <!--
   Human-readable text may be expressed in languages other than English.
   -->
     <complexType name="msgType">
       <simpleContent>
         <extension base="normalizedString">
           <attribute name="lang" type="language"
            default="en"/>
         </extension>
       </simpleContent>
     </complexType>

   <!--
   EPP result codes.
   -->
     <simpleType name="resultCodeType">
       <restriction base="unsignedShort">
         <enumeration value="1000"/>
         <enumeration value="1001"/>
         <enumeration value="1300"/>
         <enumeration value="1301"/>
         <enumeration value="1500"/>
         <enumeration value="2000"/>
         <enumeration value="2001"/>
         <enumeration value="2002"/>
         <enumeration value="2003"/>
         <enumeration value="2004"/>
         <enumeration value="2005"/>
         <enumeration value="2100"/>
         <enumeration value="2101"/>
         <enumeration value="2102"/>
         <enumeration value="2103"/>
         <enumeration value="2104"/>
         <enumeration value="2105"/>
         <enumeration value="2106"/>
         <enumeration value="2200"/>
         <enumeration value="2201"/>
         <enumeration value="2202"/>
         <enumeration value="2300"/>
         <enumeration value="2301"/>
         <enumeration value="2302"/>
         <enumeration value="2303"/>
         <enumeration value="2304"/>
         <enumeration value="2305"/>
ToP   noToC   RFC3730 - Page 58
         <enumeration value="2306"/>
         <enumeration value="2307"/>
         <enumeration value="2308"/>
         <enumeration value="2400"/>
         <enumeration value="2500"/>
         <enumeration value="2501"/>
         <enumeration value="2502"/>
       </restriction>
     </simpleType>

   <!--
   End of schema.
   -->
   </schema>
   END

4.2. Shared Structure Schema

BEGIN <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="urn:ietf:params:xml:ns:eppcom-1.0" xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <annotation> <documentation> Extensible Provisioning Protocol v1.0 shared structures schema. </documentation> </annotation> <!-- Object authorization information types. --> <complexType name="pwAuthInfoType"> <simpleContent> <extension base="normalizedString"> <attribute name="roid" type="eppcom:roidType"/> </extension> </simpleContent> </complexType> <complexType name="extAuthInfoType"> <sequence> <any namespace="##other"/> </sequence>
ToP   noToC   RFC3730 - Page 59
     </complexType>

   <!--
   <check> response types.
   -->
     <complexType name="reasonType">
       <simpleContent>
         <extension base="eppcom:reasonBaseType">
           <attribute name="lang" type="language"/>
         </extension>
       </simpleContent>
     </complexType>

     <simpleType name="reasonBaseType">
       <restriction base="token">
         <minLength value="1"/>
         <maxLength value="32"/>
       </restriction>
     </simpleType>

   <!--
   Abstract client and object identifier type.
   -->
     <simpleType name="clIDType">
       <restriction base="token">
         <minLength value="3"/>
         <maxLength value="16"/>
       </restriction>
     </simpleType>

   <!--
   DNS label type.
   -->
     <simpleType name="labelType">
       <restriction base="token">
         <minLength value="1"/>
         <maxLength value="255"/>
       </restriction>
     </simpleType>

   <!--
   Non-empty token type.
   -->
     <simpleType name="minTokenType">
       <restriction base="token">
         <minLength value="1"/>
       </restriction>
     </simpleType>
ToP   noToC   RFC3730 - Page 60
   <!--
   Repository Object IDentifier type.
   -->
     <simpleType name="roidType">
       <restriction base="token">
         <pattern value="(\w|_){1,80}-\w{1,8}"/>
       </restriction>
     </simpleType>

   <!--
   Transfer status identifiers.
   -->
     <simpleType name="trStatusType">
       <restriction base="token">
         <enumeration value="clientApproved"/>
         <enumeration value="clientCancelled"/>
         <enumeration value="clientRejected"/>
         <enumeration value="pending"/>
         <enumeration value="serverApproved"/>
         <enumeration value="serverCancelled"/>
       </restriction>
     </simpleType>

   <!--
   End of schema.
   -->
   </schema>
   END

5. Internationalization Considerations

EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists. EPP includes a provision for returning a human-readable message with every result code. This document describes result codes in English, but the actual text returned with a result MAY be provided in a language negotiated when a session is established. Languages other than English MUST be noted through specification of a "lang" attribute for each message. Valid values for the "lang" attribute and "lang" negotiation elements are described in [RFC3066].
ToP   noToC   RFC3730 - Page 61
   All date-time values presented via EPP MUST be expressed in Universal
   Coordinated Time using the Gregorian calendar.  XML Schema allows use
   of time zone identifiers to indicate offsets from the zero meridian,
   but this option MUST NOT be used with EPP.  The extended date-time
   form using upper case "T" and "Z" characters defined in [RFC3339]
   MUST be used to represent date-time values as XML Schema does not
   support truncated date-time forms or lower case "T" and "Z"
   characters.

6. IANA Considerations

This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Four URI assignments have been registered by the IANA. Registration request for the EPP namespace: URI: urn:ietf:params:xml:ns:epp-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: None. Namespace URIs do not represent an XML specification. Registration request for the EPP XML schema: URI: urn:ietf:params:xml:schema:epp-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: See the "Base Schema" section of this document. Registration request for the EPP shared structure namespace: URI: urn:ietf:params:xml:ns:eppcom-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: None. Namespace URIs do not represent an XML specification. Registration request for the EPP shared structure XML schema: URI: urn:ietf:params:xml:schema:eppcom-1.0
ToP   noToC   RFC3730 - Page 62
   Registrant Contact: See the "Author's Address" section of this
   document.

      XML: See the "Shared Structure Schema" section of this document.

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 and more robust security services MUST be provided by other protocol layers. Specifically, EPP instances MUST be protected using a transport mechanism or application protocol that provides integrity and confidentiality. EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595] to provide a simple application-layer authentication service that augments or supplements authentication and identification services that might be available at other protocol layers. 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 <login> attempts that can be attempted on an open connection. A server MAY close an open connection if multiple <login> attempts are made with either an invalid client identifier, an invalid password, or both an invalid client identifier and an invalid password. EPP uses authentication information associated with objects to confirm object transfer authority. Authentication information exchanged between EPP clients and third party entities MUST be exchanged using a facility that provides privacy and integrity services to protect against unintended disclosure and modification while in transit.

8. Acknowledgements

This document was originally written as an individual submission Internet-Draft. The provreg working group later adopted it as a working group document and provided many invaluable comments and suggested improvements. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions.
ToP   noToC   RFC3730 - Page 63
   Specific suggestions that have been incorporated into this document
   were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan,
   Roger Castillo Cortazar, Dave Crocker, Ayesha Damaraju, Sheer El-
   Showk, Patrik Faltstrom, James Gould, John Immordino, Dan Kohn, Hong
   Liu, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek,
   Andrew Newton, Budi Rahardjo, Asbjorn Steira, Rick Wesson, and Jay
   Westerdal.

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation 6 October 2000. [XMLE] "XML 1.0 Second Edition Specification Errata", E22, 25 July 2001, http://www.w3.org/XML/xml-V10-2e-errata#E22.
ToP   noToC   RFC3730 - Page 64
   [XMLS-1]   Editors H. Thompson et al.: "XML Schema Part 1:
              Structures", W3C Recommendation 2 May 2001.

   [XMLS-2]   Editors P. Biron, A. Malhotra: "XML Schema Part 2:
              Datatypes", W3C Recommendation 2 May 2001.

9.2. Informative References

[P3P] Editor M. Marchiori: "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", W3C Recommendation 16 April 2002. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
ToP   noToC   RFC3730 - Page 65

Appendix A: Object Mapping Template

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. Additional sections are required if the object mapping is written in Internet-Draft or RFC 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 <check> Command Describe the object-specific mappings required to implement the EPP <check> command. Include both sample commands and sample responses. 3.1.2. EPP <info> Command Describe the object-specific mappings required to implement the EPP <info> command. Include both sample commands and sample responses. 3.1.3. EPP <poll> Command Describe the object-specific mappings required to implement the EPP <poll> command. Include both sample commands and sample responses. 3.1.4. EPP <transfer> Command Describe the object-specific mappings required to implement the EPP <transfer> query command. Include both sample commands and sample responses.
ToP   noToC   RFC3730 - Page 66
3.2.  EPP Transform Commands

3.2.1.  EPP <create> Command

   Describe the object-specific mappings required to implement the EPP
   <create> 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.

3.2.2.  EPP <delete> Command

   Describe the object-specific mappings required to implement the EPP
   <delete> command.  Include both sample commands and sample responses.

3.2.3.  EPP <renew> Command

   Describe the object-specific mappings required to implement the EPP
   <renew> command.  Include both sample commands and sample responses.

3.2.4.  EPP <transfer> Command

   Describe the object-specific mappings required to implement the EPP
   <transfer> command.  Include both sample commands and sample
   responses.

3.2.5.  EPP <update> Command

   Describe the object-specific mappings required to implement the EPP
   <update> 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.
ToP   noToC   RFC3730 - Page 67

Appendix B: Media Type Registration: application/epp+xml

MIME media type name: application MIME subtype name: epp+xml Mandatory parameters: none Optional parameters: Same as the charset parameter of application/xml as specified in [RFC3023]. Encoding considerations: Same as the encoding considerations of application/xml as specified in [RFC3023]. Security considerations: This type has all of the security considerations described in [RFC3023] plus the considerations specified in the Security Considerations section of this document. Interoperability considerations: XML has proven to be interoperable across WebDAV clients and servers, and for import and export from multiple XML authoring tools. For maximum interoperability, validating processors are recommended. Although non-validating processors can be more efficient, they are not required to handle all features of XML. For further information, see sub-section 2.9 "Standalone Document Declaration" and section 5 "Conformance" of [XML]. Published specification: This document. Applications which use this media type: EPP is device-, platform-, and vendor-neutral and is supported by multiple service providers. Additional information: If used, magic numbers, fragment identifiers, base URIs, and use of the BOM should be as specified in [RFC3023]. Magic number(s): None. File extension(s): .xml Macintosh File Type Code(s): "TEXT" Person and email address for further information: See the "Author's Address" section of this document. Intended usage: COMMON Author/Change controller: IETF
ToP   noToC   RFC3730 - Page 68
Author's Address

   Scott Hollenbeck
   VeriSign Global Registry Services
   21345 Ridgetop Circle
   Dulles, VA 20166-6503
   USA

   EMail: shollenbeck@verisign.com
ToP   noToC   RFC3730 - Page 69
Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.