draft-ietf-eppext-launchphase.xml

<?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 RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.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 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="std" docName="draft-ietf-eppext-launchphase-00" ipr="trust200902">
  <!-- 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="Launch Phase Mapping for EPP">Launch Phase Mapping for the
    Extensible Provisioning Protocol (EPP)</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

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

    <author fullname="Wil Tan" initials="W.T." surname="Tan">
      <organization>Cloud Registry</organization>

      <address>
        <postal>
          <street>Suite 32 Seabridge House</street>

          <street>377 Kent St</street>

          <city>Sydney</city>

          <region>NSW</region>

          <code>2000</code>

          <country>AU</country>
        </postal>

        <phone>+61 414 710899</phone>

        <email>wil@cloudregistry.net</email>

        <uri>http://www.cloudregistry.net</uri>
      </address>
    </author>

    <author fullname="Gavin Brown" initials="G.B." surname="Brown">
      <organization>CentralNic Ltd</organization>

      <address>
        <postal>
          <street>35-39 Mooregate</street>

          <city>London</city>

          <region>England</region>

          <code>EC2R 6AR</code>

          <country>GB</country>
        </postal>

        <phone>+44 20 33 88 0600</phone>

        <email>gavin.brown@centralnic.com</email>

        <uri>https://www.centralnic.com</uri>
      </address>
    </author>

    <date day="17" month="January" year="2014"/>

    <!-- Meta-data Declarations -->

    <area>Applications</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>EPP, Sunrise, Landrush, Trademark Clearinghouse, Trademark
    Claims, domain name registry, launch phase</keyword>

    <abstract>
      <t>This document describes an Extensible Provisioning Protocol (EPP)
      extension mapping for the provisioning and management of domain name
      registrations and applications during the launch of a domain name registry.</t>
    </abstract>
  </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 mapping specifies a flexible schema that can be used to
      implement several common use cases related to the provisioning and
      management of domain name registrations and applications during the launch of a domain name registry.</t>

      <t>It is typical for domain registries to operate in special modes during
      their initial launch to facilitate allocation of domain names, often according
      to special rules. This document uses the term "launch phase" and the shorter form
      "launch" to refer to such a period.</t>

      <t>The <xref target="RFC5731">EPP domain name mapping</xref> is designed
      for the steady-state operation of a registry. During a launch period, the
      model in place may be different from what is defined in
      the <xref target="RFC5731">EPP domain name mapping</xref>. For example,
      registries often accept multiple applications for the same domain name during
      the "Sunrise" launch phase, referred to as a Launch Application.  A Launch
      Registration refers to a registration made during a launch phase when the
      server uses a "first-come, first-served" model.  Even in a "first-come,
      first-served" model, additional steps and information might be required, such as trademark information. In addition, the <eref
      target="http://tools.ietf.org/html/draft-ietf-eppext-tmch-smd">TMCH Functional Specification</eref> 
      defines a registry interface for the Trademark Claims or "claims" launch phase that
      includes support for presenting a Trademark Claims Notice to the
      Registrant. This document proposes an extension to the domain name
      mapping in order to provide a uniform interface for the management of Launch 
      Applications and Launch Registrations in launch phases.</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>"launch-1.0" is used as an abbreviation for
        "urn:ietf:params:xml:ns:launch-1.0". The XML namespace prefix "launch"
        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>
        <t>"signedMark-1.0" is used as an abbreviation for
        "urn:ietf:params:xml:ns:signedMark-1.0" that is defined in <xref target="draft-ietf-eppext-tmch-smd"/>. 
        The XML namespace prefix "smd"
        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>
        <t>"mark-1.0" is used as an abbreviation for
        "urn:ietf:params:xml:ns:mark-1.0" that is defined in <xref target="draft-ietf-eppext-tmch-smd"/>. 
        The XML namespace prefix "mark"
        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 <xref
      target="RFC5731">EPP domain name mapping</xref>. Only those new elements
      are described here.</t>

      <section anchor="applicationID" title="Application Identifier">
        <t>Servers MAY allow multiple applications, referred to as a Launch Application, 
        of the same domain name during its launch phase operations. Upon receiving 
        a valid request to create a Launch Application, the server MUST create an application
        object corresponding to the request, assign an application identifier
        for the Launch Application, set the <xref target="RFC5731"/> pendingCreate status, 
        and return the application identifier to the client with the
        &lt;launch:applicationID&gt; element. In order to facilitate
        correlation, all subsequent launch operations on the Launch Application
        MUST be qualified by the previously assigned application identifier
        using the &lt;launch:applicationID&gt; element.</t>
        <t>If the &lt;domain:create&gt;
        command processes a request synchronously without the use of an intermediate 
        Launch Application, then an application identifier MAY not be needed.</t>
      </section>
      
      <section anchor="validatorID" title="Validator Identifier">
        <t>The Validator Identifier is the unique identifier for a Trademark Validator that validates marks and has a repository of validated marks.  
        The OPTIONAL "validatorID" attribute is used to define the Validator Identifier of the Trademark Validator.  
        Registries MAY support more than one Third Party Trademark Validator.  The
        Internet Corporation for Assigned Names and Numbers (ICANN) Trademark Clearinghouse (TMCH) 
        is the default Trademark Validator and is reserved the Validator Identifier of "tmch".  If the ICANN TMCH 
        is not used or multiple Trademark Validators are used, the Validator Identifier MUST be 
        defined using the "validatorID" attribute.</t>
        <t>The Validator Identifier MAY be related to one or more issuer identifiers of the &lt;mark:id&gt; element 
        and the &lt;smd:id&gt; element defined in <xref target="draft-ietf-eppext-tmch-smd"/>.  Both the Validator Identifier and the 
        Issuer Identifier used MUST be unique.  The list of validator identifiers and the relationship to 
        issuer identifiers is out of scope for this document.</t>
      </section>
      
      <section anchor="phases" title="Launch Phases">
        <t>The server MAY support multiple launch phases sequentially or
        simultaneously. The &lt;launch:phase&gt; element MUST be included by
        the client to define the target launch phase of the command.  
        The server SHOULD validate the phase and MAY validate the sub-phase of the &lt;launch:phase&gt; element 
        against the active phase and OPTIONAL sub-phase of the server on a create command, 
        and return an EPP error result code of 2306 if there is a mismatch.</t>

        <t>The following launch phase values are defined: <list
            style="hanging">
            <t hangText="sunrise">The phase during which trademark holders can submit
            registrations or applications with trademark information that can be
            validated by the server.</t>

            <t hangText="landrush">A post-Sunrise phase when non-trademark
            holders are allowed to register domain names with steps taken 
            to address a large volume of initial registrations.</t>

            <t hangText="claims">The Trademark Claims phase, as defined in the  
            <eref
      target="http://tools.ietf.org/html/draft-lozano-tmch-func-spec">TMCH Functional Specification</eref>, in which a 
            Claims Notice must be displayed to a prospective registrant of a domain
            name that matches trademarks.</t>
            
            <t hangText="open">A post-launch phase that is also referred to as
            "steady state". Servers MAY require additional trademark
            protection during this phase.</t>

            <t hangText="custom">A custom server launch phase that is defined
            using the "name" attribute.</t>
          </list></t>

        <t>For extensibility, the &lt;launch:phase&gt; element includes an
        OPTIONAL "name" attribute that can define a sub-phase or the full name
        of the phase when the &lt;launch:phase&gt; element has the "custom"
        value.  For example, the "claims" launch phase could have two 
        sub-phases that include "landrush" and "open".</t>
        
        <t>Launch phases MAY overlap to support the "claims" launch phase, defined in the <eref
      target="http://tools.ietf.org/html/draft-lozano-tmch-func-spec">TMCH Functional Specification</eref>, and to support 
      a traditional "landrush" launch phase.  The overlap of the "claims" and "landrush" launch phases 
      SHOULD be handled by setting "claims" as the &lt;launch:phase&gt; value and setting 
      "landrush" as the sub-phase with the "name" attribute.  For example, the &lt;launch:phase&gt; 
      element SHOULD be &lt;launch:phase name="landrush"&gt;claims&lt;/launch:phase&gt;.
        </t>
      </section>

      <section anchor="statuses" title="Status Values">
        <t>A Launch Application or Launch Registration object MAY have a launch status value. The
        &lt;launch:status&gt; element is used to convey the launch status pertaining to
        the object, beyond what is specified in the object mapping.  A Launch Application or Launch Registration MUST set the <xref target="RFC5731"/> "pendingCreate" status if 
        a launch status is supported and the launch status is not one of the final statuses, including the "allocated" and "rejected" statuses.</t>  

        <t>The following status values are defined using the 
        required "s" attribute: <list style="hanging">
            <t hangText="pendingValidation:">The initial state of a newly-created
            application or registration object. The application or registration requires validation,
            but the validation process has not yet completed.</t>

            <t hangText="validated:">The application or registration meets relevant registry
            rules.</t>

            <t hangText="invalid:">The application or registration does not validate according
              to registry rules. Server policies permitting, it may transition back into "pendingValidation"
              for revalidation, after modifications are made to ostensibly correct attributes that
              caused the validation failure.
            </t>

            <t hangText="pendingAllocation:">The allocation of the application or registration 
            is pending based on the results of some out-of-band process (for example,
            an auction).</t>

            <t hangText="allocated:">The object corresponding to the application or registration 
            has been provisioned.  Is a possible end state of an
            application or registration object.</t>

            <t hangText="rejected:">The application or registration object
            was not provisioned.  Is a possible end state of an
            application or registration object.</t>

            <t hangText="custom:">A custom status that is defined using the 
            "name" attribute.</t>
          </list></t>

       <t>Each status value MAY be accompanied by a string of human-readable 
        text that describes the rationale for the status applied to the object.
        The OPTIONAL "lang" attribute MAY be present to identify the language 
        if the negotiated value is something other than the default value of 
        "en" (English).</t>
        
        <t>For extensibility the &lt;launch:status&gt; element includes an
        OPTIONAL "name" attribute that can define a sub-status or the full name
        of the status when the status value is "custom".  The server SHOULD 
        NOT use the "custom" status value.</t>

        <t>Certain status values MAY be combined. For example, an application or registration 
        may be both "invalid" and "rejected". Additionally, certain statuses MAY be
        skipped. For example, an application or registration MAY immediately start at the
        "allocated" status or an application or registration MAY skip the "pendingAllocation" status. 
        If the launch phase does
        not require validation of a request, an application or registration MAY immediately skip to
        "pendingAllocation".</t>

        <section title="State Transition">
          <figure align="center" anchor="fsm">
            <artwork align="left"><![CDATA[

                   | request                               
                   |                                       
                   |     +--------------------------+      
                   |     |                          |      
                   v     v                          |      
         +-------------------+                      |      
         |                   |                      |      
         | pendingValidation +--------------+       |      
         |                   |              |       |      
         +---------+---------+              |       |      
                   |                        |       |      
                   |                        |       |      
                   v                        v       |      
             +-----------+             +---------+  |      
             |           |             |         |  |      
             | validated |             | invalid +--+      
             |           |             |         |         
             +-----+-----+             +----+----+         
                   |                        |              
                   |                        |              
                   v                        |              
         +-------------------+              |              
         |                   |              |              
         | pendingAllocation +-----------+  |              
         |                   |           |  |              
         +---------+---------+           |  |              
                   |                     |  |              
                   |                     |  |              
                   |                     |  |              
                   |                     |  |              
                   |                     |  |              
                   v                     v  v              
              +---------+             +--------+           
             /           \           /          \          
             | allocated |           | rejected |          
             \           /           \          /          
              +---------+             +--------+       

            ]]></artwork>
          </figure>
        </section>
      </section>

      <section anchor="pollMessaging" title="Poll Messaging">
        <t>A Launch Application MUST and a Launch Registration MAY be handled as a domain name of <xref target="RFC5731"/> 
        in "pendingCreate" status, with the launch status values defined in <xref target="statuses"/>.  
        As a Launch Application or Launch Registration transitions between the status values 
        defined in <xref target="statuses"/>, the server SHOULD insert poll messages, per <xref target="RFC5730"/>,
        for the applicable intermediate statuses, including the 
        "pendingValidation", "validated", "pendingAllocation, and "invalid" statuses, using the 
        &lt;domain:infData&gt; element with the &lt;launch:infData&gt; extension.  The &lt;domain:infData&gt; element 
        MAY contain non-mandatory information, like contact and name server information.  Also, 
        further extensions that would normally be included in the response of a &lt;domain:info&gt; command, 
        per <xref target="RFC5731"/>, MAY be included.  For the final statuses, including the 
        "allocated" and "rejected" statuses, the server MUST insert a &lt;domain:panData&gt; poll message, per <xref target="RFC5731"/>, 
        with the &lt;launch:infData&gt; extension.</t>
        
        <figure>
        <preamble>The following is an example poll message for a Launch Application 
        that has transitioned to the "pendingAllocation" state.</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="1301">
S:      <msg>Command completed successfully; ack to dequeue</msg>
S:    </result>
S:    <msgQ count="5" id="12345">
S:      <qDate>2013-04-04T22:01:00.0Z</qDate>
S:      <msg>Application pendingAllocation.</msg>
S:    </msgQ>
S:    <resData>
S:      <domain:infData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>example.tld</domain:name>
S:        ...
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <launch:infData
S:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
S:        <launch:phase>sunrise</launch:phase>
S:          <launch:applicationID>abc123</launch:applicationID>
S:          <launch:status s="pendingAllocation"/>
S:      </launch:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></artwork>
	</figure>
        
        
        <figure>
        <preamble>The following is an example &lt;domain:panData&gt; poll message for 
        an "allocated" Launch Application.</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="1301">
S:      <msg>Command completed successfully; ack to dequeue</msg>
S:    </result>
S:    <msgQ count="5" id="12345">
S:      <qDate>2013-04-04T22:01:00.0Z</qDate>
S:      <msg>Application successfully allocated.</msg>
S:    </msgQ>
S:    <resData>
S:      <domain:panData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name paResult="1">example.tld</domain:name>
S:        <domain:paTRID>
S:          <clTRID>ABC-12345</clTRID>
S:          <svTRID>54321-XYZ</svTRID>
S:        </domain:paTRID>
S:        <domain:paDate>2013-04-04T22:00:00.0Z</domain:paDate>
S:      </domain:panData>
S:    </resData>
S:    <extension>
S:      <launch:infData
S:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
S:        <launch:phase>sunrise</launch:phase>
S:          <launch:applicationID>abc123</launch:applicationID>
S:          <launch:status s="allocated"/>
S:      </launch:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>BCD-23456</clTRID>
S:      <svTRID>65432-WXY</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></artwork>
	</figure>
	
        <figure>
        <preamble>The following is an example &lt;domain:panData&gt; poll message for 
        an "allocated" Launch Registration.</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="1301">
S:      <msg>Command completed successfully; ack to dequeue</msg>
S:    </result>
S:    <msgQ count="5" id="12345">
S:      <qDate>2013-04-04T22:01:00.0Z</qDate>
S:      <msg>Registration successfully allocated.</msg>
S:    </msgQ>
S:    <resData>
S:      <domain:panData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name paResult="1">example.tld</domain:name>
S:        <domain:paTRID>
S:          <clTRID>ABC-12345</clTRID>
S:          <svTRID>54321-XYZ</svTRID>
S:        </domain:paTRID>
S:        <domain:paDate>2013-04-04T22:00:00.0Z</domain:paDate>
S:      </domain:panData>
S:    </resData>
S:    <extension>
S:      <launch:infData
S:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
S:        <launch:phase>sunrise</launch:phase>
S:          <launch:status s="allocated"/>
S:      </launch:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>BCD-23456</clTRID>
S:      <svTRID>65432-WXY</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></artwork>
	</figure>
	
     	</section>


      <section anchor="validationModels" title="Mark Validation Models">
        <t>A server MUST support at least one of the following models for validating 
        trademark information:</t>

        <t><list style="hanging">

            <t hangText="code">Use of a mark code by itself to validate 
            that the mark matches the domain name.  This model is supported 
            using the &lt;launch:codeMark&gt; element with just the 
            &lt;launch:code&gt; element.</t>

            <t hangText="mark">The mark information is passed without any
            other validation element. The server will use some custom form of
            validation to validate that the mark information is authentic. This
            model is supported using the &lt;launch:codeMark&gt; element with 
            just the <xref target="mark">&lt;mark:mark&gt;</xref> element.</t>

            <t hangText="code with mark:">A code is used along with the mark
            information by the server to validate the mark utilizing an external party. 
            The code represents some form of
            secret that matches the mark information passed. This model is
            supported using the &lt;launch:codeMark&gt; element that contains both the
            &lt;launch:code&gt; and the <xref target="mark">&lt;mark:mark&gt;</xref> elements.</t>

            <t hangText="signed mark:">The mark information is digitally
            signed as described in the <xref target="digitalsignature">Digital Signature</xref>
            section.  The digital signature can be directly validated by the 
            server using the public key
            of the external party that created the signed mark using its private key. This model is 
            supported using the
            <xref target="signedMark">&lt;smd:signedMark&gt;</xref> and 
            <xref target="encodedSignedMark">&lt;smd:encodedSignedMark&gt;</xref> 
            elements.</t>
          </list></t>

        <t>More than one &lt;launch:codeMark&gt;, <xref target="signedMark">&lt;smd:signedMark&gt;</xref>, 
        or <xref target="encodedSignedMark">&lt;smd:encodedSignedMark&gt;</xref> element MAY be specified. The maximum
        number of marks per domain name is up to server policy.</t>
        
        <section anchor="codeMark" title="&lt;launch:codeMark&gt; element">
           <t>The &lt;launch:codeMark&gt; element that is used by the "code", "mark", 
           and "code with mark" validation models, has the following child 
           elements:</t>
           <t><list style="hanging">
              <t hangText="&lt;launch:code&gt;:">OPTIONAL mark code used to 
              validate the <xref target="mark">&lt;mark:mark&gt;</xref> information.  The mark code 
              is be a mark-specific secret that the server can verify 
              against a third party.  The OPTIONAL "validatorID" attribute is the <xref target="validatorID">Validator Identifier</xref> 
              whose value indicates which Trademark Validator that the code originated from, with no default value.</t>
              <t hangText="&lt;mark:mark&gt;:">OPTIONAL mark information 
              with child elements defined in the <xref target="mark">Mark</xref> 
              section.</t>
           </list></t>
                   <figure>
            <preamble>The following is an example &lt;launch:codeMark&gt;
            element with both a &lt;launch:code&gt; and <xref target="mark">&lt;mark:mark&gt;</xref> element.
            </preamble>

            <artwork><![CDATA[
<launch:codeMark>
  <launch:code validatorID="sample">
    49FD46E6C4B45C55D4AC</launch:code>
  <mark:mark xmlns:mark="urn:ietf:params:xml:ns:mark-1.0">
    ...
  </mark:mark>
</launch:codeMark>]]></artwork>
          </figure>
           
        </section>

      <section anchor="mark" title="&lt;mark:mark&gt; element">
        <t>A &lt;mark:mark&gt; element describes an applicant's prior right
        to a given domain name that is used with the "mark", "mark with code", and 
        the "signed mark" validation models.  The &lt;mark:mark&gt; element is defined 
        in <xref target="draft-ietf-eppext-tmch-smd"/>.  
        A new mark format can be supported by creating a new 
        XML schema for the mark that has an element that substitutes 
        for the &lt;mark:abstractMark&gt; element from <xref target="draft-ietf-eppext-tmch-smd"/>.</t>
      </section>
            
      <section anchor="digitalsignature" title="Digital Signature">
        <t>Digital signatures MAY be used by the server to validate either 
        the mark information, when using the "signed mark" validation model with the 
        <xref target="signedMark">&lt;smd:signedMark&gt;</xref> element or the <xref target="encodedSignedMark">&lt;smd:encodedSignedMark&gt;</xref> element.  
        </t>
     <section anchor="signedMark" title="&lt;smd:signedMark&gt; element">
        <t>The &lt;smd:signedMark&gt; element contains the digitally signed mark information.  The &lt;smd:signedMark&gt; 
        element is defined in <xref target="draft-ietf-eppext-tmch-smd"/>.  A new 
        signed mark format can be supported by creating a new XML schema 
        for the signed mark that has an element that substitutes for 
        the &lt;smd:abstractSignedMark&gt; element from <xref target="draft-ietf-eppext-tmch-smd"/>.  
        </t>
        </section>

     <section anchor="encodedSignedMark" title="&lt;smd:encodedSignedMark&gt; element">
        <t>The &lt;smd:encodedSignedMark&gt; element contains an encoded form of 
        the digitally signed <xref target="signedMark">&lt;smd:signedMark&gt;</xref> element.  The 
        &lt;smd:encodedSignedMark&gt; element is defined in <xref target="draft-ietf-eppext-tmch-smd"/>.  
        A new encoded signed mark format can be supported by creating a new XML schema 
        for the encoded signed mark that has an element that substitutes for the 
        &lt;smd:encodedSignedMark&gt; element from <xref target="draft-ietf-eppext-tmch-smd"/>.
        </t>
        </section>
        
      </section>
      </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 in the Launch
      Phase Extension.</t>

      <t>This mapping is designed to be flexible, requiring only a minimum set
      of required elements.</t>

      <t>While it is meant to serve several use cases, it does not prescribe
      any interpretation by the client or server. Such processing is typically
      highly policy-dependent and therefore specific to implementations.</t>

      <t>Operations on application objects are done via one or more of the
      existing EPP verbs defined in the <xref target="RFC5731">EPP domain name
      mapping</xref>. Registries MAY choose to support a subset of the
      operations.</t>

      <section anchor="checkCommand" title="EPP &lt;check&gt; Command">
       <t>There are two forms of the extension to the EPP &lt;check&gt; command:  
       the <xref target="claimsCheckForm">Claims Check Form</xref> 
       and the <xref target="availCheckForm">Availability Check Form</xref>.  The 
       &lt;launch:check&gt; element "type" attribute defines the form, 
       with the value of "claims" for the <xref target="claimsCheckForm">Claims Check Form</xref> 
       and with the value of "avail" for the <xref target="availCheckForm">Availability Check Form</xref>.  
       The default value of the "type" attribute is "claims".  The forms supported by the server is determined by server policy.  
       The server MUST return an EPP error result code of 2307 
       if it receives a check form that is not supported.</t>  
       
       <section anchor="claimsCheckForm" title="Claims Check Form">
        <t>
        The Claims Check Form defines 
        a new command called the Claims Check Command 
        that is used to determine whether or not there are any matching 
        trademarks, in the specified launch phase, for each domain name passed in the command.  
        The availability check information defined in the <xref target="RFC5731">EPP domain name
      mapping</xref> MUST NOT be returned for the Claims Check Command.  This form is the default form and MAY be 
        explicitly identified by setting the &lt;launch:check&gt; "type" attribute to "claims".</t>  
        <t>Instead of 
        returning whether the domain name is available, the Claims Check Command will return whether 
        or not at least one matching trademark exists for the domain name.  
        If there is at least one matching trademark that exists for the 
        domain name, a &lt;launch:claimKey&gt; element is returned.  
        The client MAY then use the value of the &lt;launch:claimKey&gt; element
        to obtain information needed to generate the Trademark Claims Notice from 
        Trademark Validator based on the <xref target="validatorID">Validator Identifier</xref>.  The 
        unique notice identifier of the Trademark Claims Notice MUST be passed in 
        the &lt;launch:noticeID&gt; element of the extension to the 
        <xref target="createCommand">Create Command</xref>.</t>  
        
        <t>The &lt;domain:name&gt; elements in the EPP &lt;check&gt; 
        command of <xref target="RFC5731">EPP domain name mapping</xref> define 
        the domain names to check for matching trademarks.  
        The &lt;launch:check&gt; element contains the following child elements:</t>

          <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;launch:phase&gt;">The launch phase that SHOULD be 
              "claims".</t>
            </list></t>
          <figure>
            <preamble>Example Claims Check command using the &lt;check&gt;
            domain command and the &lt;launch:check&gt; extension with 
            the "type" explicitly set to "claims", to  
            determine if "example1.tld" and "example2.tld" have any 
            matching trademarks during the "claims" launch phase:</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:check>
C:   </check>
C:   <extension>
C:    <launch:check
C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
C:     type="claims">
C:      <launch:phase>claims</launch:phase>
C:    </launch:check>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>

          <t>If the &lt;check&gt; command has been processed successfully, the EPP 
          &lt;response&gt; MUST contain an &lt;extension&gt; &lt;launch:chkData&gt; element 
          that identifies the launch namespace.  The &lt;launch:chkData&gt; element 
          contains the following child elements:</t>

          <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;launch:phase&gt;">The launch phase that SHOULD be 
              "claims".</t>

              <t hangText="&lt;launch:cd&gt;">One or more &lt;launch:cd&gt; 
              elements that contain the following child elements:</t>
              
              <t><list hangIndent="4" style="hanging">
            <t hangText="&lt;launch:name&gt;">Contains the fully 
            qualified name of the queried domain name.  This element 
            MUST contain an "exists" attribute whose value 
            indicates if a matching trademark exists for the domain 
            name.  A value of "1" (or "true") means that a matching 
            trademark does exist for the claims launch phase.  
            A value of "0" (or "false") means that 
            a matching trademark does not exist.</t>
            <t hangText="&lt;launch:claimKey&gt;">An OPTIONAL claim key 
            that MAY be passed to a third-party 
            trademark validator such as the Trademark Clearinghouse (TMCH) 
            for querying the information needed to generate a 
            Trademark Claims Notice.  The &lt;launch:claimKey&gt; is used 
            as the key for the query in place of the domain name 
            to securely query the service without using a well-known 
            value like a domain name.  The OPTIONAL "validatorID" attribute is the <xref target="validatorID">Validator Identifier</xref> 
            whose value indicates which Trademark Validator to query for the Claims Notice information, with 
            the default being the ICANN TMCH.</t>  
              </list></t>

            </list></t>

          <figure>
            <preamble>Example Claims Check response when no matching trademarks
             are found for the domain name example1.tld and matching 
             trademarks are found for the domain name example2.tld for the 
             "claims" launch phase:</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:   <extension>
S:     <launch:chkData
S:      xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
S:      <launch:phase>claims</launch:phase>
S:      <launch:cd>
S:        <launch:name exists="0">example1.tld</launch:name>
S:      </launch:cd>
S:      <launch:cd>
S:        <launch:name exists="1">example2.tld</launch:name>
S:        <launch:claimKey validatorID="tmch">
S:        2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001
S:        </launch:claimKey>
S:      </launch:cd>
S:     </launch:chkData>
S:    </extension>
S:    <trID>
S:     <clTRID>ABC-12345</clTRID>
S:     <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></artwork>
          </figure>
      
        </section>    
        
        
       <section anchor="availCheckForm" title="Availability Check Form">
        <t>The Availability Check Form defines additional elements to extend the EPP
        &lt;check&gt; command described in the 
        <xref target="RFC5731">EPP domain name mapping</xref>.  No additional 
        elements are defined for the EPP &lt;check&gt; response.  This form MUST be 
        identified by setting the &lt;launch:check&gt; "type" attribute to "avail".
        </t>
        <t>
        The EPP &lt;check&gt; command is used to determine if an object 
        can be provisioned within a repository.  Domain names may be made 
        available only in unique launch phases, whilst remaining unavailable 
        for concurrent launch phases.  In addition to the elements 
        expressed in the &lt;domain:check&gt;, the command is extended with 
        the &lt;launch:check&gt; element that contains the following child elements:</t>
        
          <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;launch:phase&gt;">The launch phase to which 
              domain name availability should be determined.</t>
            </list></t>
          <figure>
            <preamble>Example Availability Check Form command using the &lt;check&gt;
            domain command and the &lt;launch:check&gt; extension with 
            the "type" set to "avail", to determine  
            the availability of two domain names in the 
            "idn-release" custom launch phase:</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:check>
C:   </check>
C:   <extension>
C:    <launch:check
C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
C:     type="avail">
C:      <launch:phase name="idn-release">custom</launch:phase>
C:    </launch:check>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>
          
        <t>The Availability Check Form does not define any extension to the response of an
        &lt;check&gt; domain command. After processing the command, the
        server replies with a standard EPP response as defined in the <xref
        target="RFC5731">EPP domain name mapping</xref>.</t>
        
        </section>    
        
        
      </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 to be used in conjunction with the
        <xref target="RFC5731">EPP domain name mapping</xref>.</t>
        
        <t>The EPP &lt;info&gt; command is used to retrieve information 
        for a launch phase registration or application.  The <xref target="applicationID">Application Identifier</xref> 
        returned in the &lt;launch:creData&gt; element of the <xref target="createCommand">create response</xref> 
        is used for retrieving information for a Launch Application.  A &lt;launch:info&gt; element
        is sent along with the regular &lt;info&gt; domain command. The &lt;launch:info&gt; element includes 
        an OPTIONAL "includeMark" boolean attribute, with a default value of "false", to indicate whether 
        or not to include the mark in the response.  The
        &lt;launch:info&gt; element contains the following child
        elements:</t>
        
          <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;launch:phase&gt;">The phase during which the
              application or registration was submitted or is associated with. 
              Server policy defines the phases that are supported.</t>

              <t hangText="&lt;launch:applicationID&gt;">OPTIONAL application
              identifier of the Launch Application.</t>
            </list></t>

          <figure>
            <preamble>Example &lt;info&gt; domain command with the
            &lt;launch:info&gt; extension to retrieve information 
            for the sunrise application for example.tld and application 
            identifier "abc123":</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:   <info>
C:    <domain:info
C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:      <domain:name>example.tld</domain:name>
C:    </domain:info>
C:   </info>
C:   <extension>
C:    <launch:info
C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" 
C:       includeMark="true">
C:      <launch:phase>sunrise</launch:phase>
C:      <launch:applicationID>abc123</launch:applicationID>
C:    </launch:info>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>

          <figure>
            <preamble>Example &lt;info&gt; domain command with the
            &lt;launch:info&gt; extension to retrieve information 
            for the sunrise registration for example.tld:</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:   <info>
C:    <domain:info
C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:      <domain:name>example.tld</domain:name>
C:    </domain:info>
C:   </info>
C:   <extension>
C:    <launch:info
C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C:      <launch:phase>sunrise</launch:phase>
C:    </launch:info>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>


          <t>If the query was successful, the server replies with a
          &lt;launch:infData&gt; element along with the regular EPP
          &lt;resData&gt;. The &lt;launch:infData&gt; contains the following
          child elements:</t>
          <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;launch:phase&gt;">The phase during which the
              application was submitted, or is associated with, that matches the associated 
              &lt;info&gt; command &lt;launch:phase&gt;.</t>

              <t hangText="&lt;launch:applicationID&gt;">OPTIONAL Application
              Identifier of the Launch Application.</t>

              <t hangText="&lt;launch:status&gt;">OPTIONAL status of the Launch Application
              using one of the supported <xref target="statuses">status
              values</xref>.</t>

              <t hangText="&lt;mark:mark&gt;">Zero or more
              <xref target="mark">&lt;mark:mark&gt;</xref> elements.
              </t>
              
            </list></t>

          <figure>
            <preamble>Example &lt;info&gt; domain response using the 
            &lt;launch:infData&gt; extension with the mark
            information:</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:infData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>example.tld</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="pendingCreate"/>
S:        <domain:registrant>jd1234</domain:registrant>
S:        <domain:contact type="admin">sh8013</domain:contact>
S:        <domain:contact type="tech">sh8013</domain:contact>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crID>ClientY</domain:crID>
S:        <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:authInfo>
S:          <domain:pw>2fooBAR</domain:pw>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <launch:infData
S:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
S:        <launch:phase>sunrise</launch:phase>
S:          <launch:applicationID>abc123</launch:applicationID>
S:          <launch:status s="pendingValidation"/>
S:          <mark:mark
S:            xmlns:mark="urn:ietf:params:xml:ns:mark-1.0">
S:             ...
S:         </mark:mark>
S:      </launch:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]></artwork>
          </figure>


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

      <section anchor="createCommand" title="EPP &lt;create&gt; Command">
        <t>There are four forms of the extension to the EPP &lt;create&gt;
        command that include the <xref target="sunriseCreateForm">
            Sunrise Create Form</xref>, the <xref target="claimsCreateForm">Claims Create Form</xref>, 
            the <xref target="generalCreateForm">General Create Form</xref>, 
            and the <xref target="mixedCreateForm">Mixed Create Form</xref>.  
        The form is dependent on the supported <xref target="phases">launch phases</xref> as defined below.  
        </t>

        <t><list style="hanging">
            <t hangText="sunrise">The EPP &lt;create&gt; command with the
            "sunrise" launch phase is used to submit a registration with trademark
            information that can be verified by the server with the
            &lt;domain:name&gt; value. The <xref target="sunriseCreateForm">
            Sunrise Create Form</xref> is used for the "sunrise" launch phase.</t>

            <t hangText="landrush">The EPP &lt;create&gt; command with the
            "landrush" launch phase MAY use the <xref target="generalCreateForm">
            General Create Form</xref> to explicitly specify the phase and 
            optionally define the expected type of object to create.</t>

            <t hangText="claims">The EPP &lt;create&gt; command with the
            "claims" launch phase is used to pass the information associated 
            with the presentation and acceptance of the Claims Notice.  The 
            <xref target="claimsCreateForm">Claims Create Form</xref> is used 
            and the <xref target="generalCreateForm">
            General Create Form</xref> MAY be used
            for the "claims" launch phase.</t>

            <t hangText="open">The EPP &lt;create&gt; command with the "open"
            launch phase is undefined but the form supported is up to server
            policy.</t>

            <t hangText="custom">The EPP &lt;create&gt; command with the
            "custom" launch phase is undefined but the form supported is up to server
            policy.</t>
          </list></t>

        <section anchor="sunriseCreateForm" title="Sunrise Create Form">
          <t>The Sunrise Create Form of the extension to the <xref
          target="RFC5731">EPP domain name mapping</xref> includes the
          verifiable trademark information that the server uses to match
          against the domain name to authorize the domain create. A server
          MUST support one of four models in <xref
          target="validationModels">Claim Validation Models</xref> to 
          verify the trademark information passed by the client.</t>

          <t>A &lt;launch:create&gt; element is sent along with the regular
          &lt;create&gt; domain command.  The &lt;launch:create&gt; element 
        has an OPTIONAL "type" attribute that defines the expected type of object 
        ("application" or "registration") to create.  The server SHOULD validate the 
        "type" attribute, when passed, against the type of object that will be created.  
          The &lt;launch:create&gt; element
          contains the following child elements:</t>

          <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;launch:phase&gt;">The identifier for the launch phase.</t>

              <t
              hangText="&lt;launch:codeMark&gt; or &lt;smd:signedMark&gt; or &lt;smd:encodedSignedMark&gt;">
                  <list hangIndent="4" style="hanging">

              <t hangText="&lt;launch:codeMark&gt;">Zero or more
              &lt;launch:codeMark&gt; elements.  The &lt;launch:codeMark&gt;
              child elements are defined in the 
              <xref target="codeMark">&lt;launch:codeMark&gt; element</xref> 
              section.</t>

              <t hangText="&lt;smd:signedMark&gt;">Zero or more
              &lt;smd:signedMark&gt; elements.  The &lt;smd:signedMark&gt; 
              child elements are defined in 
              the <xref target="signedMark">&lt;smd:signedMark&gt; element</xref> 
              section.</t>

             <t hangText="&lt;smd:encodedSignedMark&gt;">Zero or more
              &lt;smd:encodedSignedMark&gt; elements.  The &lt;smd:encodedSignedMark&gt; 
              child elements are defined in 
              the <xref target="encodedSignedMark">&lt;smd:encodedSignedMark&gt; element</xref> 
              section.</t>
              
              </list></t>
            </list></t>


          <figure>
            <preamble>The following is an example &lt;create&gt; domain command
            using the &lt;launch:create&gt; extension, following the "code" 
            validation model, with multiple sunrise codes:</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:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.tld</domain:name>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <launch:create
C:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C:        <launch:phase>sunrise</launch:phase>
C:        <launch:codeMark>
C:          <launch:code validatorID="sample1">
C:            49FD46E6C4B45C55D4AC</launch:code>
C:        </launch:codeMark>
C:        <launch:codeMark>
C:          <launch:code>49FD46E6C4B45C55D4AD</launch:code>
C:        </launch:codeMark>
C:        <launch:codeMark>
C:          <launch:code validatorID="sample2">
C:            49FD46E6C4B45C55D4AE</launch:code>
C:        </launch:codeMark>
C:     </launch:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>


          <figure>
            <preamble>The following is an example &lt;create&gt; domain command
            using the &lt;launch:create&gt; extension, following the "mark" 
            validation model, with the mark information:</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:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>exampleone.tld</domain:name>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <launch:create
C:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C:        <launch:phase>sunrise</launch:phase>
C:        <launch:codeMark>
C:          <mark:mark
C:            xmlns:mark="urn:ietf:params:xml:ns:mark-1.0">
C:            ...
C:          </mark:mark>
C:        </launch:codeMark>
C:      </launch:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>



          <figure>
            <preamble>The following is an example &lt;create&gt; domain command
            using the &lt;launch:create&gt; extension, following the "code with mark" 
            validation model, with a code and mark information:</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:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.tld</domain:name>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <launch:create
C:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C:        <launch:phase>sunrise</launch:phase>
C:        <launch:codeMark>
C:          <launch:code validatorID="sample">
C:            49FD46E6C4B45C55D4AC</launch:code>
C:          <mark:mark
C:           xmlns:mark="urn:ietf:params:xml:ns:mark-1.0">
C:           ...
C:          </mark:mark>
C:        </launch:codeMark>
C:      </launch:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>

          <figure>
            <preamble>The following is an example &lt;create&gt; domain command
            using the &lt;launch:create&gt; extension, following the "signed mark" 
            validation model, with the signed mark information for 
            a sunrise application:</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:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>exampleone.tld</domain:name>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <launch:create
C:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
C:       type="application">
C:        <launch:phase>sunrise</launch:phase>
C:        <smd:signedMark id="signedMark"
C:         xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"> 
C:         ...
C:        </smd:signedMark>
C:      </launch:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>


          <figure>
            <preamble>The following is an example &lt;create&gt; domain command
            using the &lt;launch:create&gt; extension, following the "signed mark" 
            validation model, with the base64 encoded signed mark information:</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:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>exampleone.tld</domain:name>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <launch:create
C:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C:        <launch:phase>sunrise</launch:phase>
C:        <smd:encodedSignedMark 
C:         xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0">
C:         ...
C:        </smd:encodedSignedMark>
C:      </launch:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>

          <!-- end example sunrise create cmd -->
        </section>

        <section anchor="claimsCreateForm" title="Claims Create Form">
          <t>The Claims Create Form of the extension to the <xref
          target="RFC5731">EPP domain name mapping</xref> includes the
          information related to the registrant's acceptance of the Claims Notice 
          for the "claims" launch phase.</t>

          <t>A &lt;launch:create&gt; element is sent along with the regular
          &lt;create&gt; domain command.  The &lt;launch:create&gt; element 
        has an OPTIONAL "type" attribute that defines the expected type of object 
        ("application" or "registration") to create.  The server SHOULD validate the 
        "type" attribute, when passed, against the type of object that will be created. 
        The &lt;launch:create&gt; element contains the following child elements:</t>

          <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;launch:phase&gt;">MUST contain the value of
              "claims" to indicate the claims launch phase.</t>
              <t hangText="&lt;launch:notice&gt;">
              <list hangIndent="4" style="hanging">
            <t hangText="&lt;launch:noticeID&gt;">Unique notice identifier 
          for the Claims Notice. The &lt;launch:noticeID&gt; 
          element has an OPTIONAL "validatorID" attribute is the <xref target="validatorID">Validator Identifier</xref> whose value indicates 
          which Trademark 
          Validator is the source of the Claims Notice, with the default being the ICANN TMCH.</t>
                <t hangText="&lt;launch:notAfter&gt;">Expiry of the claims notice.</t>
                <t hangText="&lt;launch:acceptedDate&gt;">Contains the
              date and time that the Claims Notice was accepted.</t>
              </list></t>
            </list></t>

          <figure>
            <preamble>The following is an example &lt;create&gt; domain command
            using the &lt;launch:create&gt; extension with the 
            &lt;launch:notice&gt; information for the "claims"  
            launch phase:</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:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.tld</domain:name>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <launch:create
C:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C:        <launch:phase>claims</launch:phase>
C:        <launch:notice>
C:          <launch:noticeID validatorID="tmch">
C:            49FD46E6C4B45C55D4AC
C:          </launch:noticeID>
C:          <launch:notAfter>2012-06-19T10:00:10.0Z
C:          </launch:notAfter>
C:          <launch:acceptedDate>2012-06-19T09:01:30.0Z
C:          </launch:acceptedDate>
C:        </launch:notice>
C:      </launch:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>
          
        </section>
        
        
        <section anchor="generalCreateForm" title="General Create Form">
          <t>The General Create Form of the extension to the <xref
          target="RFC5731">EPP domain name mapping</xref> includes the
          launch phase and optionally the object 
          type to create.  The OPTIONAL "type" attribute defines the 
          expected type of object ("application" or "registration") to create.  
          The server SHOULD validate the "type" attribute, when passed, against 
          the type of object that will be created.</t>

          <t>A &lt;launch:create&gt; element is sent along with the regular
          &lt;create&gt; domain command. The &lt;launch:create&gt; element
          contains the following child elements:</t>

          <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;launch:phase&gt;">Contains the value of the active 
              launch phase of the server.  The server SHOULD validate the value against the 
              active server launch phase.</t>
            </list></t>

          <figure>
            <preamble>The following is an example &lt;create&gt; domain command
            using the &lt;launch:create&gt; extension for a "landrush" 
            launch phase application:</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:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.tld</domain:name>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <launch:create
C:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
C:       type="application">
C:        <launch:phase>landrush</launch:phase>
C:      </launch:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>
          
        </section>
        
        <section anchor="mixedCreateForm" title="Mixed Create Form">
        <t>The Mixed Create Form supports a mix of the create forms, where for example the 
        <xref target="sunriseCreateForm">Sunrise Create Form</xref> and the <xref target="claimsCreateForm">Claims Create Form</xref> MAY be supported in a single 
        command by including both the verified trademark information and the
        information related to the registrant's acceptance of the Claims Notice. The server MAY support the Mixed Create Form. 
        The "custom" launch phase SHOULD be used when using the Mixed Create Form.
        </t>
        <figure>
            <preamble>The following is an example &lt;create&gt; domain command
            using the &lt;launch:create&gt; extension, with using a mix of 
            the  <xref target="sunriseCreateForm">Sunrise Create Form</xref> 
            and the <xref target="claimsCreateForm">Claims Create Form</xref> by 
            including both a mark and a notice:</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:    <create>
C:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>exampleone.tld</domain:name>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <launch:create
C:       xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
C:       type="application">
C:        <launch:phase name="non-tmch-sunrise">custom</launch:phase>
C:        <launch:codeMark>
C:          <mark:mark
C:            xmlns:mark="urn:ietf:params:xml:ns:mark-1.0">
C:            ...
C:          </mark:mark>
C:        </launch:codeMark>
C:        <launch:notice>
C:          <launch:noticeID validatorID="tmch">
C:            49FD46E6C4B45C55D4AC
C:          </launch:noticeID>
C:          <launch:notAfter>2012-06-19T10:00:10.0Z
C:          </launch:notAfter>
C:          <launch:acceptedDate>2012-06-19T09:01:30.0Z
C:          </launch:acceptedDate>
C:        </launch:notice>
C:      </launch:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]></artwork>
          </figure>
       </section>
        
        
        <section anchor="createResponse" title="Create Response">
        
          <t>If the create was successful, the server MAY reply with the
          &lt;launch:creData&gt; element along with the regular EPP
          &lt;resData&gt; to indicate the server generated <xref
          target="applicationID">Application Identifier</xref>, when multiple
          applications of a given domain name are supported; otherwise no
          extension is included with the regular EPP &lt;resData&gt;. The
          &lt;launch:creData&gt; element contains the following child
          elements:</t>
          <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;launch:phase&gt;">The phase of the application
              that mirrors the &lt;launch:phase&gt; element included in the
              &lt;launch:create&gt;.</t>

              <t hangText="&lt;launch:applicationID&gt;">The application
              identifier of the application.</t>
            </list></t>

          <figure>
            <preamble>An example response when multiple overlapping
            applications are supported by the server:</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="1001">
S:      <msg>Command completed successfully; action pending</msg>
S:    </result>
S:    <resData>
S:      <domain:creData
S:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:       <domain:name>example.tld</domain:name>
S:       <domain:crDate>2010-08-10T15:38:26.623854Z</domain:crDate>
S:      </domain:creData>
S:    </resData>
S:    <extension>
S:      <launch:creData 
S:        xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
S:        <launch:phase>sunrise</launch:phase>
S:        <launch:applicationID>2393-9323-E08C-03B1
S:        </launch:applicationID>
S:      </launch:creData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>
    ]]></artwork>
          </figure>
        
        
        </section>
        
      </section>

      <!-- end CREATE command -->

      <section anchor="updateCommand" title="EPP &lt;update&gt; Command">
        <t>This extension defines additional elements to extend the EPP
        &lt;update&gt; command to be used in conjunction with the domain name
        mapping.</t>

        <t>A client MUST NOT pass the extension on 
        an EPP &lt;update&gt; command to a server that does not support launch 
        applications.  A server that does not support launch applications during 
        its launch phase MUST return an
        EPP error result code of 2102 when receiving an EPP &lt;update&gt; 
        command with the extension.</t>

        <t>Registry policies permitting, clients may update an application
        object by submitting an EPP &lt;update&gt; command along with a
        &lt;launch:update&gt; element to indicate the application object to be
        updated. The &lt;launch:update&gt; element contains the following
        child elements:</t>
        <t><list hangIndent="4" style="hanging">
            <t hangText="&lt;launch:phase&gt;">The phase during which the
            application was submitted or is associated with.</t>

            <t hangText="&lt;launch:applicationID&gt;">The application
            identifier for which the client wishes to update.</t>
          </list></t>

        <figure>
          <preamble>The following is an example &lt;update&gt; domain command with
          the &lt;launch:update&gt; extension to add and remove a name server
          of a sunrise application with the application identifier
          "abc123":</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:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.tld</domain:name>
C:        <domain:add>
C:            <domain:ns>
C:              <domain:hostObj>ns2.example.tld</domain:hostObj>
C:            </domain:ns>
C:          </domain:add>
C:          <domain:rem>
C:            <domain:ns>
C:              <domain:hostObj>ns1.example.tld</domain:hostObj>
C:            </domain:ns>
C:          </domain:rem>
C:      </domain:update>
C:    </update>
C:    <extension>
C:    <launch:update
C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C:      <launch:phase>sunrise</launch:phase>
C:      <launch:applicationID>abc123</launch:applicationID>
C:    </launch:update>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>
]]></artwork>
        </figure>

        <!-- example update cmd -->
        
        <t>This extension does not define any extension to the response of an
        &lt;update&gt; domain command. After processing the command, the
        server replies with a standard EPP response as defined in the <xref
        target="RFC5731">EPP domain name mapping</xref>.</t>        
        
      </section>
      <!-- end UPDATE command -->

      <section anchor="deleteCommand" title="EPP &lt;delete&gt; Command">
        <t>This extension defines additional elements to extend the EPP
        &lt;delete&gt; command to be used in conjunction with the domain name
        mapping.</t>

        <t>A client MUST NOT pass the extension on 
        an EPP &lt;delete&gt; command to a server that does not support launch 
        applications.  A server that does not support launch applications during 
        its launch phase MUST return an
        EPP error result code of 2102 when receiving an EPP &lt;delete&gt; 
        command with the extension.</t>

        <t>Registry policies permitting, clients MAY withdraw an application
        by submitting an EPP &lt;delete&gt; command along with a
        &lt;launch:delete&gt; element to indicate the application object to be
        deleted. The &lt;launch:delete&gt; element contains the following
        child elements:</t>
        <t><list hangIndent="4" style="hanging">
            <t hangText="&lt;launch:phase&gt;">The phase during which the
            application was submitted or is associated with.</t>

            <t hangText="&lt;launch:applicationID&gt;">The application
            identifier for which the client wishes to delete.</t>
          </list></t>

        <figure>
          <preamble>The following is an example &lt;delete&gt; domain command with
          the &lt;launch:delete&gt; 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:   <delete>
C:    <domain:delete
C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:      <domain:name>example.tld</domain:name>
C:    </domain:delete>
C:   </delete>
C:   <extension>
C:    <launch:delete
C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
C:      <launch:phase>sunrise</launch:phase>
C:      <launch:applicationID>abc123</launch:applicationID>
C:    </launch:delete>
C:   </extension>
C:   <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>    
]]></artwork>
        </figure>

        <!-- example delete cmd -->
        
        <t>This extension does not define any extension to the response of a
        &lt;delete&gt; domain command. After processing the command, the
        server replies with a standard EPP response as defined in the <xref
        target="RFC5731">EPP domain name mapping</xref>.</t>
        
      </section>
      <!-- end DELETE command -->

      <section anchor="renewCommand" title="EPP &lt;renew&gt; Command">
        <t>This extension does not define any extension to the EPP
        &lt;renew&gt; command or response described in the <xref
        target="RFC5731">EPP domain name mapping</xref>.</t>
      </section>
      <!-- end RENEW command -->

      <section anchor="transferCommand" title="EPP &lt;transfer&gt; Command">
        <t>This extension does not define any extension to the EPP
        &lt;transfer&gt; command or response described in the <xref
        target="RFC5731">EPP domain name mapping</xref>.</t>
      </section>
      <!-- end TRANSFER command -->
      
    </section>

    <!-- EPP command mapping -->

    <section anchor="syntax" title="Formal Syntax">
    
      <t>One schema is presented here that is the EPP Launch 
      Phase Mapping 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="Launch Schema">
      <t>Copyright (c) 2012 IETF Trust and the persons identified as authors
      of the code. All rights reserved.</t>

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

      <t><list style="symbols">
          <t>Redistributions of source code must retain the above copyright
          notice, this list of conditions and the following disclaimer.</t>

          <t>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.</t>

          <t>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.</t>
        </list></t>

      <t>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.</t>

      <figure>
        <artwork><![CDATA[
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema 
  targetNamespace="urn:ietf:params:xml:ns:launch-1.0" 
  xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" 
  xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
  xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"
  xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified">
  
<!--
Import common element types.
-->
  <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
          schemaLocation="eppcom-1.0.xsd"/> 
  
  <import namespace="urn:ietf:params:xml:ns:mark-1.0"
          schemaLocation="mark-1.0.xsd"/> 

  <import namespace="urn:ietf:params:xml:ns:signedMark-1.0"
          schemaLocation="signedMark-1.0.xsd"/> 
  
  <annotation>
    <documentation> 
      Extensible Provisioning Protocol v1.0 
      domain name extension schema 
      for the launch phase processing.  
    </documentation>
  </annotation>
  
  <!-- 
  Child elements found in EPP commands.  
  -->
  <element name="check" type="launch:checkType"/>
  <element name="info" type="launch:infoType"/>
  <element name="create" type="launch:createType"/>
  <element name="update" type="launch:idContainerType"/>
  <element name="delete" type="launch:idContainerType"/>
  
  <!-- 
  Common container of id (identifier) element
  -->
  <complexType name="idContainerType">
    <sequence>
      <element name="phase" type="launch:phaseType"/>
      <element name="applicationID" type="launch:applicationIDType"/>
    </sequence>
  </complexType>
  
  <!-- 
  Definition for application identifier
  -->
  <simpleType name="applicationIDType">
    <restriction base="token"/>
  </simpleType>
  
  <!-- 
  Definition for launch phase.  Name is an optional attribute
  used to extend the phase type.  For example, when 
  using the phase type value of &qt;custom&gt;, the name 
  can be used to specify the custom phase.  
  -->
  <complexType name="phaseType">
    <simpleContent>
      <extension base="launch:phaseTypeValue">
        <attribute name="name" type="token"/>
      </extension>
    </simpleContent>
  </complexType>
  
  <!-- 
  Enumeration of for launch phase values.  
  -->
  <simpleType name="phaseTypeValue">
      <restriction base="token">
        <enumeration value="sunrise"/>
        <enumeration value="landrush"/>
        <enumeration value="claims"/>
        <enumeration value="open"/>
        <enumeration value="custom"/>
    </restriction>
  </simpleType>
  
  
  <!-- 
  Definition for the sunrise code   
  -->
  <simpleType name="codeValue">
    <restriction base="token">
      <minLength value="1"/>
    </restriction>
  </simpleType>
  
  <complexType name="codeType">
    <simpleContent>
      <extension base="launch:codeValue">
        <attribute name="validatorID" 
          type="launch:validatorIDType" use="optional"/>
      </extension>
    </simpleContent>
  </complexType>
  
  <!-- 
  Definition for the notice identifier   
  -->
  <simpleType name="noticeIDValue">
    <restriction base="token">
      <minLength value="1"/>
    </restriction>
  </simpleType>
  
  <complexType name="noticeIDType">
    <simpleContent>
      <extension base="launch:noticeIDValue">
        <attribute name="validatorID" 
          type="launch:validatorIDType" use="optional"/>
      </extension>
    </simpleContent>
  </complexType>
  
  <!-- 
  Definition for the validator identifier   
  -->
  <simpleType name="validatorIDType">
    <restriction base="token">
      <minLength value="1"/>
    </restriction>
  </simpleType>
      
  <!-- 
  Possible status values for sunrise application 
  -->
    <simpleType name="statusValueType">
    <restriction base="token">
        <enumeration value="pendingValidation"/>
        <enumeration value="validated"/>
        <enumeration value="invalid"/>
        <enumeration value="pendingAllocation"/>
        <enumeration value="allocated"/>
        <enumeration value="rejected"/>
        <enumeration value="custom"/>
      </restriction>
    </simpleType>
  
  <!-- 
  Status type definition
  -->
  <complexType name="statusType">
    <simpleContent>
      <extension base="normalizedString">
        <attribute name="s" type="launch:statusValueType" 
          use="required"/>
        <attribute name="lang" type="language" 
          default="en"/>
        <attribute name="name" type="token"/>
      </extension>
    </simpleContent>
  </complexType>
  
  <!--
  codeMark Type that contains an optional code 
  with mark information.
  -->
  <complexType name="codeMarkType">
    <sequence>
    <element name="code" type="launch:codeType"
      minOccurs="0"/>
    <element ref="mark:abstractMark"
      minOccurs="0"/>
  </sequence>
  </complexType>
  
  <!-- 
  Child elements for the create command
  -->
  <complexType name="createType">
    <sequence>
      <element name="phase" type="launch:phaseType"/>
      <choice minOccurs="0">
        <element name="codeMark" type="launch:codeMarkType"
          maxOccurs="unbounded"/>
        <element ref="smd:abstractSignedMark" 
         maxOccurs="unbounded"/>
        <element ref="smd:encodedSignedMark" 
         maxOccurs="unbounded"/>
      </choice>
      <element name="notice" minOccurs="0"
       type="launch:createNoticeType"/> 
    </sequence>
    <attribute name="type" type="launch:objectType"/>
  </complexType>

  <!--
  Type of launch object
  -->
  <simpleType name="objectType">
      <restriction base="token">
        <enumeration value="application"/>
        <enumeration value="registration"/>
    </restriction>
  </simpleType>
  
  
  <!-- 
  Child elements of the create notice element. 
  -->
  <complexType name="createNoticeType">
    <sequence>
      <element name="noticeID" type="launch:noticeIDType"/>
      <element name="notAfter" type="dateTime"/>
      <element name="acceptedDate" type="dateTime"/>
    </sequence>
  </complexType>


  <!-- 
  Child elements of check (Claims Check Command).  
  -->
  <complexType name="checkType">
    <sequence>
      <element name="phase" type="launch:phaseType"/>
    </sequence>
    <attribute name="type" type="launch:checkFormType" 
    default="claims"/>
  </complexType>


  <!--
  Type of check form 
  (claims check or availability check)
  -->
  <simpleType name="checkFormType">
      <restriction base="token">
        <enumeration value="claims"/>
        <enumeration value="avail"/>
    </restriction>
  </simpleType>


  <!-- 
  Child elements of info command.  
  -->
  <complexType name="infoType">
    <sequence>
      <element name="phase" type="launch:phaseType"/>
      <element name="applicationID" 
        type="launch:applicationIDType" 
        minOccurs="0"/>
    </sequence>
    <attribute name="includeMark" type="boolean" 
      default="false"/>
  </complexType>

  <!-- 
  Child response elements.  
  -->
  <element name="chkData" type="launch:chkDataType"/>    
  <element name="creData" type="launch:idContainerType"/>
  <element name="infData" type="launch:infDataType"/>
  
  <!--
   <check> response elements.
   -->
  <complexType name="chkDataType">
    <sequence>
      <element name="phase" type="launch:phaseType"/>
      <element name="cd" type="launch:cdType"
       maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="cdType">
    <sequence>
      <element name="name" type="launch:cdNameType"/>
      <element name="claimKey" type="launch:claimKeyType"
       minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="cdNameType">
    <simpleContent>
      <extension base="eppcom:labelType">
        <attribute name="exists" type="boolean"
         use="required"/>
      </extension>
    </simpleContent>
  </complexType>
  
  <complexType name="claimKeyType">
    <simpleContent>
      <extension base="token">
        <attribute name="validatorID"
         type="launch:validatorIDType" use="optional"/>
      </extension>
    </simpleContent>
  </complexType>
  
  <!--
  <info> response elements
  -->
  <complexType name="infDataType">
    <sequence>
      <element name="phase" type="launch:phaseType"/>
     <element name="applicationID" 
      type="launch:applicationIDType" 
      minOccurs="0"/>
     <element name="status" type="launch:statusType" 
      minOccurs="0"/>
      <element ref="mark:abstractMark"
      minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
  </complexType>
    
</schema>
END]]></artwork>
      </figure>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors wish to acknowledge the efforts of the leading 
      participants of the Community TMCH Model that led to many of the 
      changes to this document, which include Chris Wright, Jeff Neuman, 
      Jeff Eckhaus, and Will Shorter.</t>
      <t>Special suggestions that have been incorporated into this document 
      were provided by Jothan Frakes, Keith Gaughan, Seth Goldman, Jan Jansen, Rubens Kuhl, Ben Levac, Gustavo Lozano,
      Klaus Malorny, Alexander Mayrhofer, Patrick Mevzek, James Mitchell, Francisco Obispo, Mike O'Connell, Bernhard Reutner-Fischer, Trung Tran,  
      Ulrich Wisser and Sharon Wodjenski.</t>
    </section>
    
   <section title="Change History">
    <section title="Change from 00 to 01" anchor="change-00-to-01">
      <t><list style="numbers">
        <t>Changed to use camel case for the XML elements.</t>
        <t>Replaced "cancelled" status to "rejected" status.</t>
        <t>Added the child elements of the &lt;claim&gt; element.</t>
        <t>Removed the XML schema and replaced with "[TBD]".</t>
      </list></t>
    </section>
    <section title="Change from 01 to 02" anchor="change-01-to-02">
      <t><list style="numbers">
        <t>Added support for both the ICANN and ARI/Neustar TMCH models.</t>
        <t>Changed the namespace URI and prefix to use "launch" instead of "launchphase".</t>
        <t>Added definition of multiple claim validation models.</t>
        <t>Added the &lt;launch:signedClaim&gt; and &lt;launch:signedNotice&gt; elements.</t>
        <t>Added support for Claims Info Command</t>
      </list></t>
    </section>
    <section title="Change from 02 to 03" anchor="change-02-to-03">
      <t><list style="numbers">
        <t>Removed XSI namespace per Keith Gaughan's suggestion on the provreg list.</t>
        <t>Added extensibility to the launch:status element and added the 
        pendingAuction status per Trung Tran's feedback on the provreg list.</t>
        <t>Added support for the Claims Check Command, updated the location and 
        contents of the signedNotice, and replaced most references of Claim to Mark 
        based on the work being done on the ARI/Neustar launch model.</t>
      </list></t>
    </section>
    <section title="Change from 03 to 04" anchor="change-03-to-04">
      <t><list style="numbers">
        <t>Removed references to the ICANN model.</t>
        <t>Removed support for the Claims Info Command.</t>
        <t>Removed use of the signedClaim.</t>
        <t>Revised the method for referring to the signedClaim from the XML Signature using the IDREF URI.</t>
        <t>Split the launch-1.0.xsd into three XML schemas including launch-1.0.xsd, signeMark-1.0.xsd, and mark-1.0.xsd.</t>
        <t>Split the "claims" launch phase to the "claims1" and "claims2" launch phases.</t>
        <t>Added support for the encodedSignedMark with base64 encoded signedMark.</t>
        <t>Changed the elements in the createNoticeType to include the noticeID, timestamp, and the source elements.</t>
        <t>Added the class and effectiveDate elements to mark.</t>
      </list></t>
    </section>
    <section title="Change from 04 to 05" anchor="change-04-to-05">
      <t><list style="numbers">
        <t>Removed reference to &lt;smd:zone&gt; in the &lt;smd:signedMark&gt; example.</t>
        <t>Incorporated feedback from Bernhard Reutner-Fischer on the provreg mail list.</t>
        <t>Added missing launch XML prefix to applicationIDType reference in the idContainerType of the Launch Schema.</t>
        <t>Added missing description of the &lt;mark:pc&gt; element in the &lt;mark:addr&gt; element.</t>
        <t>Updated note on replication of the EPP contact mapping elements in the Mark Contact section.</t>
      </list></t>
    </section>
    <section title="Change from 05 to 06" anchor="change-05-to-06">
      <t><list style="numbers">
        <t>Removed the definition of the mark-1.0 and signedMark-1.0 and replaced with reference to draft-lozano-smd, that contains the definition for the mark, signed marked, and encoded signed mark.</t>
        <t>Split the &lt;launch:timestamp&gt; into &lt;launch:generatedDate&gt; and &lt;launch:acceptedDate&gt; based on feedback from Trung Tran.</t>
        <t>Added the "includeMark" optional attribute to the &lt;launch:info&gt; element to enable the client to request whether or not to include the mark in the info response.</t>
        <t>Fixed state diagram to remove redundant transition from "invalid" to "rejected"; thanks Klaus Malorny.</t>
      </list></t>
    </section>
    <section title="Change from 06 to 07" anchor="change-06-to-07">
      <t><list style="numbers">
        <t>Proof-read grammar and spelling.</t>
        <t>Changed "pendingAuction" status to "pendingAllocation", changed "pending" to "pendingValidation" status, per proposal from Trung Tran and seconded by Rubens Kuhl.</t>
        <t>Added text related to the use of RFC 5731 pendingCreate to the Application Identifier section.</t>
        <t>Added the Poll Messaging section to define the use of poll messaging for intermediate state transitions and pending action poll messaging for final state transitions.</t>
      </list></t>
    </section>
    <section title="Change from 07 to 08" anchor="change-07-to-08">
      <t><list style="numbers">
        <t>Added support for use of the launch statuses and poll messaging for Launch Registrations based on feedback from Sharon Wodjenski and Trung Tran.</t>
        <t>Incorporated changes based on updates or clarifications in draft-lozano-tmch-func-spec-01, which include:
        	<list>
        		<t>Removed the unused &lt;launch:generatedDate&gt; element.</t>
        		<t>Removed the &lt;launch:source&gt; element.</t>
        		<t>Added the &lt;launch:notAfter&gt; element based on the required &lt;tmNotice:notAfter&gt; element.</t>
        	</list>
        </t>
      </list></t>
    </section>
    <section title="Change from 08 to 09" anchor="change-08-to-09">
      <t><list style="numbers">
        <t>Made &lt;choice&gt; element optional in &lt;launch:create&gt; to allow passing just the &lt;launch:phase&gt; in &lt;launch:create&gt; per request from Ben Levac.</t>
        <t>Added optional "type" attribute in &lt;launch:create&gt; to enable the client to explicitly define the desired type of object (application or registration) to create to all forms of the create extension.</t>
        <t>Added text that the server SHOULD validate the &lt;launch:phase&gt; element in the Launch Phases section.</t>
        <t>Add the "General Create Form" to the create command extension to support the request from Ben Levac.</t>
        <t>Updated the text for the Poll Messaging section based on feedback from Klaus Malorny.</t>
        <t>Replaced the "claims1" and "claims2" phases with the "claims" phase based on discussion on the provreg list.</t>
        <t>Added support for a mixed create model (Sunrise Create Model and Claims Create Model), where a trademark (encoded signed mark, etc.) and notice can be passed, based on a request from James Mitchell.</t>
        <t>Added text for the handling of the overlapping "claims" and "landrush" launch phases.</t>
        <t>Added support for two check forms (claims check form and availability check form) based on a request from James Mitchell.  The availability check form was based on the text in draft-rbp-application-epp-mapping.</t>
      </list></t>
    </section>
    <section title="Change from 09 to 10" anchor="change-09-to-10">
      <t><list style="numbers">
        <t>Changed noticeIDType from base64Binary to token to be compatible with draft-lozano-tmch-func-spec-05.</t>
        <t>Changed codeType from base64Binary to token to be more generic.</t>
        <t>Updated based on feedback from Alexander Mayrhofer, which include:
          <list>
             <t>Changed "extension to the domain name extension" to "extension to the domain name mapping".</t>
             <t>Changed use of 2004 return code to 2306 return code when phase passed mismatches active phase and sub-phase.</t>
             <t>Changed description of "allocated" and "rejected" statuses.</t>
             <t>Moved sentence on a synchronous &lt;domain:create&gt; command without the use of an intermediate application, then an Application Identifier MAY not be needed to the Application Identifier section.</t>    
             <t>Restructured the Mark Validation Models section to include the "&lt;launch:codeMark&gt; element" sub-section, the "&lt;mark:mark&gt; element" sub-section, and the Digital Signature sub-section.</t> 
             <t>Changed "Registries may" to "Registries MAY".</t>
             <t>Changed "extensed" to "extended" in "Availability Check Form" section.</t>
             <t>Broke the mix of create forms in the "EPP &lt;create&gt; Command" section to a fourth "Mixed Create Form" with its own sub-section.</t>
             <t>Removed "displayed or" from "displayed or accepted" in the &lt;launch:acceptedDate&gt; description.</t>
             <t>Replaced "given domain name is supported" with "given domain name are supported" in the "Create Response" section.</t>
             <t>Changed the reference of 2303 (object does not exist) in the "Security Considerations" section to 2201 (authorization error).</t>
             <t>Added arrow from "invalid" status to "pendingValidation" status and "pendingAllocation" status to "rejected" status in the State Transition Diagram.</t>  
          </list>
        </t>
        <t>Added the "C:" and "S:" example prefixes and related text in the "Conventions Used in This Document" section.</t> 
      </list></t>
    </section>
    <section title="Change from 10 to 11" anchor="change-10-to-11">
      <t><list style="numbers">
        <t>Moved the claims check response &lt;launch:chkData&gt; element under the &lt;extension&gt; element instead of the &lt;resData&gt; element based on the request from Francisco Obispo.</t>
      </list></t>
    </section>
    <section title="Change from 11 to 12" anchor="change-11-to-12">
      <t><list style="numbers">
          <t>Added support for multiple validator identifiers for claims notices and marks based on a request and 
          text provided by Mike O'Connell.</t>  
          <t>Removed domain:exDate element from example in section 3.3.5 based on a request from Seth Goldman on the provreg list.</t> 
          <t>Added clarifying text for clients not passing the launch extension on update and delete commands 
          to servers that do not support launch applications based on a request from Sharon Wodjenski on the provreg list.</t>
      </list></t>
    </section>
    <section title="Change from 12 to WG 00" anchor="change-12-to-wg00">
      <t><list style="numbers">
          <t>Changed to eppext working group draft by changing draft-tan-epp-launchphase to 
          draft-ietf-eppext-launchphase and by changing references of draft-lozano-tmch-smd 
          to draft-ietf-eppext-tmch-smd.</t>
      </list></t>
    </section>
   </section>
    

    <section anchor="IANA" title="IANA Considerations">
         <t>
             This document uses URNs to describe XML namespaces and XML schemas
             conforming to a registry mechanism described in <xref target="RFC3688"/>.
             One URI assignment has been registered by the IANA.
         </t>

         <t>Registration request for the Launch namespace:</t>
         <t>
             <list>
                 <t>URI: urn:ietf:params:xml:ns:launch-1.0</t>
                 <t>Registrant Contact: See the &quot;Author&apos;s Address&quot; section of this document.</t>
                 <t>XML: None.  Namespace URIs do not represent an XML specification.</t>
             </list>
         </t> 
 
    </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>, the <xref target="RFC5731">EPP domain name
      mapping</xref>, and protocol layers used by EPP. The security
      considerations described in these other specifications apply to this
      specification as well.</t>

      <t>Updates to, and deletion of an application object must be restricted
      to clients authorized to perform the said operation on the object.</t>

      <t>As information contained within an application, or even the mere fact
      that an application exists may be confidential. Any attempt to operate
      on an application object by an unauthorized client MUST be rejected with
      an EPP 2201 (authorization error) return code. Server policy may allow &lt;info&gt; operation with filtered
      output by clients other than the sponsoring client, in which case the
      &lt;domain:infData&gt; and &lt;launch:infData&gt; response SHOULD be
      filtered to include only fields that are publicly accessible.</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">
    
      <reference anchor="draft-ietf-eppext-tmch-smd">
        <front>
          <title abbrev='Mark and Signed Mark Objects Mapping'>Mark and Signed Mark Objects Mapping</title>
          <author fullname="Gustavo Lozano" initials="G.L." surname="Lozano"/>
        </front>
        <format type='HTML' target='http://tools.ietf.org/html/draft-ietf-eppext-tmch-smd' />
      </reference>    
    
    
      &RFC2119;

      &RFC5730;

      &RFC5731;

      &RFC3688;


    </references>
  </back>

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