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.

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"/>

     <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>
         <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">
       <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>
         <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.
   -->
     <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>
         <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>

     <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"/>
         <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>
       <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"/>
         <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>
     </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>

   <!--
   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].

   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
   [W3C.REC-xmlschema-2-20041028] 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

   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, confidentiality, and mutual strong client-server
   authentication.

   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.

   EPP instances SHOULD be protected using a transport mechanism or
   application protocol that provides anti-replay protection.  EPP
   provides some protection against replay attacks through command
   idempotency and client-initiated transaction identification.
   Consecutive command replays will not change the state of an object in
   any way.  There is, however, a chance of unintended or malicious
   consequence if a command is replayed after intervening commands have
   changed the object state and client identifiers are not used to
   detect replays.  For example, a replayed <create> command that
   follows a <delete> command might succeed without additional
   facilities to prevent or detect the replay.

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.

   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.

   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, September 2000.

   [RFC3066]  Alvestrand, H., "Tags for the Identification of
              Languages", RFC 3066, January 2001.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [W3C.REC-xml-20040204]
              Yergeau, F., Maler, E., Sperberg-McQueen, C., Bray, T.,
              and J. Paoli, "Extensible Markup Language (XML) 1.0 (Third
              Edition)", World Wide Web Consortium FirstEdition REC-xml-
              20040204, February 2004,
              <http://www.w3.org/TR/2004/REC-xml-20040204>.

   [W3C.REC-xmlschema-1-20041028]
              Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech,
              "XML Schema Part 1: Structures Second Edition", World Wide
              Web Consortium Recommendation REC-xmlschema-1-20041028,
              October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

   [W3C.REC-xmlschema-2-20041028]
              Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
              Second Edition", World Wide Web Consortium
              Recommendation REC-xmlschema-2-20041028, October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

9.2.  Informative References

   [RFC0793]  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.

   [RFC2781]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
              10646", RFC 2781, February 2000.

   [RFC2821]  Klensin, J., "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.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3080]  Rose, M., "The Blocks Extensible Exchange Protocol Core",
              RFC 3080, March 2001.

   [RFC3375]  Hollenbeck, S., "Generic Registry-Registrar Protocol
              Requirements", RFC 3375, September 2002.

   [RFC3730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              RFC 3730, March 2004.

   [W3C.REC-P3P-20020416]
              Marchiori, M., "The Platform for Privacy Preferences 1.0
              (P3P1.0) Specification", World Wide Web Consortium
              Recommendation REC-P3P-20020416, April 2002,
              <http://www.w3.org/TR/2002/REC-P3P-20020416>.

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.

   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.4.  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.

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

   MIME media type name: application

   MIME subtype name: epp+xml

   Required 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 WWW Distributed Authoring and Versioning (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 Section 2.9, "Standalone Document Declaration", and Section 5,
   "Conformance", of [W3C.REC-xml-20040204].

   Published specification: This document.

   Applications that 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 & email address for further information: See the "Author's
   Address" section of this document.

   Intended usage: COMMON

   Author/Change controller: IETF

Appendix C.  Changes from RFC 3730

   1.   Minor reformatting as a result of converting I-D source format
        from nroff to XML.

   2.   Updated the state diagram in Section 2 to note that a <hello>
        can be received and processed at any time that a server is
        waiting for a command.  The text correctly describes how this
        works, but the state diagram was inconsistent with the text.

   3.   In Section 2, changed "The specific strings used to associate
        URIs and namespaces (such as the string "foo" in "xmlns:foo") in
        EPP are illustrative and are not needed for interoperability" to
        "The XML namespace prefixes used in examples (such as the string
        "foo" in "xmlns:foo") are solely for illustrative purposes.  A
        conforming implementation MUST NOT require the use of these or
        any other specific namespace prefixes".

   4.   Removed the last paragraph from Section 2 that described an
        error in the W3C XML reference specification.  This was
        corrected in a later edition.  References in this specification
        have been updated to cite the most current version.  Preserved
        the last sentence by appending it to the end of the previous
        paragraph.

   5.   Updated the description of the <value> element in Section 2.6 to
        add "or other information" to "a client-provided element
        (including XML tag and value)".

   6.   Changed text in Section 2.9.2.3 from this:

        "Service messages MUST be created for all clients affected by an
        action on an object.  For example, <transfer> actions MUST be
        reported to both the client that requests an object transfer and
        the client that has the authority to approve or reject the
        transfer request."

        to this:

        "Service messages SHOULD be created for passive clients affected
        by an action on an object.  Service messages MAY also be created
        for active clients that request an action on an object, though
        such messages MUST NOT replace the normal protocol response to
        the request.  For example, <transfer> actions SHOULD be reported
        to the client that has the authority to approve or reject a
        transfer request.  Other methods of server-client action
        notification, such as offline reporting, are also possible and
        are beyond the scope of this specification."

   7.   Changed text in Section 2.9.2.3 from this:

        "A <poll> acknowledgement response notes the number of messages
        remaining in the queue and the ID of the next message available
        for retrieval."

        to this:

        "A <poll> acknowledgement response notes the ID of the message
        that has been acknowledged and the number of messages remaining
        in the queue."

        Fixed the example to note the correct message ID.  This was done
        because the msgID isn't needed to retrieve a message, only to
        ack and dequeue it, so it doesn't need to be returned in the
        response.  Implementations are known to implement this feature
        as updated.

   8.   Changed text in Section 2.9.3.4 from this:

        "Once a transfer request has been received by the server, the
        server MUST notify the current sponsoring client of the
        requested transfer by queuing a service message for retrieval
        via the <poll> command."

        to this:

        "Once a transfer request has been received by the server, the
        server MUST notify the current sponsoring client of the
        requested transfer either by queuing a service message for
        retrieval via the <poll> command or by using an out-of-band
        mechanism to inform the client of the request."

   9.   Updated Security Considerations to note implemented required
        practices for authentication and replay protection.

   10.  Updated XML references.  Updated reference from RFC 2279 to RFC
        3629.

   11.  Removed text describing use of the XML Schema schemaLocation
        attribute.  This is an optional attribute that doesn't need to
        be mandated for use in EPP.

   12.  Moved RFCs 2781 and 3375 (Informational RFCs) from the normative
        reference section to the informative reference section.

   13.  Moved RFC 3023 from the normative reference section to the
        informative reference section.  This reference is used only in
        an informative appendix.

   14.  Removed references to RFC 3339 and replaced them with references
        to the W3C XML Schema specification.

Author's Address

   Scott Hollenbeck
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   US

   EMail: shollenbeck@verisign.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.