<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5730 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5730.xml">
<!ENTITY RFC5731 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5731.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc private="VeriSign Inc. Proprietary Information" ?>
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes"?>
<!-- keep one blank line between list items -->
<?rfc comments="yes" ?>
<!-- show cref output -->
<?rfc inline="yes" ?>
<!-- inline cref output -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="verisign_epp-extension_namestoreext_v01" ipr="none">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="namestoreext">Namestore Extension Mapping for the Extensible Provisioning Protocol (EPP)</title>

    <author fullname="James Gould" initials="J.G" surname="Gould">
      <organization>VeriSign, Inc.</organization>

      <address>
        <postal>
          <street>12061 Bluemont Way</street>

          <city>Reston</city>

          <region>VA</region>

          <code>20190</code>

          <country>US</country>
        </postal>

        <email>jgould@verisign.com</email>

        <uri>http://www.verisigninc.com</uri>
      </address>
    </author>


    <date day="10" month="December" year="2013"/>

    <abstract>
      <t>This document describes an Extensible Provisioning Protocol (EPP)
      extension mapping for routing commands to a logical registry using 
      a sub-product identifier.</t>
    </abstract>
    
    <note title="Legal Disclaimer">
      <t>COPYRIGHT NOTIFICATION</t>
      <t>Copyright 2013 VeriSign, Inc. All rights reserved. VERISIGN; 
      the Verisign logo; and other trademarks, service marks and Verisign designs are registered or 
      unregistered trademarks of VeriSign Inc. and its subsidiaries in the United States and foreign countries. 
      Copyright laws and international treaties protect this document, and any Verisign product to which it relates.</t>
      
      <t>VERISIGN PROPRIETARY INFORMATION</t>
      <t>This document is the property of VeriSign, Inc. and its subsidiaries (together "Verisign") It may be used by 
      recipient only for the purpose for which it was transmitted and must be returned upon request or when no longer 
      needed by recipient. It may not be copied or communicated without the prior written consent of Verisign.</t>

      <t>NOTICE AND CAUTION</t>
      <t>Concerning U.S. Patent or Trademark Rights</t>
      <t>Verisign and other trademarks, service marks and logos are registered or unregistered trademarks of 
      Verisign and its subsidiaries in the United States and in foreign countries. The inclusion in this 
      document, the associated on-line file or the associated software of any information covered by any 
      other patent, trademark or service mark rights does not constitute nor imply a grant of or authority 
      to exercise, any right or privilege protected by such patent, trademark or service mark. All such 
      rights and privileges are vested in the patent, trademark or service mark owner and no other person 
      may exercise such rights without express permission, authority or license secured from the patent, 
      trademark or service mark owner.</t>    
    </note>
    
  </front>

  <middle>
    <section title="Introduction">
      <t>This document describes an extension mapping for version 1.0 of the
      <xref target="RFC5730">Extensible Provisioning Protocol (EPP)</xref>.
      This EPP extension mapping enables a client to specify the logical 
      target registry of the EPP command using a <xref target="sub-product-identifier">sub-product identifier</xref>.  
      An EPP server can host multiple logical registries, where the client MUST route commands to the desired 
      target logical registry.</t>

      <section title="Conventions Used in This Document">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119">RFC 2119</xref>.</t>

        <t>XML is case sensitive. Unless stated otherwise, XML specifications
        and examples provided in this document MUST be interpreted in the
        character case presented in order to develop a conforming
        implementation.</t>
        
        <t>In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server.  
        Indentation and white space in examples are provided only to illustrate element relationships 
        and are not a REQUIRED feature of this protocol.        
        </t>

        <t>"namestoreExt-1.1" is used as an abbreviation for
        "http://www.verisign-grs.com/epp/namestoreExt-1.1". The XML namespace prefix "namestoreExt"
        is used, but implementations MUST NOT depend on it and instead employ
        a proper namespace-aware XML parser and serializer to interpret and
        output the XML documents.</t>
      </section>
    </section>

    <section anchor="attrs" title="Object Attributes">
    
      <t>This extension adds additional elements to the EPP object mappings, like the <xref
      target="RFC5731">EPP domain name mapping</xref>. The use of the <xref
      target="RFC5731">EPP domain name mapping</xref> throughout the document is used 
      strictly as an example since the Namestore Extension MAY be used with any 
      EPP object mapping.  Only those new elements
      are described here.</t>

      <section anchor="sub-product-identifier" title="Sub-Product Identifier">
        <t>The sub-product identifier is used to identify the target logical registry 
        that the EPP command is intended for.  The valid set of sub-product identifiers 
        is up to server policy.  The server MUST validate the sub-product identifier 
        and route the EPP command to the logical registry that matches the 
        sub-product identifier.</t>
      </section>
            
    </section>

    <section anchor="commands" title="EPP Command Mapping">
      <t>A detailed description of the EPP syntax and semantics can be found
      in the EPP core protocol specification <xref target="RFC5730"/>. The
      command mappings described here are specifically for use with the 
      Namestore Extension.</t>

      <section anchor="queryCommands" title="EPP Query Commands">
      
      	<t>EPP provides three commands to retrieve object information: &lt;check&gt; to determine 
      	if an object is known to the server, &lt;info&gt; to retrieve detailed information associated 
      	with an object, and &lt;transfer&gt; to retrieve object transfer status information.</t>
      	
      <section anchor="checkCommand" title="EPP &lt;check&gt; Command">
       <t>This extension defines additional elements to extend the EPP
        &lt;check&gt; command and response to be used in conjunction with the
        EPP object mappings, like the <xref target="RFC5731">EPP domain name mapping</xref>.</t>
        
       <t>The EPP &lt;check&gt; command is extended to include target logical registry.  
       In addition to the EPP command elements defined in the EPP object mappings, like 
       the <xref target="RFC5731">EPP domain name mapping</xref>, the command MUST contain 
       the &lt;extension&gt; element.  The &lt;extension&gt; element MUST contain 
       a child &lt;namestoreExt:namestoreExt&gt; element that contains the following 
       child elements:</t>
              
       <t><list hangIndent="4" style="hanging">
          <t hangText="&lt;namestoreExt:subProduct&gt;">element MUST contain a 
          sub-product identifier specifying the target logical registry.</t>
       </list></t>

       <figure>
            <preamble>Example &lt;check&gt; command with the 
            Namestore Extension:</preamble>

            <artwork><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <check>
C:      <domain:check
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>EXAMPLE1.TLD</domain:name>
C:        <domain:name>EXAMPLE2.TLD</domain:name>
C:        <domain:name>EXAMPLE3.TLD</domain:name>
C:      </domain:check>
C:    </check>
C:    <extension>
C:      <namestoreExt:namestoreExt
C:       xmlns:namestoreExt=
C:       "http://www.verisign-grs.com/epp/namestoreExt-1.1">
C:         <namestoreExt:subProduct>TLD</namestoreExt:subProduct>
C:      </namestoreExt:namestoreExt>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
       </figure>
       
       <t>When a &lt;check&gt; command has been successfully processed, 
       the response MUST contain the elements defined in the EPP object 
       mapping.  In addition, the EPP &lt;extension&gt; element MUST 
       contain a child &lt;namestoreExt:namestoreExt&gt; element that 
       contains the same &lt;namestoreExt:subProduct&gt; element that 
       was passed in the &lt;check&gt; command.</t>
          
       <figure>
            <preamble>Example &lt;check&gt; response with the 
            Namestore Extension:</preamble>

            <artwork><![CDATA[
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <domain:chkData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:cd>
S:          <domain:name avail="1">EXAMPLE1.TLD</domain:name>
S:        </domain:cd>
S:        <domain:cd>
S:          <domain:name avail="0">EXAMPLE2.TLD</domain:name>
S:          <domain:reason>In use</domain:reason>
S:        </domain:cd>
S:        <domain:cd>
S:          <domain:name avail="1">EXAMPLE3.TLD</domain:name>
S:        </domain:cd>
S:      </domain:chkData>
S:    </resData>
S:    <extension>
S:      <namestoreExt:namestoreExt
S:       xmlns:namestoreExt=
S:       "http://www.verisign-grs.com/epp/namestoreExt-1.1">
S:         <namestoreExt:subProduct>TLD</namestoreExt:subProduct>
S:      </namestoreExt:namestoreExt>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></artwork>
       </figure>
       
       <t>When a &lt;check&gt; command has failed, 
       the response MUST contain the elements defined in the EPP object 
       mapping.  In addition, if the command response code is 2306 
       "Parameter value policy error", the EPP &lt;extension&gt; element MAY 
       have a child &lt;nsExtErrData&gt; element that contains the 
       following child elements:</t>

       <t><list hangIndent="4" style="hanging">
          <t hangText="&lt;namestoreExt:msg&gt;">element MUST containing 
          a human-readable description of the error.  The error code of 
          the error MUST be identified with a "code" attribute.  
          The language of the error is identified via an OPTIONAL 
          "lang" attribute.  If not specified, the default 
          attribute value MUST be "en" (English).  The "code" value 
          of "1" with the error text "Invalid sub-product" indicates 
          that the server does not support the specified 
          sub-product identifier.</t>
       </list></t>

          
       <figure>
            <preamble>Example &lt;check&gt; error response with the 
            Namestore Extension:</preamble>

            <artwork><![CDATA[
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="2306">
S:      <msg>Parameter value policy error</msg>
S:    </result>
S:    <extension>
S:      <namestoreExt:nsExtErrData
S:        xmlns:namestoreExt=
S:        "http://www.verisign-grs.com/epp/namestoreExt-1.1">
S:        <namestoreExt:msg code="1">
S:          Invalid sub-product
S:        </namestoreExt:msg>
S:      </namestoreExt:dstErrData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></artwork>
       </figure>
       
       
      </section>

      <!-- end CHECK command -->

      <section anchor="infoCommand" title="EPP &lt;info&gt; Command">
      
       <t>This extension defines additional elements to extend the EPP
        &lt;info&gt; command and response in the same fashion as defined 
        for the <xref target="checkCommand">EPP &lt;check&gt; Command</xref>.  
       </t>

      </section>
      <!-- end INFO command -->

      <section anchor="transferQueryCommand" title="EPP &lt;transfer&gt; Command">
      
       <t>This extension defines additional elements to extend the EPP
        &lt;transfer&gt; command and response in the same fashion as defined 
        for the <xref target="checkCommand">EPP &lt;check&gt; Command</xref>.  
       </t>
       
      </section>
      <!-- end TRANSFER command -->

      </section>
      
      <section anchor="transformCommands" title="EPP Transform Commands">
      
      	<t>EPP provides five commands to transform objects: &lt;create&gt; to create an instance of an object, 
      	&lt;delete&gt; to delete an instance of an object, &lt;renew&gt; to extend the validity period of an object,
      	&lt;transfer&gt; to manage object sponsorship changes, and &lt;update&gt; to change information associated 
      	with an object.</t>
      	
      <section anchor="createCommand" title="EPP &lt;create&gt; Command">
      
       <t>This extension defines additional elements to extend the EPP
        &lt;create&gt; command and response in the same fashion as defined 
        for the <xref target="checkCommand">EPP &lt;check&gt; Command</xref>.  
       </t>
        
      </section>
      <!-- end CREATE command -->

      <section anchor="deleteCommand" title="EPP &lt;delete&gt; Command">
      
       <t>This extension defines additional elements to extend the EPP
        &lt;delete&gt; command and response in the same fashion as defined 
        for the <xref target="checkCommand">EPP &lt;check&gt; Command</xref>.  
       </t>
         
      </section>
      <!-- end DELETE command -->

      <section anchor="renewCommand" title="EPP &lt;renew&gt; Command">
      
       <t>This extension defines additional elements to extend the EPP
        &lt;renew&gt; command and response in the same fashion as defined 
        for the <xref target="checkCommand">EPP &lt;check&gt; Command</xref>.  
       </t>
       
      </section>
      <!-- end RENEW command -->

      <section anchor="transferCommand" title="EPP &lt;transfer&gt; Command">
      
       <t>This extension defines additional elements to extend the EPP
        &lt;transfer&gt; command and response in the same fashion as defined 
        for the <xref target="checkCommand">EPP &lt;check&gt; Command</xref>.  
       </t>
       
      </section>
      <!-- end TRANSFER command -->

      <section anchor="updateCommand" title="EPP &lt;update&gt; Command">
      
       <t>This extension defines additional elements to extend the EPP
        &lt;update&gt; command and response in the same fashion as defined 
        for the <xref target="checkCommand">EPP &lt;check&gt; Command</xref>.  
       </t>
        
      </section>
      <!-- end UPDATE command -->
      
     </section>
      
    </section>

    <!-- EPP command mapping -->

    <section anchor="syntax" title="Formal Syntax">
    
      <t>One schema is presented here that is the EPP Namestore Extension
      schema.</t>
      
      <t>The formal
      syntax presented here is a complete schema representation of the object
      mapping suitable for automated validation of EPP XML instances. 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.</t>

    <section title="Namestore Extension Schema">

      <figure>
        <artwork><![CDATA[
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace=
   "http://www.verisign-grs.com/epp/namestoreExt-1.1" 
   xmlns="http://www.w3.org/2001/XMLSchema" 
   xmlns:namestoreExt=
     "http://www.verisign-grs.com/epp/namestoreExt-1.1" 
   elementFormDefault="qualified">
  <annotation>
    <documentation>      
      Extensible Provisioning Protocol v1.0 Namestore 
      extension schema for destination registry routing.
     </documentation>
  </annotation>
  <!-- General Data types. -->
  <simpleType name="subProductType">
    <restriction base="token">
      <minLength value="1"/>
      <maxLength value="64"/>
    </restriction>
  </simpleType>
  <complexType name="extAnyType">
    <sequence>
      <any namespace="##other" maxOccurs="unbounded"/>
    </sequence>
  </complexType>
  <!-- Child elements found in EPP commands and responses. -->
  <element name="namestoreExt" 
    type="namestoreExt:namestoreExtType"/>
  <!-- Child elements of the <product> command. -->
  <complexType name="namestoreExtType">
    <sequence>
      <element name="subProduct" 
        type="namestoreExt:subProductType"/>
    </sequence>
  </complexType>
  <!-- Child response elements. -->
  <element name="nsExtErrData" 
    type="namestoreExt:nsExtErrDataType"/>

  <!-- <prdErrData> error response elements. -->
  <complexType name="nsExtErrDataType">
    <sequence>
      <element name="msg" type="namestoreExt:msgType"/>
    </sequence>
  </complexType>
  <!-- <prdErrData> <msg> element. -->
  <complexType name="msgType">
    <simpleContent>
      <extension base="normalizedString">
            <attribute name="code" 
              type="namestoreExt:prdErrCodeType" 
            use="required"/>
        <attribute name="lang" type="language" 
          default="en"/>
      </extension>
    </simpleContent>
  </complexType>
  <!-- <prdErrData> error response codes. -->
  <simpleType name="prdErrCodeType">
    <restriction base="unsignedShort">
      <enumeration value="1"/>
    </restriction>
  </simpleType>
<!-- End of schema. -->
</schema>
END]]></artwork>
      </figure>
      </section>
    </section>
   
   <section title="Change History">
    <section title="Version 01" anchor="version-01">
      <t><list style="numbers">
        <t>Initial version of Internet-Draft format of the 
        EPP Namestore Extension, version 1.2.</t>
      </list></t>
    </section>
   </section>
    

    <section anchor="Security" title="Security Considerations">
      <t>The mapping extensions described in this document do not provide any
      security services beyond those described by <xref
      target="RFC5730">EPP</xref> and protocol layers used by EPP. The security
      considerations described in these other specifications apply to this
      specification as well.</t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
       
      &RFC2119;

      &RFC5730;

      &RFC5731;

    </references>
  </back>

  <!-- vim: set ts=2 sw=2 expandtab: -->
</rfc>
