tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3730

 
 
 

Extensible Provisioning Protocol (EPP)

Part 3 of 3, p. 42 to 69
Prev RFC Part

 


prevText      Top      Up      ToC       Page 42 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       Page 68 
Author's Address

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

   EMail: shollenbeck@verisign.com

Top      Up      ToC       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.