<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!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 RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC5730 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5730.xml">
<!ENTITY RFC5733 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5733.xml">
<!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.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-regext-validate-04" 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>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Validate">
    Validate Mapping for the Extensible Provisioning Protocol (EPP)</title>

    <author fullname="Roger Carney" initials="R.C." surname="Carney">
      <organization>GoDaddy Inc.</organization>

      <address>
        <postal>
          <street>14455 N. Hayden Rd. #219</street>

          <city>Scottsdale</city>

          <region>AZ</region>

          <code>85260</code>

          <country>US</country>
        </postal>

        <email>rcarney@godaddy.com</email>

        <uri>http://www.godaddy.com</uri>
      </address>
    </author>

    <author fullname="Joseph Snitker" initials="J.S." surname="Snitker">
      <organization>GoDaddy Inc.</organization>

      <address>
        <postal>
          <street>14455 N. Hayden Rd. #219</street>

          <city>Scottsdale</city>

          <region>AZ</region>

          <code>85260</code>

          <country>US</country>
        </postal>

        <email>jsnitker@godaddy.com</email>

        <uri>http://www.godaddy.com</uri>
      </address>
    </author>

    <date year="2018"/>

    <!-- Meta-data Declarations -->

    <area>Applications and Real-Time</area>

    <workgroup>Registration Protocols Extensions</workgroup>

    <abstract>
      <t>This document describes an Extensible Provisioning Protocol (EPP)
      mapping for the validation of contact and eligibility data.</t>
    </abstract>
    
  </front>

  <middle>
    <section title="Introduction">
      <t>This document describes a Validate mapping for version 1.0 of the
      <xref target="RFC5730">Extensible Provisioning Protocol (EPP)</xref>.
      This EPP mapping specifies a flexible schema by which EPP clients and
      servers can reliably validate contact and eligibility data.</t>

      <t>With the increased number of restrictions on contacts and required data
      points (license, ids, etc.) to register a domain name, a way to validate
      the data points prior to issuing a transform command is becoming more
      important.</t>

      <section title="Conventions Used in This Document">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP 14
        <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
        they appear in all capitals, as shown here.</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>"validate" is used as an abbreviation for
        "urn:ietf:params:xml:ns:validate-0.2".  The XML namespace prefix
        "validate" 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>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>(Note to RFC Editor: remove the following paragraph before
        publication as an RFC.)</t>
        
        <t>The XML namespace prefix above contains a version number,
        specifically "0.2".  This version number will increment with successive
        versions of this document, and will reach 1.0 if and when this document
        is published as an RFC.  This permits clients to distinguish which
        version of the extension a server has implemented.</t>
      </section>
    </section>

    <section title="Object Attributes">
      <t>A EPP validation object has attributes and associated values that can
      be viewed by the client. This section describes each attribute type in
      detail.</t>

      <section title="Key Value">
        <t>Key Value provides a flexible mechanism to share data between the client
        and the server. The &lt;validate:kv&gt; element defines the data, with two
        required simple attributes, key and value, and an optional contactType
        attribute for specificity in the response, more details below.</t>

        <t><list style="symbols">
          <t>An example &lt;validate:kv key="VATID" value="0123456789"/&gt;.</t>
          <t>An example &lt;validate:kv contactType="Admin" key="contact:cc"
          value="Invalid country code for admin contact, must be MX."/&gt;.</t>
        </list></t>

      </section>

      <section title="Validate Id">
        <t>The &lt;validate:id&gt; element is used in two different scenarios.</t>
        <t>First if the &lt;validate:id&gt; is passed by itself with no other 
          elements (e.g. &gt;validate:postalInfo&gt;) then the client intent is 
          that this is an already existing contact and the server should handle 
          the request by looking up the associated data in its system and using 
          that data to validate against.</t>
        <t>Second scenario would be if the request includes additional elements 
          then the server should treat the &lt;validate:id&gt; as a temporary 
          contact handle and should not perform a look on the contact but use the 
          data that is passed in the request to validate against.</t>
        
      </section>
      
      <section title="Validate PostalInfo, Voice, Fax, Email, AuthInfo">
        <t>These elements are intended to mirror the definitions in [RFC5733].</t>
        
      </section>
      
    </section>

    <section title="EPP Command Mapping">
      <t>A detailed description of the EPP syntax and semantics can be found in
      <xref target="RFC5730"/>. The command mappings described
      here are specifically for the Validate Extension.</t>

      <section title="EPP Query Commands">
        <t>EPP provides three commands to retrieve object information: &lt;check&gt;
        to determine if an object is known to the server, &lt;info&gt; to retrieve
        detailed information associated with an object, and &lt;transfer&gt;
        to retrieve object transfer status information.</t>
      
        <section title="EPP &lt;check&gt; Command">
          <t>The EPP &lt;check&gt; command is used to validate a list of contact
          information.  The &lt;check&gt; command MUST contain a &lt;validate:check&gt;
          element that identifies the validate namespace.  The &lt;validate:check&gt;
          element contains the following child elements:</t>

          <t><list style="symbols">
            <t>one or more &lt;validate:contact&gt; element(s) for each contact
            that is to be validated that contains the contact type of the contact
            to be validated.</t>
          </list></t>

          <t>The &lt;validate:contact&gt; element has two required attributes:
          contactType, which describes the role (registrant, admin, tech,
          billing, etc.) of the contact that the contact should be validated
          for; and tld, which provides the top level domain to be validated
          against. The &lt;validate:contact&gt; element contains the
          following child elements:</t>
          
          <t><list style="symbols">
            <t>one &lt;validate:id&gt; element (as described in section 2.2).</t>
            <t>an OPTIONAL &lt;validate:postalInfo&gt; element (as described in section 2.3).</t>
            <t>an OPTIONAL &lt;validate:voice&gt; element (as described in section 2.3).</t>
            <t>an OPTIONAL &lt;validate:fax&gt; element (as described in section 2.3).</t>
            <t>an OPTIONAL &lt;validate:email&gt; element (as described in section 2.3).</t>
            <t>an OPTIONAL &lt;validate:authInfo&gt; element (as described in section 2.3).</t>
            <t>zero or more &lt;validate:kv&gt; elements (as described in section 2.1).</t>
          </list></t>

          <figure>
            <preamble>The following is an example &lt;check&gt; command where 
            "sh8013" and "sh8014" are both "new" contacts and "sh8012" is an 
            existing contact on the server.</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:  xmlns:validate="urn:ietf:params:xml:ns:validate-0.2"
C:  xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C:  <command>
C:    <check>
C:      <validate:check>
C:        <validate:contact contactType="registrant" tld="COM">
C:          <validate:id>sh8013</validate:id>
C:          <validate:postalInfo type="int">
C:            <contact:name>John Doe</contact:name>
C:            <contact:org>Example Inc.</contact:org>
C:            <contact:addr>
C:              <contact:street>123 Example Dr.</contact:street>
C:              <contact:street>Suite 100</contact:street>
C:              <contact:city>Dulles</contact:city>
C:              <contact:sp>VA</contact:sp>
C:              <contact:pc>20166-6503</contact:pc>
C:              <contact:cc>US</contact:cc>
C:            </contact:addr>
C:          </validate:postalInfo>
C:          <validate:voice>+1.7035555555</validate:voice>
C:          <validate:fax>+1.7035555556</validate:fax>
C:          <validate:email>jdoe@example.com</validate:email>
C:          <validate:authInfo>
C:            <contact:pw>2fooBAR</contact:pw>
C:          </validate:authInfo>
C:          <validate:kv key="VAT" value="1234567890"/>
C:        </validate:contact>
C:        <validate:contact contactType="tech" tld="COM">
C:          <validate:id>sh8012</validate:id>
C:        </validate:contact>
C:        <validate:contact contactType="admin" tld="COM">
C:          <validate:id>sh8014</validate:id>
C:          <validate:postalInfo type="int">
C:            <contact:name>John Doe</contact:name>
C:            <contact:org>Example Inc.</contact:org>
C:            <contact:addr>
C:              <contact:street>123 Example Dr.</contact:street>
C:              <contact:street>Suite 100</contact:street>
C:              <contact:city>Dulles</contact:city>
C:              <contact:sp>VA</contact:sp>
C:              <contact:pc>20166-6503</contact:pc>
C:              <contact:cc>US</contact:cc>
C:            </contact:addr>
C:          </validate:postalInfo>
C:          <validate:voice>+1.7035555555</validate:voice>
C:          <validate:fax>+1.7035555556</validate:fax>
C:          <validate:email>jdoe@example.com</validate:email>
C:          <validate:authInfo>
C:            <contact:pw>2fooBAR</contact:pw>
C:          </validate:authInfo>
C:        </validate:contact>
C:        <validate:contact contactType="billing" tld="COM">
C:          <validate:id>sh8014</validate:id>
C:          <validate:postalInfo type="int">
C:            <contact:name>John Doe</contact:name>
C:            <contact:org>Example Inc.</contact:org>
C:            <contact:addr>
C:              <contact:street>123 Example Dr.</contact:street>
C:              <contact:street>Suite 100</contact:street>
C:              <contact:city>Dulles</contact:city>
C:              <contact:sp>VA</contact:sp>
C:              <contact:pc>20166-6503</contact:pc>
C:              <contact:cc>US</contact:cc>
C:            </contact:addr>
C:          </validate:postalInfo>
C:          <validate:voice>+1.7035555555</validate:voice>
C:          <validate:fax>+1.7035555556</validate:fax>
C:          <validate:email>jdoe@example.com</validate:email>
C:          <validate:authInfo>
C:            <contact:pw>2fooBAR</contact:pw>
C:          </validate:authInfo>
C:        </validate:contact>
C:      </validate:check>
C:    </check>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>]]>
            </artwork>
          </figure>

          <t>When the server receives a &lt;check&gt; command with a
          &lt;validate:contact&gt; element that contains only a &lt;validate:id&gt;
          element the server will process this as an existing contact. If the
          contact does not exist the server MUST return an EPP error response
          for that specific &lt;validate:contact&gt;.</t>
          
          <t>When a &lt;check&gt; command has been processed succesfully, the
          EPP &lt;resData&gt; element MUST contain a child &lt;validate:chkData&gt;
          element that identifies the validate namespace. The &lt;validate:chkData&gt;
          element MUST contain a &lt;validate:cd&gt; element for each &lt;validate:check&gt;
          element contained in the &lt;check&gt; command. The &lt;validate:cd&gt;
          element contains the following child elements:</t>

          <t><list style="symbols">
            <t>one &lt;validate:id&gt; element.</t>
            <t>one &lt;validate:response&gt; element.</t>
            <t>zero or more &lt;validate:kv&gt; elements.</t>
          </list></t>

          <figure>
            <preamble>The following is an example of the &lt;check&gt; response.</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:      <validate:chkData
S:        xmlns:validate="urn:ietf:params:xml:ns:validate-0.2">
S:        <validate:cd>
S:          <validate:id>sh8013</validate:id>
S:          <validate:response>1000</validate:response>
S:        </validate:cd>
S:        <validate:cd>
S:          <validate:id>sh8014</validate:id>
S:          <validate:response>2306</validate:response>
S:          <validate:kv key="contact:city" value="City not valid
S:            for state."/>
S:          <validate:kv contactType="Admin" key="contact:cc"
S:            value="Invalid country code for admin, must be mx."/>
S:          <validate:kv contactType="Billing" key="VAT" value="VAT
S:            required for Billing contact."/>
S:        </validate:cd>
S:      </validate:chkData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-ZYX</svTRID>
S:    </trID>
S:  </response>
S:</epp>]]>
            </artwork>
          </figure>

        </section>

        <section title="EPP &lt;info&gt; Command">
          <t>Info semantics do not apply to validate objects, so there is no
          mapping defined for the EPP &lt;info&gt; command.</t>
          
        </section>

        <section title="EPP &lt;transfer&gt; Command">
          <t>Transfer semantics do not apply to validate objects, so there is no
          mapping defined for the EPP &lt;transfer&gt; command.</t>

        </section>
        
      </section>

      <section title="EPP Transform Commands">
        <t>EPP provides five commands to transform objects: &lt;create&gt; to
        create an instance of an object with a server, &lt;delete&gt; to remove
        an instance of an object from a server, &lt;renew&gt; to extend the
        validity period of an object, &lt;transfer&gt; to manage changes in
        client sponsorship of an object, and &lt;update&gt; to change information.</t>

        <section title="EPP &lt;create&gt; Command">
          <t>Create semantics do not apply to validate objects, so there is no
          mapping defined for the EPP &lt;create&gt; command.</t>

        </section>

        <section title="EPP &lt;delete&gt; Command">
          <t>Delete semantics do not apply to validate objects, so there is no
          mapping defined for the EPP &lt;delete&gt; command.</t>

        </section>

        <section title="EPP &lt;renew&gt; Command">
          <t>Renew semantics do not apply to validate objects, so there is no
          mapping defined for the EPP &lt;renew&gt; command.</t>

        </section>

        <section title="EPP &lt;transfer&gt; Command">
          <t>Transfer semantics do not apply to validate objects, so there is no
          mapping defined for the EPP &lt;transfer&gt; command.</t>

        </section>

        <section title="EPP &lt;update&gt; Command">
          <t>Update semantics do not apply to validate objects, so there is no
          mapping defined for the EPP &lt;update&gt; command.</t>

        </section>

      </section>
      
    </section>

    <section anchor="syntax" title="Formal Syntax">

      <t>One schema is presented here that is the EPP Validate 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="Validate Schema">

        <t>Copyright (c) 2018 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:validate-0.2"
   xmlns:validate="urn:ietf:params:xml:ns:validate-0.2"
   xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
   xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
   xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
   xmlns="http://www.w3.org/2001/XMLSchema"
   elementFormDefault="qualified">

   <annotation>
     <documentation>
       Extensible Provisioning Protocol v1.0
       Validate Object
     </documentation>
   </annotation>

   <!-- 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:epp-1.0"
     schemaLocation="epp-1.0.xsd"/>
   <import namespace="urn:ietf:params:xml:ns:contact-1.0"
     schemaLocation="contact-1.0.xsd"/>

<!--
Child elements of the <check> command.
-->
   <element name="check" type="validate:checkType"/>

   <complexType name="checkType">
     <sequence>
       <element name="contact"
         type="validate:validateContactType"
         maxOccurs="unbounded" />
     </sequence>
   </complexType>

   <complexType name="validateContactType">
     <sequence>
       <element name="id"
         type="eppcom:clIDType" />
       <element name="postalInfo"
         type="contact:postalInfoType"
         minOccurs="0" maxOccurs="2" />
       <element name="voice"
         type="contact:e164Type" minOccurs="0" />
       <element name="fax"
         type="contact:e164Type" minOccurs="0" />
       <element name="email"
         type="eppcom:minTokenType" minOccurs="0"/>
       <element name="authInfo"
         type="contact:authInfoType"
         minOccurs="0"/>
       <element name="kv"
         type="validate:kvType" minOccurs="0"
         maxOccurs="unbounded" />
     </sequence>
     <attribute name="contactType" type="eppcom:labelType"
       use="required"/>
     <attribute name="tld"
       type="eppcom:labelType" use="required"/>
   </complexType>

   <complexType name="kvType">
     <attribute name="contactType"
       type="eppcom:labelType" use="optional" />
     <attribute name="key"
       type="validate:keyType" use="required" />
    <attribute name="value"
       type="validate:valueType" use="required" />
   </complexType>

   <simpleType name="keyType">
     <restriction base="token">
       <minLength value="1" />
     </restriction>
   </simpleType>

   <simpleType name="valueType">
     <restriction base="token">
       <minLength value="0" />
     </restriction>
   </simpleType>

<!--
Child elements of the <check> response.
-->
   <element name="chkData" type="validate:chkDataType" />

   <complexType name="chkDataType">
     <sequence>
       <element name="cd"
         type="validate:resCreateDataType" maxOccurs="unbounded" />
     </sequence>
   </complexType>

   <complexType name="resCreateDataType">
     <sequence>
       <element name="id"
         type="eppcom:clIDType" />
       <element name="response"
         type="epp:resultCodeType" />
       <element name="kv"
         type="validate:kvType"
         minOccurs="0" maxOccurs="unbounded" />
     </sequence>
   </complexType>

</schema>
END]]>
          </artwork>
        </figure>
      </section>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The mapping described in this document do not provide any
      security services beyond those described by <xref target="RFC5730">EPP</xref>
      and protocol layers used by EPP. The security considerations described in
      these other specifications apply to this specification as well.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">

    	<section title="XML Namespace">
          <t>This document uses URNs to describe XML namespaces and XML schemas
             conforming to a registry mechanism described in <xref target="RFC3688"/>.</t>

          <t>Registration request for the validate namespace:</t>

          <t>URI: urn:ietf:params:xml:ns:validate-1.0</t>
          <t>Registrant Contact: IESG</t>
          <t>XML: None. Namespace URIs do not represent an XML specification.</t>

    	  <t>Registration request for the validate schema:</t>

    	  <t>URI: urn:ietf:params:xml:schema:validate-1.0</t>
    	  <t>Registrant Contact: IESG</t>
    	  <t>XML: See the "Formal Syntax" section of this document.</t>

       </section>

    </section>

    <section title="Implemntation Status">
      <t>Note to RFC Editor: Please remove this section and the reference to
      [RFC7942] before publication.</t>

      <t>This section records the status of known implementations of the
      protocol defined by this specification at the time of posting of this
      Internet-Draft, and is based on a proposal described in [RFC7942]. The
      description of implementations in this section is intended to assist the
      IETF in its decision processes in progressing drafts to RFCs.  Please note
      that the listing of any individual implementation here does not imply
      endorsement by the IETF.  Furthermore, no effort has been spent to verify
      the information presented here that was supplied by IETF contributors.
      This is not intended as, and must not be construed to be, a catalog of
      available implementations or their features.  Readers are advised to note
      that other implementations may exist.</t>

      <t>According to [RFC7942], "this will allow reviewers and working groups
      to assign due consideration to documents that have the benefit of running
      code, which may serve as evidence of valuable experimentation and feedback
      that have made the implemented protocols more mature. It is up to the
      individual working groups to use this information as they see fit".</t>

      <section title="To Be Filled In">
        <t>Add implementation details once available.</t>
      </section>

    </section>

    <section title="Acknowledgements">
      <t>The authors wish to thank the following persons for their feedback and
      suggestions:</t>
      <t><list style="symbols">
        <t>Kevin Allendorf of GoDaddy Inc.</t>
        <t>Jody Kolker of GoDaddy Inc.</t>
        <t>James Gould of Verisign Inc</t>
      </list></t>
    </section>

    <section title="Change History">
    
      <section title="Change from 03 to 04">
        <t>Removed the &lt;validate:cd&gt; element from the &lt;check&gt;
        command, moving all sub-elements to the &lt;validate:contact&gt; element
        to simplify. Also removed the &lt;disclose&gt; element as it was not
        needed in this context. Also updated references to current versions of
        documents.</t>
      </section>

      <section title="Change from 02 to 03">
        <t>Corrected some formatting issues.</t>
      </section>

      <section title="Change from 01 to 02">
        <t>Corrected some formatting issues.</t>
      </section>

      <section title="Change from 00 to 01">
        <t>After review and broad feedback, extensive changes have been made
        transforming the original document from a standalone extension command to
        using the &lt;check&gt; command and response framework.
        Stubbed in an Implementation section for later documentation.</t>
      </section>
      
      <section title="Change from carney-regext 01 to ietf-regext 00">
        <t>Updated miscellaneous verbiage to reflect the change from an
        extension and changed to ietf naming as REGEXT WG will assume this work.</t>
      </section>

    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">

      &RFC2119;

      &RFC3688;

      &RFC5730;
      
      &RFC5733;
      
      &RFC7942;

      &RFC8174;

    </references>

  </back>
</rfc>
























