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

   Copyright (c) 2009 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

   o  Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
      names of specific contributors, may be used to endorse or promote
      products derived from this software without specific prior written
      permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

   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

   Copyright (c) 2009 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

   o  Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
      names of specific contributors, may be used to endorse or promote
      products derived from this software without specific prior written
      permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

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

   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.

   A MIME media type registration template is included in Appendix B.

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

   As described in Section 2, EPP includes features that allow for
   offline review of transform commands before the requested action is
   actually completed.  The server is required to notify the client when
   offline processing of the action has been completed.  Notifications
   can be sent using an out-of-band mechanism that is not protected by
   the mechanism used to provide EPP transport security.  Notifications
   sent without EPP's transport-security services should be protected
   using another mechanism that provides an appropriate level of
   protection for the notification.

8.  Acknowledgements

   RFC 3730 is a product of the PROVREG working group, which suggested
   improvements and provided many invaluable comments.  The author
   wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap
   Akkerhuis for their process and editorial contributions.  RFC 4930
   and this document are individual submissions, based on the work done
   in RFC 3730.

   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.

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

   [RFC4646]  Phillips, A. and M. Davis, "Tags for Identifying
              Languages", BCP 47, RFC 4646, September 2006.

   [W3C.REC-xml-20040204]
              Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J.,
              and T. Bray, "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]
              Maloney, M., Thompson, H., 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]
              Malhotra, A. and P. Biron, "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.

   [RFC2781]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
              10646", RFC 2781, February 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.

   [RFC4616]  Zeilenga, K., "The PLAIN Simple Authentication and
              Security Layer (SASL) Mechanism", RFC 4616, August 2006.

   [RFC4930]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              RFC 4930, May 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [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 gives 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 4930

   1.   Changed "This document obsoletes RFC 3730" to "This document
        obsoletes RFC 4930".

   2.   Replaced references to RFC 2595 with references to RFC 4616.

   3.   Replaced references to RFC 2821 with references to RFC 5321.

   4.   Replaced references to RFC 2960 with references to RFC 4960.

   5.   Replaced references to RFC 3066 with references to RFC 4646.

   6.   Replaced references to RFC 3730 with references to RFC 4930.

   7.   Added "A protocol client that is authorized to manage an
        existing object is described as a "sponsoring" client throughout
        this document" in Section 1.1.

   8.   Changed "This action MUST be open to all authorized clients" to
        "This command MUST be available to all clients" in the
        descriptions of the <login> and <logout> commands.

   9.   Changed "Specific result codes are listed in the table below" to
        "The complete list of valid result codes is enumerated below and
        in the normative schema" in Section 3.

   10.  Added new paragraph to Section 7 to give guidance on the need to
        protect offline transaction notices.

   11.  Added reference to Appendix B in the IANA Considerations
        section.

   12.  Added BSD license text to XML schema section.

Author's Address

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

   EMail: shollenbeck@verisign.com