<?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 RFC2045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml">
<!ENTITY RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.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 RFC5732 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5732.xml">
<!ENTITY RFC5733 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5733.xml">
<!ENTITY RFC5910 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5910.xml">
<!ENTITY RFC7451 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7451.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY W3C.xmldsig PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml4/reference.W3C.CR-xmldsig-core2-20120124.xml'>
<!ENTITY I-D.draft-gould-eppext-verificationcode PUBLIC ''
   'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.gould-eppext-verificationcode.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-gould-regext-dataset-02" 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="Data Set File Format">
     Data Set File Format</title>

    <author fullname="James Gould" initials="J.G" surname="Gould">
      <organization>VeriSign, Inc.</organization>

      <address>
        <postal>
          <street>12061 Bluemont Way</street>

          <city>Reston</city>

          <region>VA</region>

          <code>20190</code>

          <country>US</country>
        </postal>

        <email>jgould@verisign.com</email>

        <uri>http://www.verisign.com</uri>
      </address>
    </author>


    <date day="5" month="September" year="2018"/>

    <abstract>
      <t>
      This document defines a Data Set File (DSF) format 
      that can be used to define and pass bulk data between a client and 
      a server.  This format is extensible to pass any set of simple 
      data types in a set of records contained in the body of the file.  
      The file format also supports storing the result of processing the 
      data set that MAY be generated by the server and returned to the client.  
      The file format consists of an XML definition header and a 
      Comma-Separated Values (CSV) data section delimited by 
      "-----BEGIN DATA SET-----" and "-----END DATA SET-----" lines.  
      The XML definition header defines the format of the CSV data section,  
      contains additional meta-data, and optionally 
      includes a digital signature to identify the source and ensure that the 
      data has not been tampered with between the parties (source, client, and server).
      The interface (manual or automated) that is used 
      to submit the file and receive the result file is not defined within 
      this document.
      </t>
    </abstract>
           
  </front>

  <middle>
    <section title="Introduction">
       <t>
      This document defines a Data Set File (DSF) format 
      that can be used to define and pass bulk data between a client and 
      a server.  The client and server MAY leverage a provisioning protocol like EPP, as defined in <xref target="RFC5730"/>, 
      to provision individual objects, but the provisioning protocol MAY NOT handle all provisioning use 
      cases.  This document defines a format for bulk provisioning requests that can be generated 
      by authorized third parties, can be generated by clients that choose not to leverage the provisioning protocol, 
      and can be supported by servers to process bulk requests in a controlled manner that throttles the 
      processing against the provisioning database.  Bulk requests can include court orders, out-of-band client requests to fix 
      data, the backfill of data like contact or verification code data, and a large set of ad-hoc needs.</t>
      <t>
      This format is extensible to pass any set of simple 
      data types in a set of records contained in the body of the file.  
      The file format also supports storing the result of processing the 
      data set that MAY be generated by the server and returned to the client.  
      The file format consists of an XML definition header and a 
      Comma-Separated Values (CSV) data section delimited by 
      "-----BEGIN DATA SET-----" and "-----END DATA SET-----" lines.  
      The XML definition header defines the format of the CSV data section,  
      contains additional meta-data, and optionally 
      includes a digital signature to identify the source and ensure that the 
      data has not been tampered with between the parties (source, client, and server) 
      using <xref target="W3C.CR-xmldsig-core2-20120124">XML Signature</xref>.
      All <xref target="W3C.CR-xmldsig-core2-20120124">XML Signature</xref> data 
      is "base64" encoded, in conformance with <xref target="RFC2045"/>, by default to 
      mitigate any validation errors due 
      to whitespace formatting.
      The interface (manual or automated) that is used to submit the file and receive the result file 
      is not defined within this document and must be documented independently. 
      Please see <xref target="Security"/> for a description of the issues associated with 
      transport security.
      </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>The following XML abbreviations are used:</t>
        <t><list>
          <t>"eppcom" XML namespace prefix refers to 
          "urn:ietf:params:xml:ns:eppcom-1.0" XML namespace in <xref target="RFC5730"/>.</t>
          <t>"domain" XML namespace prefix refers to 
          "urn:ietf:params:xml:ns:domain-1.0" XML namespace in <xref target="RFC5731"/>.</t>
          <t>"host" XML namespace prefix refers to 
          "urn:ietf:params:xml:ns:host-1.0" XML namespace in <xref target="RFC5732"/>.</t>
          <t>"contact" XML namespace prefix refers to 
          "urn:ietf:params:xml:ns:contact-1.0" XML namespace in <xref target="RFC5733"/>.</t>
          <t>"dataSet-1.0" is used as an abbreviation for
          "urn:ietf:params:xml:ns:dataSet-1.0".</t>
          <t>"dataSet" XML namespace prefix refers to 
          "urn:ietf:params:xml:ns:dataSet-1.0" XML namespace.</t>
          <t>"dsfDomain-1.0" is used as an abbreviation for
          "urn:ietf:params:xml:ns:dsfDomain-1.0".</t>
          <t>"dsfDomain" XML namespace prefix refers to 
          "urn:ietf:params:xml:ns:dsfDomain-1.0" XML namespace.</t>
          <t>"dsfHost-1.0" is used as an abbreviation for
          "urn:ietf:params:xml:ns:dsfHost-1.0".</t>
          <t>"dsfHost" XML namespace prefix refers to 
          "urn:ietf:params:xml:ns:dsfHost-1.0" XML namespace.</t>
          <t>"dsfContact-1.0" is used as an abbreviation for
          "urn:ietf:params:xml:ns:dsfContact-1.0".</t>
          <t>"dsfContact" XML namespace prefix refers to 
          "urn:ietf:params:xml:ns:dsfContact-1.0" XML namespace.</t>
          <t>"dsfVerificationCode-1.0" is used as an abbreviation for
          "urn:ietf:params:xml:ns:dsfVerificationCode-1.0".</t>
          <t>"dsfVerificationCode" XML namespace prefix refers to 
          "urn:ietf:params:xml:ns:dsfVerificationCode-1.0" XML namespace.</t>
          <t>"dsfRouting-1.0" is used as an abbreviation for
          "urn:ietf:params:xml:ns:dsfRouting-1.0".</t>
        </list></t>
        <t>Implementations MUST NOT depend on 
        the XML namespace prefix used in this document and 
        instead MUST employ a proper namespace-aware 
        XML parser and serializer to interpret and
        output the XML.</t>
      </section>
    </section>

    <section anchor="generalConventions" title="General Conventions">
    
      <t>This document includes a general set of attributes and terms that are described here.</t>
            
    <section title="Date and Time">
       <t>
          Numerous fields indicate "dates", such as the creation date of the DSF. These fields 
          SHALL contain timestamps indicating the date and time in UTC as specified in <xref target="RFC3339"/>,
          with no offset from the zero meridian.
       </t>
    </section>
    
    <section title="Checksum" anchor="checksum">
       <t>
          The checksum of the body of the file, as defined by the body rule of the <xref target="dsfFormat">Data Set File (DSF) ABNF</xref>, 
          MUST use CRC32, that is the algorithm used in the <xref target="iso13239">ISO 13239 standard</xref> 
          and in section 8.1.1.6.2 of <xref target="itu-t-V.42">ITU-T recommendation V.42</xref>.
       </t>
    </section>
    
    <section title="Type and Subtype" anchor="typeSubType">
      <t>
        There can be many different Data Set File (DSF) types supported based on the objects, operations, and 
        the specific scenarios.  To make it easier to negotiate the client's intent of the DSF with the server's 
        set of supported DSF files, the DSF supports the definition of a type and an optional sub-type.  The 
        supported list of types and sub-types is up to server policy.  The server SHOULD provide the possible 
        set of supported DSF type and sub-type values to the parties generating the DSF.  The mechanism for 
        providing the supported DSF type and sub-type values is not defined in this document but MAY require 
        registration within an IANA registry.  
      </t>
      <t>    
            The &lt;dataSet:type&gt; element formally defines the DSF type, which indicates the expected set of fields 
            defined under the &lt;dataSet:fields&gt; element and the expected operation to be taken.  An OPTIONAL "subType" attribute 
            defines the sub-type that is used to further refine the purpose of the DSF.
          </t>
          <t>
              It is recommended that the server follows a consistent naming scheme for the &lt;dataSet:type&gt; values.  One option is to 
            delimit the value with a '.' and to include the object ("domain", "host", "contact, "verificationCode", etc.), 
            the operation ("create", "renew, "transfer", "delete", "update", etc.), and the scoped name of the DSF.  For 
            example, to support the bulk update of encoded signed verification codes, the &lt;dataSet:type&gt; value can be set to 
            "verificationCode.update.encodedSignedCode".  To further sub-divide the "verificationCode.update.encodedSignedCode" type  
            by locality, the "subType" attribute can be set to the locality name.  For example, the "china" verification profile 
            supports two verification codes of type "domain" and "real-name", so the "verificationCode.update.encodedSignedCode" 
            DSF type can include "china" for the "subType" attribute, as in 
            &lt;dataSet:type subType="china"&gt;verificationCode.update.encodedSignedCode&lt;/dataSet:type&gt;.  
          </t>                    
    
    </section>
    
             
    
    <section anchor="fields" title="Fields">
      <t>
      The &lt;dataSet:fields&gt; element, an element in the <xref target="headerFormat">header</xref>, contains 
      an ordered list of CSV fields used in the body of the file delimited by 
          the character defined by the OPTIONAL "sep" attribute, with a default value of ",".
          A field child element substitutes for the &lt;dataSet:field&gt; abstract element.  Each 
          element defines the format of the CSV field contained in the body.  The &lt;dataSet:field&gt; 
          elements support the "type" attribute that defines the XML schema simple type of the field element.</t>
          <t>  
          The abstract &lt;dataSet:field&gt; element does not directly define any attributes, but 
          there are a couple attributes that a data set processor SHOULD support including:</t>
          <t><list hangIndent="4" style="hanging">
            <t hangText="&quot;isRequired&quot;:">
            When the "isRequired" attribute is "true", it indicates that the field MUST be non-empty in the body and when set 
            to "false", it indicates that the field MAY be empty in the body.  The "isRequired" attribute MAY 
            be specifically set for the field elements in the XML schema and MAY be overriden by specifying 
            the attribute in the fields under the &lt;dataSet:fields&gt; element.  If no "isRequired" attribute is defined, the default 
            value is "false". 
            </t>
            <t hangText="&quot;isPrimaryKey&quot;:">
            When the "isPrimaryKey" attribute is "true", it indicates that the field is part of the primary key of the 
            records.  The combination of the primary key fields MUST be unique across the set of records in the file.  
            The "isPrimaryKey" attribute MAY be specifically set for the field elements in the XML schema and MAY 
            be overridden by specifying the attribute in the fields under the &lt;dataSet:fields&gt; element.  If no 
            "isPrimaryKey" attribute is defined, the default value is "false". 
            </t>
          </list></t>
          
          <section anchor="baseFields" title="Base Field Types">
          
            <t>
            New field types can be defined that reside in the CSV records.  To make the definition of new field types 
            easier, a set of base field types are defined in the dataSet-1.0 XML schema that include:
            </t>
            <t><list hangIndent="4" style="hanging">
              <t hangText="&quot;dataSet:fieldOptionalType&quot;:">
              The "dataSet:fieldOptionalType" type can be extended by a field that can be empty ("isRequired" = "false") 
              and is not a member of the primary key ("isPrimaryKey" = "false").  
              </t>
              <t hangText="&quot;dataSet:fieldRequiredType&quot;:">
              The "dataSet:fieldRequiredType" type can be extended by a field that cannot be empty ("isRequired" = "true") 
              and is not a member of the primary key ("isPrimaryKey" = "false").  
              </t>
              <t hangText="&quot;dataSet:fieldPrimaryKeyType&quot;:">
              The "dataSet:fieldPrimaryKeyType" type can be extended by a field that cannot be empty ("isRequired" = "true") 
              and is a member of the primary key ("isPrimaryKey" = "true").  
              </t>
              <t hangText="&quot;dataSet:fListItemType&quot;:">
              The "dataSet:fListItemType" type is an extension of the "dataSet:fieldOptionalType" type that adds an OPTIONAL 
              "op" attribute that reflects the operation to apply for the list item.  The default "op" value is "replace".  
              The list of possible "op" values is include below.  A "dataSet:fListItemType" field with "op" set to "replace" MUST NOT 
              be mixed with a matching "dataSet:fListItemType" field with "op" set to either "add" or "remove".  
                    <list hangIndent="4" style="hanging">
                      <t hangText="&quot;replace&quot;:">Specifies that the list item will replace what is currently set for the object.  
                        The list of items provided will replace the existing list of items set on the object.  
                        The concrete "dataSet:fListItemType" field along with the DSF type can determine 
                        what is the possible set of list item values.  
                      </t>
                      <t hangText="&quot;add&quot;:">Specifies that the list item will be added to the object if it is not 
                      already set.  
                      </t>
                      <t hangText="&quot;rem&quot;:">Specifies that the list item will be removed from the object and expects it to 
                      already be set.   
                      </t>
                    </list>    
               
              </t>
            </list></t>
            
            <figure>
                <preamble>Example definition of the &lt;dataSet:fName&gt; field element that extends the 
                "dataSet:fieldPrimaryKeyType" base field type with the XML type dataSet:labelType and with 
                the required "class" attribute:</preamble>

            <artwork><![CDATA[
<element name="fName" type="dataSet:fNameType" 
  substitutionGroup="dataSet:field"/>
     
<complexType name="fNameType">
  <complexContent>
    <extension base="dataSet:fieldPrimaryKeyType">
      <sequence/>
      <attribute name="type" type="token"  
        default="dataSet\:labelType"/>
      <attribute name="class" type="token"  
        use="required"/>
    </extension>
  </complexContent>
</complexType>]]></artwork>
       </figure>
                
          </section>
        
          <section anchor="dataSetFieldElements" title="Data Set Field Elements">
          
            <t>
            The dataSet-1.0 XML schema predefines a set of field elements that can be used as child elements of 
            the &lt;dataSet:fields&gt; element of the header to define the CSV record fields.  The dataSet-1.0 field 
            elements with the XML schema type value and the base type include:      
            </t>
            
            <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;dataSet:fName&gt;:"> 
              Field that represents the name of an object.  This field extends 
              a "dataSet:fieldPrimaryKeyType", as defined in <xref target="baseFields"/>, with the type="token".  
              The required "class" attribute defines the class of the object, like the use of "domain" for 
              a domain name.  It is recommended to use an object specific name field if available, like &lt;dsfDomain:fName&gt;.  
              </t>
                  <t hangText="&lt;dataSet:fAuthInfo&gt;:">Object authorization information with type="eppcom:pwAuthInfoType".  
                  </t>        
              <t hangText="&lt;dataSet:fResultCode&gt;:"> 
              Field that represents the result of processing an individual record using the codes defined in <xref target="resultCodes"/>.  The 
              field extends a "dataSet:fieldRequiredType", as defined in <xref target="baseFields"/>, with the type="dataSet:resultCodeType".
              </t>
              <t hangText="&lt;dataSet:fResultMsg&gt;:"> 
              Field containing the human-readable description of the result code. The field extends a "dataSet:fieldOptionalType", as defined in 
              <xref target="baseFields"/>, with the type="normalizedString".  The field includes the OPTIONAL "lang" attribute with the default 
              value of "en" (English).      
              </t>
              <t hangText="&lt;dataSet:fResultReason&gt;:">
              Field containing the human-readable message that describes the reason for the error processing the record.  The field extends the 
              "dataSet:fieldOptionalType", as defined in <xref target="baseFields"/>, with the type="normalizedString".  The language of the reason
              is identified the OPTIONAL "lang" attribute.  If not specified, the default attribute value is "en" (English).  
              </t>
            </list></t>
                    
          <figure>
                <preamble>Example &lt;dataSet:fields&gt; definition for a result file generated by a server that includes 
                a domain name with a result code, with an OPTIONAL result message, and an OPTIONAL result reason:</preamble>

                <artwork><![CDATA[
<dataSet:fields>
  <dataSet:fName class="domain"/>
  <dataSet:fResultCode/>
  <dataSet:fResultMsg/>
  <dataSet:fResultReason/>
</dataSet:fields>]]></artwork>
            </figure>
          
            <section anchor="fieldElementExt" title="Field Element Extensibility">
              <t>New field elements MAY be defined in separate XML schemas and referenced as child elements 
              of the &lt;dataSet:fields&gt; element.  The convention is to prefix all field elements with 
              a lowercase "f", as in &lt;dataSet:fName&gt; for the object name or &lt;dataSet:fResultCode&gt; 
              for the result code.  The following are the steps to define a new field element:</t>  
                <t><list hangIndent="4" style="numbers">
                <t hangText="Create or new XML Schema or Extend an Existing XML Schema:">
                Define a new XML schema or extend an existing XML schema to include the definition 
                of the field element.  The XML schema will have it's own XML namespace that will 
                be referenced in the header of the Data Set File (DSF).  
                </t>
                <t hangText="Define a New complexType &quot;extension&quot; of &quot;dataSet:fieldType&quot;:">
                Define a new XML schema complexType that is a direct or indirect extension of the 
                "dataSet:fieldType" complexType.  The new complexType MUST directly, or indirectly
                define through extension, the following attibutes:
                  <list hangIndent="4" style="hanging">
                    <t hangText="&quot;type&quot;:">
                    Defines the XML schema data type of the CSV field.  The "default" value of the 
                    attribute is used to define the default CSV field type using an XML schema simple data type.  
                    Any XML namespaces MUST be escaped ("\:" instead of ":") so the XML 
                    parser of the header can ignore the reference during XML 
                    validation.  The "type" attribute is used during CSV validation leveraging the 
                    XML schema simple data type to define the format.  The "type" attribute can be 
                    overridden when referencing the field element in the header.  The 
                    "type" attribute for the "dataSet:fResultCodeType" complexType is defined as &lt;attribute name="type" default="dataSet\:resultCodeType"&gt;.  
                    When using the default XML namespace, no escaping is necessary.  For example for the "dataSet:fResultMsg" complexType, 
                    the "type" attribute is defined as &lt;attribute name="type" default="normalizedString"/>.  A 
                    validator of the Data Set File (DSF) will apply the XML schema type to the CSV fields.  
                    </t>
                    <t hangText="&quot;isRequired&quot;:">
                    See the definition of the "isRequired" attribute in <xref target="fields"/>.  A required field 
                    can extend the "dataSet:fieldRequiredType" complexType, as defined in <xref target="baseFields"/>, or 
                    can explicitly specify the attribute.  For example, the "isRequired" attribute is set in the "dataSet:fieldRequiredType" 
                    complexType as &lt;attribute name="isRequired" default="true"&gt;.  
                    </t>
                    <t hangText="&quot;isPrimaryKey&quot;:">
                    See the definition of the "isPrimaryKey" attribute in <xref target="fields"/>.  A primary key field 
                    can extend the "dataSet:primaryKeyType" complexType, as defined in <xref target="baseFields"/>, or 
                    can explicitly specify the attribute.  For example, the "isPrimaryKey" attribute is set in the 
                    "dataSet:fieldPrimaryKeyType" complexType as &lt;attribute name="isPrimaryKey" default="true"/>.
                    </t> 
                  </list>
                </t>
                <t hangText="Define Field Element">
                Define the field element that uses the new complexType defined above and that substitutes for the 
                "dataSet:field" abstract element.  An example of defining the "dataSet:fResultCode" field element 
                is &lt;element name="fResultCode" type="dataSet:fResultCodeType" substituteGroup="dataSet:field"/&gt;.  
                An example of defining the "dataSet:fResultReason" field 
                element is &lt;element name="fResultReason" type="dataSet:fResultMsgType" 
                subsititionGroup="dataSet:field"/&gt;.
                </t>
               </list></t>
               
          <figure>
                <preamble>Example definition of the &lt;dataSet:fResultCode&gt; field element that is 
                required to be non-empty and with the CSV field type "dataSet:resultCodeType":</preamble>

                <artwork><![CDATA[
 <element name="fResultCode" 
   type="dataSet:fResultCodeType" 
   substitutionGroup="dataSet:field"/>   
   
 <complexType name="fResultCodeType">
  <complexContent>
    <extension base="dataSet:fieldRequiredType">
      <sequence/>
      <attribute name="type" type="token"  
        default="dataSet\:resultCodeType"/>
    </extension>
  </complexContent>
 </complexType>]]></artwork>
            </figure>
          
          <figure>
                <preamble>Example definition of the &lt;dataSet:fResultMsg&gt; field element that  
                may be empty (optional), with the CSV field type "normalizedString", and with the 
                additional optional "lang" attribute:</preamble>

                <artwork><![CDATA[
 <element name="fResultMsg" 
   type="dataSet:fResultMsgType" 
   substitutionGroup="dataSet:field"/>   
   
 <complexType name="fResultMsgType">
  <complexContent>
    <extension base="dataSet:fieldOptionalType">
      <sequence/>
      <attribute name="type" type="token"  
        default="normalizedString"/>
      <attribute name="lang" type="language"  
        default="en"/>
    </extension>
  </complexContent>
 </complexType>]]></artwork>
            </figure>
                   
            </section>
          </section>
                    
		</section>
       
		<section anchor="routing" title="Routing">
			<t>
			 A Data Set File (DSF) MAY include data that targets multiple independent backend 
			 services, but the object alone cannot be used to determine the 
			 appropropriate backend service.  An example is creating a <xref target="contactObject">Contact Object</xref> 
			 in the .EXAMPLE1 domain registry service and creating another <xref target="contactObject">Contact Object</xref> 
			 in the .EXAMPLE2 domain registry service within a single DSF, where .EXAMPLE1 and .EXAMPLE2 are independent domain registry services.  
			 The Data Set File (DSF) processor MAY coordinate with the backend services to process each of the DSF records, 
			 but it is dependent on the client to specify the target backend service with each record.  
			</t>
			<t>The Data Set File (DSF) field element used for routing a record to a specific backend service includes:</t>
			<t><list hangIndent="4" style="hanging">
			  <t hangText="&lt;dsfRouting:fSubProduct&gt;:">Contains the unique sub-product name of a backend service with type="token".  
			  It is up to server policy on the valid list of sub-product values.  An example of a sub-product value is the 
			  Top Level Domain (TLD) of a domain registry service.  
			  </t>
			</list></t>
			<t>
			Routing is most applicable to objects like a <xref target="contactObject">Contact Object</xref> and 
			a <xref target="hostObject">Host Object</xref>, where the keys (&lt;dsfContact:fId&gt; for the Contact Object and 
			&lt;dsfHost:fName&gt; for the Host Object) MAY NOT be enough to uniqually identify a target domain registry service.  An 
			example of using the &lt;dsfRouting:fSubProduct&gt; field for routing is provided with the "contact.create.routing" 
			DSF in <xref target="contactObject"/>.
			</t>
		</section>
       
    </section>
     
    <section anchor="dsfFormat" title="Data Set File (DSF) Format">
      <t>The Data Set File (DSF) format supports multiple types of requests and response files.  
      All of these types of files support a general file format that includes a header that 
      provides meta-data about the data including the what, who, when, and optionally the digital signature of the 
      information, and the body containing the data.  The Data Set File (DSF) syntax is specified using  
        <xref target="RFC5234">Augmented Backus-Naur Form (ABNF) grammar</xref> as follows:
     </t>
        
       <figure>
          <preamble>Data Set File (DSF) ABNF</preamble>
          <artwork><![CDATA[
file         = header body
header       = dataSet-1-0 LF 
dataSet-1-0  = 1*(1*VCHAR LF) ; compliant to dataSet-1.0
body         = start [data] end
start        = "-----BEGIN DATA SET-----" LF
data         = 1*VCHAR LF ; CSV compliant <dataSet:fields>  
end          = "-----END DATA SET-----" *1LF]]></artwork>
        </figure>
     
    <section anchor="headerFormat" title="Header Format">
        <t>
        The header of the Data Set File (DSF) is an XML document that complies with the 
        dataSet-1.0 XML schema.  The purpose of the header is 
        to provide the meta-data about the data contained in the body.  The &lt;dataSet:definition&gt; 
        element is the root XML element of the header and contains the following child element:
        </t>
        <t><list hangIndent="4" style="hanging">
          <t hangText="&lt;dataSet:defData&gt; or &lt;dataSet:encodedSignedDefData&gt; or &lt;dataSet:resultData&gt;:">
             <list hangIndent="4" style="hanging">
              <t hangText="&lt;dataSet:defData&gt;:">
              Provides meta-data about the body of the file that is not digitally signed, as described in 
              <xref target="defData"/>.
              </t>
              <t hangText="&lt;dataSet:encodedSignedDefData&gt;:">
              Contains the encoded form of the digitally signed &lt;dataSet:signedDefData&gt; element, as described in 
              in <xref target="encodedSignedDefData"/>.
              </t>
              <t hangText="&lt;dataSet:resultData&gt;:">
              Provides the high level result data with the processing of a request Data Set File (DSF) by the server,  
              as described in <xref target="resultData"/>.
              </t>
            </list>
          </t>
        </list></t> 
        
        <section anchor="defData" title="&lt;dataSet:defData&gt; element">
          <t>
        The &lt;dataSet:defData&gt; element contains the meta-data of the body of the file that is not digitally signed.  
        The &lt;dataSet:defData&gt; element contains the following child elements:
          </t>
          <t><list hangIndent="4" style="hanging">
            <t hangText="&lt;dataSet:type&gt;:">
            The type value and OPTIONAL "subType" attribute value of the Data Set File (DSF), 
            as defined in <xref target="typeSubType"/>.  
            </t>
            <t hangText="&lt;dataSet:fields&gt;:">
            Ordered list of CSV fields as defined in <xref target="fields"/>.        
            </t>
        <t hangText="&lt;dataSet:dataSetId&gt;:">OPTIONAL unique identifier of the Data Set File (DSF).  The 
        client SHOULD assign a unique identifer when generating the Data Set File (DSF) and set it in the 
        &lt;dataSet:dataSetId&gt; element.
        </t>
        <t hangText="&lt;dataSet:crDate&gt;:">Contains the date and time of the Data Set File (DSF) creation.
        </t>
          </list></t>
          <figure>
              <preamble>Example &lt;dataSet:defData&gt; element for setting 
              verification codes on a domain name:</preamble>

              <artwork><![CDATA[
<dataSet:defData>
  <dataSet:fields>
    <dataSet:type subType="locality">
      verificationCode.update.encodedSignedCode
    </dataSet:type>
    <dsfDomain:fName/>
    <dsfVerificationCode:fEncodedSignedCode type="domain"/>
    <dsfVerificationCode:fEncodedSignedCode type="real-name"/>
  </dataSet:fields>
  <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
  <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
</dataSet:defData>]]></artwork>
          </figure>
        
        </section>  
        
        <section anchor="encodedSignedDefData" title="&lt;dataSet:encodedSignedDefData&gt; element">
        <t>
          The &lt;dataSet:encodedSignedDefData&gt; element contains the encoded form of the digitally signed &lt;dataSet:signedDefData&gt; element, described 
          in <xref target="signedDefData"/>, with the encoding defined by the "encoding" attribute 
          with the default "encoding" value of "base64".  The "base64" encoded text 
          of the &lt;dataSet:signedDefData&gt; element MUST conform to <xref target="RFC2045"/>.
          </t>
          <figure>
              <preamble>Example &lt;dataSet:encodedSignedDefData&gt; element, where "..." represents continuation of data for brevity:</preamble>

                <artwork><![CDATA[
<dataSet:encodedSignedDefData encoding="base64">
  ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z
  ...
  b25Db2RlOnNpZ25lZENvZGU+Cg==
</dataSet:encodedSignedDefData>]]></artwork>
            </figure>
            
      <section anchor="signedDefData" title="Signed Definition Data">
        <t>
          The Signed Definition Data, represented by the &lt;dataSet:signedDefData&gt; element, is a signed 
          extension of the &lt;dataSet:defData&gt; element, defined in <xref target="defData"/>.  
          The &lt;dataSet:signedDefData&gt; provides the meta-data about the body of the file, 
          that is a fragment of XML that is digitally signed using 
          <xref target="W3C.CR-xmldsig-core2-20120124">XML Signature</xref>.  The &lt;dataSet:signedDefData&gt; element 
          includes a required "id" attribute of type XSD ID for use with the IDREF URI from the Signature element.  Setting 
          the "id" attribute value to "signedData" is recommended.  
          The certificate of the issuer MUST be included with the Signature so it can be chained with the 
          issuer's certificate by the validating client.  A checksum, as defined by the <xref target="checksum"/>, 
          of the body of the file, as defined by the body rule of the Data Set File (DSF) ABNF, is included 
          in the digitally signed data to ensure that it's covered by the Signature.  The &lt;dataSet:signedDefData&gt; element 
          contains the following child elements:
        </t>
        <t><list hangIndent="4" style="hanging">
              <t hangText="&lt;dataSet:type&gt;:">
              The type value and OPTIONAL "subType" attribute value of the Data Set File (DSF), 
              as defined in <xref target="typeSubType"/>.  
              </t>
              <t hangText="&lt;dataSet:fields&gt;:">
              Ordered list of CSV fields as defined in <xref target="fields"/>.       
              </t>
          <t hangText="&lt;dataSet:dataSetId&gt;">OPTIONAL unique identifier of the data set.  The 
          source SHOULD assign a unique identifer when generating the data set and set it in the 
          &lt;dataSet:dataSetId&gt; element.
          </t>
          <t hangText="&lt;dataSet:crDate&gt;:">Contains the date and time of the data set creation.
          </t>
          <t hangText="&lt;dataSet:cksum&gt;:">Checksum of the body of the file, as defined by the body rule of the Data Set File (DSF) ABNF, 
          using the mechanism defined by the <xref target="checksum"/>.
          </t>
          <t hangText="&lt;Signature&gt;:"><xref target="W3C.CR-xmldsig-core2-20120124">XML Signature</xref> for the &lt;dataSet:signedDefData&gt;.  Use 
              of a namespace prefix, like "dsig", is recommended for the <xref target="W3C.CR-xmldsig-core2-20120124">XML Signature</xref> elements.</t>
          </list></t>
         <figure>
              <preamble>Example &lt;dataSet:signedDefData&gt; element, where "..." represents continuation of data for brevity:</preamble>
  
              <artwork><![CDATA[
<dataSet:signedDefData 
    xmlns:dataSet=
      "urn:ietf:params:xml:ns:dataSet-1.0"
    xmlns:dsfDomain=
      "urn:ietf:params:xml:ns:dsfDomain-1.0"     
    xmlns:dsfVerificationCode=
      "urn:ietf:params:xml:ns:dsfVerificationCode-1.0"     
    id="signedData">
    <dataSet:type subType="locality">
      verificationCode.update.encodedSignedCode
    </dataSet:type>
    <dataSet:fields>
      <dsfDomain:fName/>
      <dsfVerificationCode:fCode type="domain"/>
      <dsfVerificationCode:fCode type="real-name"/>
    </dataSet:fields>
     <dataSet:dataSetId>abc-123</dataSet:dataSetId>
     <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
     <dataSet:cksum>6F2B988F</dataSet:cksum>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
   <SignedInfo>
    <CanonicalizationMethod
 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <SignatureMethod
 Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
    <Reference URI="#signedData">
     <Transforms>
      <Transform
 Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
     </Transforms>
     <DigestMethod
 Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
 <DigestValue>wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg=
 </DigestValue>
    </Reference>
   </SignedInfo>
   <SignatureValue>
 jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w
 ...
 ipJsXNa6osTUw1CzA7jfwA==
   </SignatureValue>
   <KeyInfo>
    <X509Data>
    <X509Certificate>
 MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL
 ...
 AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk
   </X509Certificate>
   </X509Data>
   </KeyInfo>
  </Signature>     
</dataSet:signedDefData>]]></artwork>
         </figure>
          
      </section>
            
        </section>  
        
        
        <section anchor="resultData" title="&lt;dataSet:resultData&gt; element">
      <t>
      The &lt;dataSet:resultData&gt; element contains the high level result data with the processing of a 
      request Data Set File (DSF) by the server.
          the "code" attribute describes the success or failure of the 
          processing using the code values defined in <xref target="resultCodes"/>.  The &lt;dataSet:resultData&gt; element 
          contains the following child elements:
          </t>
          <t><list hangIndent="4" style="hanging">
            <t hangText="&lt;dataSet:type&gt;:">
            OPTIONAL type value and OPTIONAL "subType" attribute value associaed with the request Data Set File (DSF), 
            as defined in <xref target="typeSubType"/>.  The &lt;dataSet:type&gt; element MUST be returned if 
            the request header is successfully parsed. 
            </t>
            <t hangText="&lt;dataSet:fields&gt;:">
            OPTIONAL ordered list of CSV fields as defined in <xref target="fields"/>.  If the 
            &lt;dataSet:fields&gt; element is not defined, then the data as defined by the data rule of the Data Set File (DSF) ABNF 
            MUST be empty.      
            </t>
            <t hangText="&lt;dataSet:dataSetId&gt;:">OPTIONAL identifier of the Data Set File (DSF) formed 
            using the &lt;dataSet:dataSetId&gt; element associated with the request if supplied by 
            the client and the request header is successfully parsed.
            </t>
            <t hangText="&lt;dataSet:msg&gt;:">Human-readable description of the result code.  The 
            language of the result is identified via an OPTIONAL "lang" attribute.  If not specified, 
            the default attribute value is "en" (English).
            </t>
            <t hangText="&lt;dataSet:reason&gt;:">OPTIONAL human-readable message that describes the reason for 
            the error. The  language of the reason is identified via an OPTIONAL "lang" attribute.  If not specified, 
            the default attribute value is "en" (English).
            </t>
            <t hangText="&lt;dataSet:records&gt;:">OPTIONAL summary record result data.  The summary data is associated 
            with the count of the records (lines in request data).  The &lt;dataSet:records&gt; element contains the following 
            child elements: 
            </t>
              <t><list hangIndent="4" style="hanging">
                <t hangText="&lt;dataSet:total&gt;:">Total count of the records (lines in request data) 
                processed by the server.
                </t>
                <t hangText="&lt;dataSet:success&gt;:">Total count of the records (lines in request data) 
                successfully processed by the server.
                </t>
                <t hangText="&lt;dataSet:failed&gt;:">Total count of the records (lines in request data) 
                that failed processing by the server.
                </t>                      
              </list></t>
          </list></t>
          <figure>
              <preamble>Example successful &lt;dataSet:resultData&gt; element:</preamble>

              <artwork><![CDATA[
<dataSet:resultData code="1000">
  <dataSet:type subType="locality">
    verificationCode.update.encodedSignedCode
  </dataSet:type>
  <dataSet:fields>
    <dsfDomain:fName/>
    <dataSet:fResultCode/>
    <dataSet:fResultMsg/>
    <dataSet:fResultReason/>
  </dataSet:fields>
  <dataSet:dataSetId>abc-123</dataSet:dataSetId>
  <dataSet:svTRID>54322-XYZ</dataSet:svTRID>
  <dataSet:msg>Code Set processed successfully.</dataSet:msg>
  <dataSet:records>
    <dataSet:total>2</dataSet:total>
    <dataSet:success>2</dataSet:success>
    <dataSet:failed>0</dataSet:failed>
  </dataSet:records>
</dataSet:resultData>]]></artwork>
          </figure>
          <figure>
              <preamble>Example &lt;dataSet:resultData&gt; element with some failures:</preamble>

              <artwork><![CDATA[
<dataSet:resultData code="1001">
  <dataSet:type subType="locality">
    verificationCode.update.encodedSignedCode
  </dataSet:type>
  <dataSet:fields>
    <dsfDomain:fName/>
    <dataSet:fResultCode/>
    <dataSet:fResultMsg/>
    <dataSet:fResultReason/>
  </dataSet:fields>
  <dataSet:dataSetId>abc-123</dataSet:dataSetId>
  <dataSet:svTRID>54322-XYZ</dataSet:svTRID>
  <dataSet:msg>Success with failures</dataSet:msg>
  <dataSet:records>
    <dataSet:total>4</dataSet:total>
    <dataSet:success>1</dataSet:success>
    <dataSet:failed>3</dataSet:failed>
  </dataSet:records>    
</dataSet:resultData>]]></artwork>
          </figure>
          <figure>
              <preamble>Example failed &lt;dataSet:resultData&gt; element based on malformed request file:</preamble>

              <artwork><![CDATA[
<dataSet:resultData code="2000">
  <dataSet:svTRID>54322-XYZ</dataSet:svTRID>
  <dataSet:msg>File syntax error</dataSet:msg>
  <dataSet:reason lang="en">Malformed request file
  </dataSet:reason>
</dataSet:resultData>]]></artwork>
          </figure>
          <figure>
              <preamble>Example failed &lt;dataSet:resultData&gt; element based on header syntax error:</preamble>

              <artwork><![CDATA[
<dataSet:resultData code="2001">
  <dataSet:svTRID>54322-XYZ</dataSet:svTRID>
  <dataSet:msg>Header syntax error</dataSet:msg>
  <dataSet:reason lang="en">Header XML syntax error
  </dataSet:reason>
</dataSet:resultData>]]></artwork>
          </figure>
          <figure>
              <preamble>Example failed &lt;dataSet:resultData&gt; element based on body syntax error:</preamble>

              <artwork><![CDATA[
<dataSet:resultData code="2002">
  <dataSet:type subType="locality">
    verificationCode.update.encodedSignedCode
  </dataSet:type>
  <dataSet:dataSetId>abc-123</dataSet:dataSetId>
  <dataSet:svTRID>54322-XYZ</dataSet:svTRID>
  <dataSet:msg>Body syntax error</dataSet:msg>
  <dataSet:reason lang="en">Invalid with fields definition
  </dataSet:reason>
</dataSet:resultData>]]></artwork>
          </figure>       
        </section>  
      
   </section>
    
    <section anchor="bodyFormat" title="Body Format">
        <t>
          The body of the Data Set File (DSF) is a set of Comma-Separated Values (CSV) 
          data that includes a leading "-----BEGIN CODE SET-----" line and 
          a trailing "-----END CODE SET-----" line.  The format of the CSV data is defined by 
          the &lt;dataSet:fields&gt; element in the <xref target="headerFormat">header</xref>, that includes the 
          delimiter and the ordered set of <xref target="fields">fields</xref> with their XML simple type and 
          descriptor attributes like "isRequired", "isPrimaryKey", "class", and "codeType".  
        </t>
                  
      <figure>
            <preamble>
              Example body for a result file generated by a server that includes a success 
              and a set of failed records with a mix of messages and reasons.:
            </preamble>

            <artwork><![CDATA[
-----BEGIN DATA SET-----
domain1.example,1000,Success,
domain2.example,2303,Object does not exist,
domain3.example,2201,Authorization error,
domain4.example,2302,Object exists,domain code already
-----END DATA SET-----]]></artwork>
        </figure>
        
    </section>
    
   </section>
    
    <section anchor="objectDescription" title="Object Description">
    
      <t>This section describes the base objects supported by this specification:</t>
    
      <section anchor="domainNameObject" title="Domain Name Object">
        <t>
        The domain name object is based on the EPP domain name mapping specified in <xref target="RFC5731"/>.  
        </t>
                
        <t>The Data Set File (DSF) field elements specific to the domain name object include:</t>
        <t><list hangIndent="4" style="hanging">
                <t hangText="&lt;dsfDomain:fName&gt;:">Domain name field with type="eppcom:labelType" and isRequired="true".  
                </t>        
                <t hangText="&lt;dsfDomain:fPeriod&gt;:">Domain name initial or extension period of the expiration date with type="domain:pLimitType".  
                </t>        
                <t hangText="&lt;dsfDomain:fPeriodUnit&gt;:">Domain name initial or extension period unit of the expiration date with type="domain:pUnitType".  
                </t>  
                <t hangText="&lt;dsfDomain:fNs&gt;:">Domain name server is an extension of the "dataSet:fListItemType" field, described in <xref target="baseFields"/>, 
                with type="eppcom:labelType".  
                </t>                              
                <t hangText="&lt;dsfDomain:fContact&gt;:">Domain contact identifer with type="eppcom:clIDType" and with required "role" attribute.  The 
                possible values of the "role" attribute include "registrant", "admin", "tech", and "billing".  
                </t>                              
                <t hangText="&lt;dsfDomain:fStatus&gt;:">The status of the domain name is an extension of the "dataSet:fListItemType" field, 
                described in <xref target="baseFields"/>, with type="domain:statusValueType".  
                </t>
                <t hangText="&lt;dsfDomain:fKeyTag&gt;:">Contains the DS key tag value per <xref target="RFC5910"/> with type="unsignedShort".  
                </t>
                <t hangText="&lt;dsfDomain:fDsAlg&gt;:">Contains the DS algorithm value per <xref target="RFC5910"/> with type="unsignedByte".
                </t>
                <t hangText="&lt;dsfDomain:fDigestType&gt;:">Contains the DS digest type value per <xref target="RFC5910"/> with type="unsignedByte".
                </t>
                <t hangText="&lt;dsfDomain:fDigest&gt;:">Contains the DS digest value per <xref target="RFC5910"/> with type="hexBinary".
                </t>
                <t hangText="&lt;dsfDomain:fFlags&gt;:">Contains the flags field value per <xref target="RFC5910"/> with type="unsignedShort".
                </t>            
                <t hangText="&lt;dsfDomain:fProtocol&gt;:">Contains the Key protocol value per <xref target="RFC5910"/> with type="unsignedByte".
                </t>
                <t hangText="&lt;dsfDomain:fKeyAlg&gt;:">Contains the Key algorithm value per <xref target="RFC5910"/> with type="unsignedByte".
                </t>
                <t hangText="&lt;dsfDomain:fPubKey&gt;:">Contains the public key value per <xref target="RFC5910"/> with type="secDNS:keyType".
                </t>
                <t hangText="&lt;dsfDomain:fMaxSigLife&gt;:">Indicates a child's preference for the number of seconds 
                after signature generation when the parent's signature on the DS information provided by the child 
                will expire with type="secDNS:maxSigLifeType" defined in <xref target="RFC5910"/>.
                </t>
          </list></t>
        
          
        <t> 
            The following are example DSF files using the domain object fields.  The different forms of domain 
            object DSF files is up to server policy.  
        </t>
        
        <figure>
             <preamble>Example of a "domain.update.replaceClientStatuses" DSF that will set the client statuses 
             of a domain name to those specified in the DSF record.  The client statuses set will be replaced 
             by the set of client statuses specified.  Empty statuses will result in the removal of those 
             statuses if previously set.  Non-empty statuses will be added if not previously set.  Non-empty 
             statuses will result in no change if previously set.  All five client statuses defined 
             in <xref target="RFC5731"/> are defined in the DSF in fixed order.</preamble>

             <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfDomain=
  "urn:ietf:params:xml:ns:dsfDomain-1.0">
  <dataSet:defData>
    <dataSet:type>
      domain.update.replaceClientStatuses
    </dataSet:type>
    <dataSet:fields>
      <dsfDomain:fName/>
      <!-- clientDeleteProhibited -->
      <dsfDomain:fStatus/>
      <!-- clientHold -->
      <dsfDomain:fStatus/>
      <!-- clientRenewProhibited -->
      <dsfDomain:fStatus/>
      <!-- clientTransferProhibited -->
      <dsfDomain:fStatus/>
      <!-- clientUpdateProhibited -->
      <dsfDomain:fStatus/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,clientDeleteProhibited,,,,clientUpdateProhibited
domain2.example,,clientHold,,,
domain3.example,,,clientRenewProhibited,clientTransferProhibited,
domain4.example,,,,,
-----END DATA SET-----]]></artwork>
          </figure>

        <figure>
             <preamble>Example of a "domain.update.addRemoveStatus" DSF that will add a status and remove 
             a status for each domain name.  Any status can be empty to indicate no action for that domain name. 
             </preamble>

             <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfDomain=
  "urn:ietf:params:xml:ns:dsfDomain-1.0">
  <dataSet:defData>
    <dataSet:type>
      domain.update.addRemoveNs
    </dataSet:type>
    <dataSet:fields>
      <dsfDomain:fName/>
      <dsfDomain:fNs op="add"/>
      <dsfDomain:fNs op="remove"/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,ns1.domain1.example,n2.domain1.example
domain2.example,ns1.domain1.example,
domain3.example,,ns2.domain1.example
-----END DATA SET-----]]></artwork>
          </figure>


          
       <figure>
            <preamble>Example of a "domain.update.replaceNs" DSF that will set the name servers 
            of a domain name to those specified in the DSF record.  The server supports setting 
            up to 13 name servers to a domain name, so there are 13 &lt;dsfDomain:fNs&gt; defined.  
            All existing name servers set will be replaced with the name servers specified.
            </preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfDomain=
  "urn:ietf:params:xml:ns:dsfDomain-1.0">
  <dataSet:defData>
    <dataSet:type>
      domain.update.replaceNs
    </dataSet:type>
    <dataSet:fields>
      <dsfDomain:fName/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,ns1.domain1.example,n2.domain1.example,,,,,,,,,,,
domain2.example,ns1.domain1.example,,,,,,,,,,,,
domain3.example,,,,,,,,,,,,,
-----END DATA SET-----]]></artwork>
          </figure>
      
       <figure>
            <preamble>Example of a "domain.update.addRemoveNs" DSF that will add a name server and remove 
             a name server for each domain name.  Any name server can be empty to indicate no action for that domain name. 
            </preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfDomain=
  "urn:ietf:params:xml:ns:dsfDomain-1.0">
  <dataSet:defData>
    <dataSet:type>
      domain.update.addRemoveNs
    </dataSet:type>
    <dataSet:fields>
      <dsfDomain:fName/>
      <dsfDomain:fNs op="add"/>
      <dsfDomain:fNs op="remove"/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,ns1.domain1.example,n2.domain1.example
domain2.example,ns1.domain1.example,
domain3.example,,ns2.domain1.example
-----END DATA SET-----]]></artwork>
          </figure>
      
       <figure>
            <preamble>Example of a "domain.update.contacts" DSF that supports updating 
            the contacts (registrant, admin, tech, and billing) for each 
            domain name.  All four contacts fields are set as required 
            using the "isRequired" attribute and any existing contacts set 
            for each domain name are replaced.</preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfDomain=
  "urn:ietf:params:xml:ns:dsfDomain-1.0">
  <dataSet:defData>
    <dataSet:type>
      domain.update.contacts
    </dataSet:type>
    <dataSet:fields>
      <dsfDomain:fName/>
      <dsfDomain:fContact role="registrant" isRequired="true"/>
      <dsfDomain:fContact role="admin" isRequired="true"/>
      <dsfDomain:fContact role="tech" isRequired="true"/>
      <dsfDomain:fContact role="billing" isRequired="false"/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,jd1234,sh813,sh813,sh813
domain2.example,jd1234,sh813,sh813,
-----END DATA SET-----]]></artwork>
          </figure>
      
      
       <figure>
            <preamble>Example of a "domain.create.standard" DSF that supports creating each domain name 
            record with a standard set of fields / attributes for a thick domain name. 
            </preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfDomain=
  "urn:ietf:params:xml:ns:dsfDomain-1.0">
  <dataSet:defData>
    <dataSet:type>
      domain.create.standard
    </dataSet:type>
    <dataSet:fields>
      <dsfDomain:fName/>
      <dsfDomain:fPeriod/>
      <dsfDomain:fNs/>
      <dsfDomain:fNs/>
      <dsfDomain:fContact role="registrant"/>
      <dsfDomain:fContact role="admin"/>
      <dsfDomain:fContact role="tech"/>
      <dsfDomain:fContact role="billing"/>
      <dataSet:fAuthInfo/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,1,ns1.dom.example,,jd1234,sh813,sh813,sh813,2fooBAR
domain2.example,1,,,jd1234,sh813,sh813,sh813,2fooBAR
-----END DATA SET-----]]></artwork>
          </figure>
        
      </section>
    
      <section anchor="hostObject" title="Host Object">
        <t>
        The host object is based on the EPP host mapping specified in <xref target="RFC5732"/>.  
        </t>
                
        <t>The Data Set File (DSF) field elements specific to the host object include:</t>
        <t><list hangIndent="4" style="hanging">
                <t hangText="&lt;dsfHost:fName&gt;:">Host name field with type="eppcom:labelType" and isRequired="true".  
                </t>        
                <t hangText="&lt;dsfHost:fNewName&gt;:">Host new name field used to rename the host with type="eppcom:labelType".  
                </t>        
                <t hangText="&lt;dsfHost:fAddrVersion&gt;:">The address version ("v4" or "v6") is an extension of the "dataSet:fListItemType" field, described in <xref target="baseFields"/>, 
                with type="eppcom:addrStringType".  The "dsfHost.fAddrVersion" field usually corresponds with a following "dsfHost:fAddr" field.  
                The "dsfHost:fAddrVersion" and "dsfHost.fAddr" fields are included in pairs.         
                </t>                              
                <t hangText="&lt;dsfHost:fAddr&gt;:">The address is an extension of the "dataSet:fListItemType" field, described in <xref target="baseFields"/>, 
                with type="eppcom:addrStringType".  The "dsfHost.fAddr" field usually corresponds with a previous "dsfHost:fAddrVersion" field that defines 
                the type of address.  The "dsfHost:fAddrVersion" and "dsfHost.fAddr" fields are included in pairs.   
                </t>                              
                <t hangText="&lt;dsfHost:fStatus&gt;:">The status of the host is an extension of the "dataSet:fListItemType" field, 
                described in <xref target="baseFields"/>, with type="host:statusValueType".  
                </t>
          </list></t>
        
          
        <t> 
            The following are example DSF files using the host object fields.  The different forms of host 
            object DSF files is up to server policy.  
        </t>
        
        <figure>
             <preamble>Example of a "host.update.replaceClientStatuses" DSF that will set the client statuses 
             of a host to those specified in the DSF record.  The client statuses set will be replaced 
             by the set of client statuses specified.  Empty statuses will result in the removal of those 
             statuses if previously set.  Non-empty statuses will be added if not previously set.  Non-empty 
             statuses will result in no change if previously set.  All two client statuses defined 
             in <xref target="RFC5732"/> are defined in the DSF in fixed order.</preamble>

             <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfHost=
  "urn:ietf:params:xml:ns:dsfHost-1.0">
  <dataSet:defData>
    <dataSet:type>
      host.update.replaceClientStatuses
    </dataSet:type>
    <dataSet:fields>
      <dsfHost:fName/>
      <!-- clientDeleteProhibited -->
      <dsfHost:fStatus/>
      <!-- clientUpdateProhibited -->
      <dsfHost:fStatus/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
ns1.domain.example,clientDeleteProhibited,clientUpdateProhibited
ns2.domain.example,,clientUpdateProhibited
ns3.domain.example,clientDeleteProhibited,
ns4.domain.example,,
-----END DATA SET-----]]></artwork>
          </figure>

        <figure>
             <preamble>Example of a "host.update.addRemoveStatus" DSF that will add a status and remove 
             a status for each host.  Any status can be empty to indicate no action for that host. 
             </preamble>

             <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfHost=
  "urn:ietf:params:xml:ns:dsfHost-1.0">
  <dataSet:defData>
    <dataSet:type>
      host.update.addRemoveClientStatuses
    </dataSet:type>
    <dataSet:fields>
      <dsfHost:fName/>
      <dsfHost:fStatus op="add"/>
      <dsfHost:fStatus op="remove"/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
ns1.domain.example,clientDeleteProhibited,clientUpdateProhibited
ns2.domain.example,,clientUpdateProhibited
ns3.domain.example,clientUpdateProhibited,
-----END DATA SET-----]]></artwork>
          </figure>


          
       <figure>
            <preamble>Example of a "host.update.replaceAddr" DSF that will set the addresses  
            of a host to those specified in the DSF record.  The server supports setting 
            up to 6 addresses to a host, so there are 6 &lt;dsfHost:fAddrVersion&gt; and &lt;dsfHost:fAddr&gt; field pairs defined.  
            All existing addresses set will be replaced with the addresses specified.
            </preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfHost=
  "urn:ietf:params:xml:ns:dsfHost-1.0">
  <dataSet:defData>
    <dataSet:type>
      host.update.replaceAddr
    </dataSet:type>
    <dataSet:fields>
      <dsfHost:fName/>
      <dsfHost:fAddrVersion/>
      <dsfHost:fAddr/>
      <dsfHost:fAddrVersion/>
      <dsfHost:fAddr/>
      <dsfHost:fAddrVersion/>
      <dsfHost:fAddr/>
      <dsfHost:fAddrVersion/>
      <dsfHost:fAddr/>
      <dsfHost:fAddrVersion/>
      <dsfHost:fAddr/>
      <dsfHost:fAddrVersion/>
      <dsfHost:fAddr/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
ns1.domain.example,v4,192.0.2.2,v4,192.0.2.29,,,,,,,,
ns2.domain.example,v6,1080:0:0:0:8:800:200C:417A,,,,,,,,,,
ns3.domain.example,,,,,,,,,,,,
-----END DATA SET-----]]></artwork>
          </figure>
      
       <figure>
            <preamble>Example of a "host.update.addRemoveAddr" DSF that will add an address and remove 
             an address for each host.  Any address can be empty to indicate no action for that host.  
             The &lt;dsfHost:fAddrVersion&gt; and &lt;dsfHost:fAddr&gt; field pairs are provided with 
             matching list operations.    
            </preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfHost=
  "urn:ietf:params:xml:ns:dsfHost-1.0">
  <dataSet:defData>
    <dataSet:type>
      host.update.addRemoveAddr
    </dataSet:type>
    <dataSet:fields>
      <dsfHost:fName/>
      <dsfHost:fAddrVersion op="add"/>
      <dsfHost:fAddr op="add"/>
      <dsfHost:fAddrVersion op="remove"/>
      <dsfHost:fAddr op="remove"/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
ns1.domain.example,v4,192.0.2.2,v4,192.0.2.29
ns2.domain.example,v6,1080:0:0:0:8:800:200C:417A,,
ns3.domain.example,,v4,192.0.2.29
-----END DATA SET-----]]></artwork>
          </figure>
      
       <figure>
            <preamble>Example of a "host.create.standard" DSF that supports creating each host 
            record with a standard set of fields / attributes for a host.  There is an example 
            of creating an internal host (ns1.domain.example and ns2.domain.example) with up 
            to two addresses and an external host (ns1.domain.external) without addresses. 
            </preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfHost=
  "urn:ietf:params:xml:ns:dsfHost-1.0">
  <dataSet:defData>
    <dataSet:type>
      host.create.standard
    </dataSet:type>
    <dataSet:fields>
      <dsfHost:fName/>
      <dsfHost:fAddrVersion/>
      <dsfHost:fAddr/>
      <dsfHost:fAddrVersion/>
      <dsfHost:fAddr/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
ns1.domain.example,v4,192.0.2.2,v4,192.0.2.29
ns2.domain.example,v6,1080:0:0:0:8:800:200C:417A,
ns1.domain.external,,,,
-----END DATA SET-----]]></artwork>
          </figure>
        
      </section>
    
      <section anchor="contactObject" title="Contact Object">
        <t>
        The contact object is based on the EPP host mapping specified in <xref target="RFC5733"/>.  
        </t>

            <t>
              Some elements MAY be provided in either internationalized form ("int") or provided in localized 
              form ("loc").  Those elements use a field value or "isLoc" attribute to specify the form used.  If 
              an "isLoc" attribute is used, a value of "true" indicates the use of the localized form and a value 
              of "false" indicates the use of the internationalized form.  This MAY override the form specified for a parent 
              element.  A value of "int" is used to indicate the internationalized form and 
              a value of "loc" is used to indicate the localized form.  
              When the internalized form ("int") is provided, the field value MUST be represented in a subset of 
              UTF-8 that can be represented in the 7-bit US-ASCII character set.  When the localized form ("loc") 
              is provided, the field value MAY be represented in unrestricted UTF-8.  
              Some of the contact field elements specify the internationalized form with the isLoc="false" attribute.
             </t>
                
        <t>The Data Set File (DSF) field elements specific to the contact object include:</t>
        <t><list hangIndent="4" style="hanging">
 
                 <t hangText="&lt;dsfContact:fId&gt;:">Contains the server-unique contact identifier with type="eppcom:clIDType" and isRequired="true".  
                </t>
 
                <t hangText="&lt;dsfContact:fEmail&gt;:">Contains the contact's email address with type="eppcom:minTokenType" and isRequired="true".  
                </t>
 
                 <t hangText="&lt;dsfContact:fVoice&gt;:">Contains the contact's voice telephone number with type="contact:e164StringType".  
                </t>

                <t hangText="&lt;dsfContact:fVoiceExt&gt;:">Contains the contact's voice telephone number extension with type="token".  
                </t>

                <t hangText="&lt;dsfContact:fFax&gt;:">Contains the contact's facsimile telephone number with type="contact:e164StringType".  
                </t>

                <t hangText="&lt;dsfContact:fFaxExt&gt;:">Contains the contact's facsimile telephone number extension with type="token".  
                </t>
 
                <t hangText="&lt;dsfContact:fName&gt;:">Contains the contact's name of the individual or role represented by the contact with type="contact:postalLineType" and isRequired="true".  
                An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form. 
                </t>

                <t hangText="&lt;dsfContact:fStreet&gt;:">Contains the contact's contact's street address line with type="contact:fPostalLineType".  An index attribute 
                is required to indicate which street address line the field represents with index "0" for the first line and index "2" for the last line.  
                An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form. 
                </t>

                <t hangText="&lt;dsfContact:fCity&gt;:">Contains the contact's city with type="contact:postalLineType" and isRequired="true".   
                An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form. 
                </t>

                <t hangText="&lt;dsfContact:fCc&gt;:">Contains the contact's country code with type="contact:ccType" and isRequired="true".   
                An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form. 
                </t>
 
                 <t hangText="&lt;dsfContact:fPostalType&gt;:">Contains the form of the postal-address information with type="contact:postalLineType".  
                This field specifies the form ("int" or "loc") of the 
                &lt;dsfContact:fName&gt;, &lt;dsfContact:fOrg&gt;, &lt;dsfContact:fStreet&gt;, &lt;dsfContact:fCity&gt;, 
                &lt;dsfContact:fSp&gt;, &lt;dsfContact:fPc&gt;, &lt;dsfContact:fCc&gt; fields.  
                </t>
 
                <t hangText="&lt;dsfContact:fOrg&gt;:">Contains the name of the organization with which the contact is affiliated with type="contact:optPostalLineType".  
                An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form. 
                </t>

                <t hangText="&lt;dsfContact:fSp&gt;:">Contains the contact's state or province with type="contact:optPostalLineType".   
                An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form. 
                </t>
   
                <t hangText="&lt;dsfContact:fPc&gt;:">Contains the contact's postal code with type="contact:pcType".  
                An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form. 
                </t>
                
                <t hangText="&lt;dsfContact:fDiscloseFlag&gt;:">Contains flag with a value of "true" or "1" (one) notes the preference 
                to allow disclosure of the specified elements as an exception to the stated data-collection policy.  
                A value of "false" or "0" (zero) notes a client preference to not allow disclosure of the specified elements as an exception 
                to the stated data-collection policy with type="boolean". The additional fields define specific exceptional disclosure 
                preferences based on the &lt;dsfContact:fDiscloseFlag&gt; field.  
                </t>
 
                <t hangText="&lt;dsfContact:fDiscloseNameLoc&gt;:">Exceptional disclosure preference flag for the localized form of the 
                contact name with type="boolean".  
                </t>

                <t hangText="&lt;dsfContact:fDiscloseNameInt&gt;:">Exceptional disclosure preference flag for the internationalized form of the 
                contact name with type="boolean".   
                </t>

                <t hangText="&lt;dsfContact:fDiscloseOrgLoc&gt;:">Exceptional disclosure preference flag for the localized form of the 
                contact organization with type="boolean".   with type="boolean".  
                </t>

                <t hangText="&lt;dsfContact:fDiscloseOrgInt&gt;:">Exceptional disclosure preference flag for the internationalized form of the 
                contact organization with type="boolean".   with type="boolean".  
                </t>

                <t hangText="&lt;dsfContact:fDiscloseAddrLoc&gt;:">Exceptional disclosure preference flag for the localized form of the 
                contact address with type="boolean".
                </t>
   
                <t hangText="&lt;dsfContact:fDiscloseAddrInt&gt;:">Exceptional disclosure preference flag for the internationalized form of the 
                contact address with type="boolean".  
                </t>

                <t hangText="&lt;dsfContact:fDiscloseVoice&gt;:">Exceptional disclosure preference flag of the 
                contact voice telephone number with type="boolean". 
                </t>

                <t hangText="&lt;dsfContact:fDiscloseFax&gt;:">Exceptional disclosure preference flag of the 
                contact facsimile telephone number with type="boolean".   
                </t>

                <t hangText="&lt;dsfContact:fDiscloseEmail&gt;:">Exceptional disclosure preference flag of the 
                contact email address with type="boolean".  
                </t>
                
                <t hangText="&lt;dsfContact:fDiscloseAll&gt;:">Exceptional disclosure preference flag of all of the supported 
                disclose fields with type="boolean".  This single field represents the &lt;dsfContact:fDiscloseFlag&gt; field 
                value for all of the disclose fields, that include &lt;dsfContact:fDiscloseNameLoc&gt;, &lt;dsfContact:fDiscloseNameInt&gt;, 
                &lt;dsfContact:fDiscloseOrgLoc&gt;, &lt;dsfContact:fDiscloseOrgInt&gt;, &lt;dsfContact:fDiscloseAddrLoc&gt;, 
                &lt;dsfContact:fDiscloseAddrInt&gt;, &lt;dsfContact:fDiscloseVoice&gt;, &lt;dsfContact:fDiscloseFax&gt;, 
                and &lt;dsfContact:fDiscloseEmail&gt;.  
                </t>
                
                
                
          </list></t>
                
        <t> 
            The following are example DSF files using the contact object fields.  The different forms of contact 
            object DSF files is up to server policy.  
        </t>
        
        <figure>
             <preamble>Example of a "contact.update.replaceClientStatuses" DSF that will set the client statuses 
             of a contact to those specified in the DSF record.  The client statuses set will be replaced 
             by the set of client statuses specified.  Empty statuses will result in the removal of those 
             statuses if previously set.  Non-empty statuses will be added if not previously set.  Non-empty 
             statuses will result in no change if previously set.  All three client statuses defined 
             in <xref target="RFC5733"/> are defined in the DSF in fixed order.</preamble>

             <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfContact=
  "urn:ietf:params:xml:ns:dsfContact-1.0">
  <dataSet:defData>
    <dataSet:type>
      contact.update.replaceClientStatuses
    </dataSet:type>
    <dataSet:fields>
      <dsfContact:fId/>
      <!-- clientDeleteProhibited -->
      <dsfContact:fStatus/>
      <!-- clientTransferProhibited -->
      <dsfContact:fStatus/>
      <!-- clientUpdateProhibited -->
      <dsfContact:fStatus/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
sh1111,clientDeleteProhibited,,clientUpdateProhibited
sh2222,,clientUpdateProhibited
sh3333,,clientTransferProhibited,
sh4444,,,
-----END DATA SET-----]]></artwork>
          </figure>

        <figure>
             <preamble>Example of a "contact.update.addRemoveStatus" DSF that will add a status and remove 
             a status for each contact.  Any status can be empty to indicate no action for that contact. 
             </preamble>

             <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfContact=
  "urn:ietf:params:xml:ns:dsfContact-1.0">
  <dataSet:defData>
    <dataSet:type>
      contact.update.addRemoveClientStatuses
    </dataSet:type>
    <dataSet:fields>
      <dsfContact:fId/>
      <dsfContact:fStatus op="add"/>
      <dsfContact:fStatus op="remove"/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
sh1111,clientDeleteProhibited,clientUpdateProhibited
sh2222,,clientUpdateProhibited
sh3333,clientUpdateProhibited,
sh4444,clientTransferProhibited,
-----END DATA SET-----]]></artwork>
          </figure>
    
       <figure>
            <preamble>Example of a "contact.create.standard" DSF that supports creating each contact 
            record with a standard set of fields / attributes for a contact.  A &quot;|&quot; character is used 
            as a separator to minimize conflicting with the contact data.  This is an example 
            of creating two contacts, where indented data set lines are a continuation 
            from the prior line. 
            </preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfContact=
  "urn:ietf:params:xml:ns:dsfContact-1.0">
  <dataSet:defData>
    <dataSet:type>
      contact.create.standard
    </dataSet:type>
    <dataSet:fields sep="|">
      <dsfContact:fId/>
      <dsfContact:fPostalType/>
      <dsfContact:fName/>
      <dsfContact:fOrg/>
      <dsfContact:fStreet index="0"/>
      <dsfContact:fStreet index="1"/>
      <dsfContact:fStreet index="2"/>
      <dsfContact:fCity/>
      <dsfContact:fSp/>
      <dsfContact:fPc/>
      <dsfContact:fCc/>
      <dsfContact:fVoice/>
      <dsfContact:fVoiceExt/>
      <dsfContact:fFax/>
      <dsfContact:fFaxExt/>
      <dsfContact:fEmail/>
      <dataSet:fAuthInfo/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
sh1111|int|John Doe|Example Inc.|
  123 Example Dr.|||Dulles|VA|20166-6503|US|
  +1.7035555555|1234|+1.7035555556||
  johndoe@example.com|2fooBAR
sh2222|int|Jane Doe|Example Inc.|
  123 Example Dr.|Suite 2222||Dulles|VA|20166-6503|US|
  +1.7035555555||||
  janedoe@example.com|2fooBAR
-----END DATA SET-----]]></artwork>
          </figure>
   
       <figure>
            <preamble>Example of a "contact.create.routing" DSF that extends 
            the "contact.create.standard" DSF with the <xref target="routing">&lt;dsfContact:fSubProduct&gt; field</xref>  to 
            route the create to the appropriate Top Level Domain (TLD) or group of TLDs.  
            A &quot;|&quot; character is used as a separator to minimize conflicting with the contact data.  
            This is an example of creating two contacts, 
            where indented data set lines are a continuation from the prior line. 
            </preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfContact=
  "urn:ietf:params:xml:ns:dsfContact-1.0"
  xmlns:dsfRouting=
  "urn:ietf:params:xml:ns:dsfRouting-1.0">
  <dataSet:defData>
    <dataSet:type>
      contact.create.routing
    </dataSet:type>
    <dataSet:fields sep="|">
      <dsfRouting:fSubProduct/>
      <dsfContact:fId/>
      <dsfContact:fPostalType/>
      <dsfContact:fName/>
      <dsfContact:fOrg/>
      <dsfContact:fStreet index="0"/>
      <dsfContact:fStreet index="1"/>
      <dsfContact:fStreet index="2"/>
      <dsfContact:fCity/>
      <dsfContact:fSp/>
      <dsfContact:fPc/>
      <dsfContact:fCc/>
      <dsfContact:fVoice/>
      <dsfContact:fVoiceExt/>
      <dsfContact:fFax/>
      <dsfContact:fFaxExt/>
      <dsfContact:fEmail/>
      <dataSet:fAuthInfo/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>   
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
EXAMPLE|sh1111|int|John Doe|Example Inc.|
  123 Example Dr.|||Dulles|VA|20166-6503|US|
  +1.7035555555|1234|+1.7035555556||
  johndoe@example.com|2fooBAR
EXAMPLE|sh2222|int|Jane Doe|Example Inc.|
  123 Example Dr.|Suite 2222||Dulles|VA|20166-6503|US|
  +1.7035555555||||
  janedoe@example.com|2fooBAR
-----END DATA SET-----]]></artwork>
          </figure>
                  
      </section>
    
      <section anchor="verificationCodeObject" title="Verification Code Object">
        <t>
        The Verification Code Object is defined in the <xref
            target="I-D.gould-eppext-verificationcode">Verification Code Extension for the Extensible Provisioning Protocol</xref>.  This section 
            defines the Verification Code specific Data Set File (DSF) field elements and sample DSF files used to set verification codes with a 
            bulk update.
        </t>
        
        <t>
        The Verification Service Provider (VSP) is a certified 
            party to verify that data is in compliance with the policies of a locality.  A 
            locality MAY require the client to have data verified in accordance with 
            local regulations or laws utilizing data sources not available to the server.  The 
            VSP has access to the local data sources and is authorized to verify the data.  Examples 
            include verifying that the domain name is not prohibited and verifying that the 
            domain name registrant is a valid individual, organization, or business in the locality.  
            The data verified, and the objects and operations that require the verification code to be passed 
            to the server is up to the policies of the locality.
            The verification code represents a marker that the verification was completed.  
            The data verified by the VSP MUST be stored by the VSP along with the generated 
            verification codes in order to address any compliance issues.  The signer certificate 
            and the digital signature of the verification code MUST be verified 
            by the server.        
          </t>
        
        <t>The Data Set File (DSF) field elements specific to the Verification Code Object include:</t>
        <t><list hangIndent="4" style="hanging">
        <t hangText="&lt;dsfVerificationCode:fCode&gt;:">
            Field that represents a Verification Code Token value.  The 
            field extends a "dataSet:fieldOptionalType", as defined in <xref target="baseFields"/>, with the type="dataSet:verificationCodeValueType".  The field includes 
            the required "codeType" attribute that represents the type of verification code, as defined by the "type" attribute of the &lt;verificationCode:signedCode&gt; 
            element in <xref target="I-D.gould-eppext-verificationcode"/>.  The verification code field can be empty since it is a 
            "dataSet:fieldOptionalType".   
          </t>
          <t hangText="&lt;dsfVerificationCode:fEncodedSignedCode&gt;:"> 
            Field that represents a Encoded Signed Code. The field 
            extends a "dataSet:fieldOptionalType", as defined in <xref target="baseFields"/>, with the type="token".  The field includes the 
            OPTIONAL "encoding" attribute with the default value of "base64".  The line breaks, defined in <xref target="RFC2045"/>, MUST 
            NOT be used with the "base64" Encoded Signed Code.      
          </t>
        </list></t>
        
        <t>
          The Data Set File (DSF) used for setting of the verification codes MAY include fields from other objects and the fields specific to the 
          Verification Code Object.  There are two scenarios in passing the verification codes based on who generates the DSF file, which includes:
        </t>
          <t><list hangIndent="4" style="hanging">
            <t hangText="VSP Generated DSF:">
              The VSP generates the Verification Code Token values, represented with the &lt;dsfVerificationCode:fCode&gt; field, and 
              digitally signs the DSF file by referencing the &lt;dataSet:encodedSignedDefData&gt; element in the DSF header. 
            </t>
            <t hangText="Client Generated DSF:">
              The client generates the DSF file with a set of encoded signed codes, represented with the &lt;dsfVerificationCode:fEncodedSignedCode&gt; field, 
              collected from the VSP to bulk submit them to the server.  The &lt;dataSet:defData&gt; element, described in <xref target="defData"/>, is 
              referenced in the DSF header. 
            </t>
          </list></t>
          
        <t> 
            The following examples reference verification codes supported by the China Locality, which includes the Domain Name Verification Code (DNVC) 
            and the Real Name Verification Code (RNVC).  Both China Locality verification codes are set on a domain name with the 
            verification code type of "domain" used for the DNVC and the verification code type of "real-name" used for the RNVC.  
            Other localities MAY include a different set of verification codes.
        </t>
        
        <figure>
             <preamble>Example VSP Generated DSF that includes a domain name primary key field, a "domain" 
             code token value field, and a "real-name" token value field.  
             The "base64" value includes "..." representing continuation of data for brevity:</preamble>

             <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0">
  <dataSet:encodedSignedDefData encoding="base64">
  ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z
  ...
  b25Db2RlOnNpZ25lZENvZGU+Cg==
  </dataSet:encodedSignedDefData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,0-abc111,0-abc222
domain2.example,0-abc333,0-abc444
domain3.example,0-abc555,
domain3.example,,0-abc666
-----END DATA SET-----]]></artwork>
          </figure>
          
       <figure>
            <preamble>Example Client Generated Data Set File (DSF) that includes a domain name primary key field, a "domain" 
            encoded signed code field, and a "real-name" encoded signed code field.  
            The "base64" values include no line breaks and include "..." representing continuation of data for brevity:</preamble>

            <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
    "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfDomain=
    "urn:ietf:params:xml:ns:dsfDomain-1.0"
  xmlns:dsfVerificationCode=
    "urn:ietf:params:xml:ns:dsfVerificationCode-1.0"
  >
  <dataSet:defData>
    <dataSet:type subType="china">
      verificationCode.update.encodedSignedCode
    </dataSet:type>
    <dataSet:fields>
      <dsfDomain:fName/>
      <dsfVerificationCode:fEncodedSignedCode type="domain"/>
      <dsfVerificationCode:fEncodedSignedCode type="real-name"/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>
    <dataSet:crDate>2016-04-03T22:00:00.0Z</dataSet:crDate>
  </dataSet:defData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,ICAg...GlvbkN,CAgICA...uOmlldG
domain2.example,YW1zOb2R...GlvbkNvZGU6c2ln,
domain3.example,,CAgICAnZ...htbDpZmljYXMCIKI
-----END DATA SET-----]]></artwork>
          </figure>
        
      </section>
    
    </section>
    
    <section anchor="resultCodes" title="Result Codes">
      <t>The result codes are based on and not equal to the reply codes defined in 
      the EPP result codes of <xref target="RFC5730"/>.  Four decimal digits are used 
      to describe the success or failure of the processing of the Data Set File (DSF) 
      or the processing of an individual record.  Each digit of the 
      result code has specific significance.</t>
      <t>The first digit denotes success or failure.  The second digit denotes the result 
      category, such as request syntax or security.  The third and fourth digits 
      provide explicit response detail within each result category.
      </t>
      <t>There are two values for the first digit of the result code:</t>
      <t><list hangIndent="4" style="hanging">
          <t hangText="1yzz:">Positive result.  The file or record was processed 
          by the system successfully.  Partial successful results MAY be 
          included.</t>
          <t hangText="2yzz:">Negative result.  The file or record was not 
          processed successfully.  Partial successful results MAY NOT be included.
          </t>  
        </list></t>
        <t>The second digit groups responses into one of five specific categories:
        </t>
      <t><list hangIndent="6" style="hanging">
          <t hangText="x0zz:">File or record syntax</t>
          <t hangText="x1zz:">Implementation-specific rules</t>
          <t hangText="x2zz:">Security</t>
          <t hangText="x3zz:">Data Management</t>
          <t hangText="x4zz:">Server System</t>
        </list></t>
        
        <t>Successful result codes:
        </t>
      <t><list hangIndent="6" style="hanging">
          <t hangText="1000&nbsp;&nbsp;&quot;Success&quot;:"><vspace/>This is the result for a successfully processed file when all records are processed successfully or the result for an individual record that is successfully processed.<vspace blankLines="1"/></t>
          <t hangText="1001&nbsp;&nbsp;&quot;Success with failures&quot;:"><vspace/>This is the result for a successfully processed file when some records are processed successfully and some records failed.<vspace blankLines="1"/></t>
          <t hangText="1002&nbsp;&nbsp;&quot;Success with all failures&quot;:"><vspace/>This is the result for a successfully processed file when all of the records failed.<vspace blankLines="1"/></t>
        </list></t>
        
        <t>Error result codes:
        </t>
      <t><list hangIndent="6" style="hanging">
          <t hangText="2000&nbsp;&nbsp;&quot;File syntax error&quot;:"><vspace/>This result code occurs when the overall file is syntactically incorrect.<vspace blankLines="1"/></t>
          <t hangText="2001&nbsp;&nbsp;&quot;Header syntax error&quot;:"><vspace/>This result code occurs when the header is syntactically incorrect.<vspace blankLines="1"/></t>
          <t hangText="2002&nbsp;&nbsp;&quot;Body syntax error&quot;:"><vspace/>This result code occurs when the body is syntactically incorrect.<vspace blankLines="1"/></t>
          <t hangText="2003&nbsp;&nbsp;&quot;Required parameter missing&quot;:"><vspace/>This result code occurs when a server receives a request for which a required parameter has not been provided.<vspace blankLines="1"/></t>
          <t hangText="2004&nbsp;&nbsp;&quot;Parameter value range error&quot;:"><vspace/>This result code occurs when a server receives a request whose value is outside the range of values specified in the protocol.<vspace blankLines="1"/></t>
          <t hangText="2005&nbsp;&nbsp;&quot;Parameter value syntax error&quot;:"><vspace/>This result code occurs when a server receives a request whose value is improperly formed.<vspace blankLines="1"/></t>
          <t hangText="2100&nbsp;&nbsp;&quot;Unimplemented protocol version&quot;:"><vspace/>This result code occurs when a server receives a request version, as defined by the XML namespace of the header, that is not implemented by the server.<vspace blankLines="1"/></t>
          <t hangText="2102&nbsp;&nbsp;&quot;Unimplemented option&quot;:"><vspace/>This result code occurs when a server receives a request that contains a protocol option that is not implemented by the server.<vspace blankLines="1"/></t>
          <t hangText="2103&nbsp;&nbsp;&quot;Unimplemented extension&quot;:"><vspace/>This result code occurs when a server receives a request that contains an extension, as defined by the XML namespace used by a field element extension, that is not implemented by the server.<vspace blankLines="1"/></t>
          <t hangText="2104&nbsp;&nbsp;&quot;Billing failure&quot;:"><vspace/>This result code occurs when a server receives a request that cannot be completed due to a client-billing failure.<vspace blankLines="1"/></t>
          <t hangText="2201&nbsp;&nbsp;&quot;Authorization error&quot;:"><vspace/>This result code occurs when a server receives a request cannot be execute due to a client-authorization error.<vspace blankLines="1"/></t>
          <t hangText="2202&nbsp;&nbsp;&quot;Invalid authorization information&quot;:"><vspace/>This result code occurs when a server receives invalid authorization information to execute a request.<vspace blankLines="1"/></t>
          <t hangText="2302&nbsp;&nbsp;&quot;Object exists&quot;:"><vspace/>This result code occurs when a server receives a request to create an object that already exists in the repository.<vspace blankLines="1"/></t>
          <t hangText="2303&nbsp;&nbsp;&quot;Object does not exist&quot;:"><vspace/>This result code occurs when a server receives a request to transform an object that does not exist in the repository.<vspace blankLines="1"/></t>
          <t hangText="2304&nbsp;&nbsp;&quot;Object status prohibits operation&quot;:"><vspace/>This result code occurs when a server receives a request to transform an object that cannot be completed due to server policy or business practices.<vspace blankLines="1"/></t>
          <t hangText="2305&nbsp;&nbsp;&quot;Object association prohibits operation&quot;:"><vspace/>This result code occurs when a server receives a request to transform an object that cannot be completed due to dependencies to other objects that are associated with the target object.<vspace blankLines="1"/></t>
          <t hangText="2306&nbsp;&nbsp;&quot;Parameter value policy error&quot;:"><vspace/>This result code occurs when a server receives a request that contains a parameter value that is syntactically valid but semantically invalid due to local policy.<vspace blankLines="1"/></t>
          <t hangText="2307&nbsp;&nbsp;&quot;Unimplemented object service&quot;:"><vspace/>This result code occurs when a server receives a request to operate on an object that is not supported by the server.<vspace blankLines="1"/></t>
          <t hangText="2308&nbsp;&nbsp;&quot;Data management policy violation&quot;:"><vspace/>This result code occurs when a server receives a request whose execution results in a violation of server data management policies.<vspace blankLines="1"/></t>
          <t hangText="2400&nbsp;&nbsp;&quot;Request failed&quot;:"><vspace/>This result code occurs when a server receives a request that cannot be executed due to an internal server error that is not related to the protocol.<vspace blankLines="1"/></t>
        </list></t>
        
        <t>The error result codes include some overlap that will require the server to decide which one to return based on server policy.  For example, 
        a "Header syntax error", represented by the error result code 2001, may have occured for multiple reasons including a 2003 "Required parameter missing", 
        a 2004 "Parameter value range error", or a 2005 "Parameter value syntax error".  The overlapping reasons also apply at the record level, 
        where an object may be syntactically incorrect with a 2005 "Parameter value syntax error", and also be against server policy with 
        a 2306 "Parameter value policy error".  The server SHOULD attempt to provide the most accurate error result code to match the 
        error.  For example, a syntax error defined by the protocol SHOULD take precedence over a server policy error.</t>
          
    </section>
    
    <section anchor="exampleDataSetResultFiles" title="Example Data Set File (DSF) Result Files">
    
       <t>
       This section includes a set of Data Set File (DSF) result examples.  
       </t>
    
       <section anchor="exampleResultData" title="Example Data Set File (DSF) with Result Data">
    
        <t>
          This section includes example Data Set File (DSF) files that reference the &lt;dataSet:resultData&gt; element, described in <xref target="resultData"/>, 
          for providing the meta-data about the result file, along with a set of fields that reference the &lt;dataSet:fResultCode&gt; field element, 
          described in <xref target="dataSetFieldElements"/>, for including the result code in processing the domain name record in the request.   
        </t>
    
      <figure>
           <preamble>Example Data Set File (DSF) for a succesful result by the server:</preamble>

           <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
    "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfDomain=
    "urn:ietf:params:xml:ns:dsfDomain-1.0">
  <dataSet:resultData code="1000">
    <dataSet:fields>
       <dsfDomain:fName/>
       <dataSet:fResultCode/>
       <dataSet:fResultMsg/>
       <dataSet:fResultReason/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>
    <dataSet:svTRID>54322-XYZ</dataSet:svTRID>
    <dataSet:msg>Code Set processed successfully.</dataSet:msg>
    <dataSet:records>
      <dataSet:total>2</dataSet:total>
      <dataSet:success>2</dataSet:success>
      <dataSet:failed>0</dataSet:failed>
    </dataSet:records>
  </dataSet:resultData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,1000,,
domain2.example,1000,,
-----END DATA SET-----]]></artwork>
          </figure>
    
      <figure>
           <preamble>Example Data Set File (DSF) for a partially successful result by the server:</preamble>

           <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
    "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsfDomain=
    "urn:ietf:params:xml:ns:dsfDomain-1.0">
  <dataSet:resultData code="1001">
    <dataSet:fields>
      <dsfDomain:fName/>
      <dataSet:fResultCode/>
      <dataSet:fResultMsg/>
      <dataSet:fResultReason/>
    </dataSet:fields>
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>
    <dataSet:svTRID>54322-XYZ</dataSet:svTRID>
    <dataSet:msg>Success with failures</dataSet:msg>
    <dataSet:records>
      <dataSet:total>4</dataSet:total>
      <dataSet:success>1</dataSet:success>
      <dataSet:failed>3</dataSet:failed>
    </dataSet:records>    
  </dataSet:resultData>
</dataSet:definition>
-----BEGIN DATA SET-----
domain1.example,1000,Success,
domain2.example,2303,Object does not exist,
domain3.example,2201,Authorization error,
domain4.example,2302,Object exists,domain code already set
-----END DATA SET-----]]></artwork>
          </figure>
    
      <figure>
           <preamble>Example Data Set File (DSF) for a failure result by the server:</preamble>

           <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<dataSet:definition
  xmlns:dataSet=
  "urn:ietf:params:xml:ns:dataSet-1.0">
  <dataSet:resultData code="2000">
    <dataSet:dataSetId>abc-123</dataSet:dataSetId>
    <dataSet:svTRID>54322-XYZ</dataSet:svTRID>
    <dataSet:msg>File syntax error</dataSet:msg>
    <dataSet:reason lang="en">Malformed request file
    </dataSet:reason>
  </dataSet:resultData>
</dataSet:definition>
-----BEGIN DATA SET-----
-----END DATA SET-----]]></artwork>
          </figure>
    
       </section>

    </section> 

    <section anchor="syntax" title="Formal Syntax">
    
      <t>Each schema is included in a sub-section, starting with the Data Set schema and 
        followed by each object 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="Data Set Schema">

    <t>Data Set schema that represents the base XML schema for the Data Set File (DSF).</t>
    
        <figure>
          <artwork><![CDATA[
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema 
  targetNamespace=
    "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dataSet=
    "urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">
  
  <annotation>
    <documentation>
      Data Set XML Schema
    </documentation>
  </annotation>

  <import namespace="http://www.w3.org/2000/09/xmldsig#"
    schemaLocation="xmldsig-core-schema.xsd"/>

  <element name="definition" 
    type="dataSet:definitionType"/>

  <complexType name="definitionType">
    <sequence>
       <choice>
        <element name="encodedSignedDefData" 
          type="dataSet:encodedSignedDefDataType"/>
        <element name="defData" 
          type="dataSet:defDataType"/>
        <element name="resultData" 
          type="dataSet:resultDataType"/>
      </choice>
    </sequence>
  </complexType>
  
  <!-- field seperator must be a single character -->
  <simpleType name="sepType">
    <restriction base="string">
      <minLength value="1"/>
      <maxLength value="1"/>
    </restriction>
  </simpleType>
  
  <!-- Ordered list of field definitions for the csv --> 
  <complexType name="fieldsType">
    <sequence maxOccurs="unbounded">
      <element ref="dataSet:field"/>
    </sequence>
    <attribute name="sep" type="dataSet:sepType" default=","/>    
  </complexType>  
    
  <!-- defDataType -->
  <complexType name="defDataType">
    <sequence>
      <element name="type" 
        type="dataSet:typeType"/>
      <element name="fields" 
        type="dataSet:fieldsType"/>
      <element name="dataSetId" 
        type="dataSet:IdType"/>
      <element name="crDate" 
        type="dateTime"/>
    </sequence>
  </complexType>
  
  <!-- typeType -->
  <complexType name="typeType">
    <simpleContent>
      <extension base="token">
        <attribute name="subType" type="token"/>
      </extension>
    </simpleContent>
  </complexType>
  
  <!-- signedData -->
  <element name="signedDefData" 
    type="dataSet:signedDefDataType"/>
    
  <complexType name="signedDefDataType">
    <complexContent>
      <extension base="dataSet:defDataType">
        <sequence>
          <element name="cksum" 
            type="token"/>
          <element ref="dsig:Signature"/>
        </sequence>
        <attribute name="id" type="ID" use="required"/>
      </extension>
    </complexContent>
  </complexType>
  
  <!-- resultDataType -->
  <complexType name="resultDataType">
    <sequence>
      <element name="type" 
        type="dataSet:typeType"
        minOccurs="0"/>
      <element name="fields" 
        type="dataSet:fieldsType"
        minOccurs="0"/>
      <element name="dataSetId" 
        type="dataSet:IdType"
        minOccurs="0"/>
      <element name="svTRID" 
        type="dataSet:IdType"/>
      <element name="msg" 
        type="dataSet:msgType"/>
      <element name="reason" 
        type="dataSet:msgType" 
        minOccurs="0"/>
      <element name="records" 
        type="dataSet:recordsType"
        minOccurs="0"/>
    </sequence>
    <attribute name="code" type="dataSet:resultCodeType"
      use="required"/>    
  </complexType>

  <complexType name="recordsType"> 
    <sequence>
      <element name="total" type="unsignedInt"/>
      <element name="success" type="unsignedInt"/>
      <element name="failed" type="unsignedInt"/>
    </sequence>
  </complexType>

  <simpleType name="resultCodeType">
    <restriction base="unsignedShort">
      <!-- Success -->
      <enumeration value="1000"/>
      <!-- Success with failures -->
      <enumeration value="1001"/>
      <!-- Success with all failures -->
      <enumeration value="1002"/>
      <!-- File syntax error -->
      <enumeration value="2000"/>
      <!-- Invalid header -->
      <enumeration value="2001"/>
      <!-- Invalid body -->
      <enumeration value="2002"/>
      <!-- Required parameter missing -->
      <enumeration value="2003"/>
      <!-- Parameter value range error -->
      <enumeration value="2004"/>
      <!-- Parameter value syntax error -->
      <enumeration value="2005"/>
      <!-- Unimplemented protocol version -->
      <enumeration value="2100"/>
      <!-- Unimplemented option -->
      <enumeration value="2102"/>
      <!-- Unimplemented extension -->
      <enumeration value="2103"/>
      <!-- Billing failure -->
      <enumeration value="2104"/>
      <!-- Authorization error -->
      <enumeration value="2201"/>
      <!-- Invalid authorization information -->
      <enumeration value="2202"/>
      <!-- Object exists -->
      <enumeration value="2302"/>
      <!-- Object does not exist -->
      <enumeration value="2303"/>
      <!-- Object status prohibits operation -->
      <enumeration value="2304"/>
      <!-- Object association prohibits operation -->
      <enumeration value="2305"/>
      <!-- Parameter value policy error -->
      <enumeration value="2306"/>
      <!-- Unimplemented object service -->
      <enumeration value="2307"/>
      <!-- Data management policy violation -->
      <enumeration value="2308"/>
      <!-- Request failed -->
      <enumeration value="2400"/>
    </restriction>
  </simpleType>
    
  <simpleType name="IdType">
    <restriction base="token">
      <minLength value="3"/>
      <maxLength value="64"/>
    </restriction>
  </simpleType>

  <complexType name="msgType">
    <simpleContent>
      <extension base="normalizedString">
        <attribute name="lang" type="language"
          default="en"/>
      </extension>
    </simpleContent>
  </complexType>
  
  
  <!-- encodedSignedData -->
  <element name="encodedSignedDefData" 
    type="dataSet:encodedSignedDefDataType"/>
  
  <complexType name="encodedSignedDefDataType">
    <simpleContent>
      <extension base="token">
        <attribute name="encoding" 
          type="token" default="base64"/>
      </extension>
    </simpleContent>
  </complexType>
  
  
  <!-- Abstract field type -->
  <element name="field" type="dataSet:fieldType" 
    abstract="true"/>
  
  <complexType name="fieldType">
    <sequence/>
  </complexType>
  
  <!-- fieldType with optional value (isRequired=false) -->  
  <complexType name="fieldOptionalType">
    <complexContent>
      <extension base="dataSet:fieldType">
        <sequence/>
        <attribute name="isRequired" type="boolean" 
          default="false"/>
        <attribute name="isPrimaryKey" type="boolean" 
          default="false"/>
      </extension>
    </complexContent>
  </complexType>
 
 <!-- fieldType with required value (isRequired=false) -->  
 <complexType name="fieldRequiredType">
  <complexContent>
    <extension base="dataSet:fieldType">
      <sequence/>
      <attribute name="isRequired" type="boolean" 
        default="true"/>
      <attribute name="isPrimaryKey" type="boolean" 
        default="false"/>
    </extension>
  </complexContent>
 </complexType>
  
 <!-- fieldType as primary key field (isPrimaryKey=true) -->  
 <complexType name="fieldPrimaryKeyType">
   <complexContent>
     <extension base="dataSet:fieldType">
       <sequence/>
       <attribute name="isRequired" type="boolean" 
         default="true"/>
       <attribute name="isPrimaryKey" type="boolean" 
         default="true"/>
     </extension>
   </complexContent>
 </complexType>
  
 <!-- fieldType as list item -->  
 <complexType name="fListItemType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="op" 
         type="dataSet:listItemOpType"  
         default="replace"/>
     </extension>
   </complexContent>
 </complexType>
  
 <!-- Enumerated list item "op" attribute values -->
 <simpleType name="listItemOpType">
   <restriction base="token">
     <enumeration value="replace"/>
     <enumeration value="add"/>
     <enumeration value="remove"/>
   </restriction>
 </simpleType>
  
 <complexType name="fNameRequiredType">
   <complexContent>
     <extension base="dataSet:fieldRequiredType">
       <sequence/>
       <attribute name="type" type="token"  
         default="eppcom\:labelType"/>
     </extension>
   </complexContent>
 </complexType>
 
 <element name="fName" type="dataSet:fNameType" 
   substitutionGroup="dataSet:field"/>
     
 <complexType name="fNameType">
   <complexContent>
     <extension base="dataSet:fieldPrimaryKeyType">
       <sequence/>
       <attribute name="type" type="token"  
         default="dataSet\:labelType"/>
       <attribute name="class" type="token"  
         use="required"/>
     </extension>
   </complexContent>
 </complexType>
 
 <!-- Authorization Information field -->
 <element name="fAuthInfo" type="dataSet:fAuthInfoType" 
   substitutionGroup="dataSet:field"/>
 
 <complexType name="fAuthInfoType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="eppcom\:pwAuthInfoType"/>
     </extension>
   </complexContent>
 </complexType>
 
 
 <!-- General token type -->
 <complexType name="fTokenType">
  <complexContent>
    <extension base="dataSet:fieldOptionalType">
      <sequence/>
      <attribute name="type" type="token"  
        default="token"/>
    </extension>
  </complexContent>
 </complexType>
 
 <!-- boolean type -->
 <complexType name="fBooleanType">
  <complexContent>
    <extension base="dataSet:fieldOptionalType">
      <sequence/>
      <attribute name="type" type="token"  
        default="boolean"/>
    </extension>
  </complexContent>
 </complexType>
      
 <!-- fResultCode field -->
 <element name="fResultCode" 
   type="dataSet:fResultCodeType" 
   substitutionGroup="dataSet:field"/>   
 <complexType name="fResultCodeType">
   <complexContent>
     <extension base="dataSet:fieldRequiredType">
       <sequence/>
       <attribute name="type" type="token"  
         default="dataSet\:resultCodeType"/>
     </extension>
   </complexContent>
 </complexType>
  
 <!-- fResultMsg field -->
 <element name="fResultMsg" 
   type="dataSet:fResultMsgType" 
   substitutionGroup="dataSet:field"/>   
 <complexType name="fResultMsgType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="normalizedString"/>
       <attribute name="lang" type="language"  
         default="en"/>
     </extension>
   </complexContent>
 </complexType>
  
 <!-- fResultReason field -->
 <element name="fResultReason" 
   type="dataSet:fResultReasonType" 
   substitutionGroup="dataSet:field"/>   
 <complexType name="fResultReasonType">
  <complexContent>
    <extension base="dataSet:fieldOptionalType">
      <sequence/>
      <attribute name="type" type="token"  
        default="normalizedString"/>
      <attribute name="lang" type="language"  
        default="en"/>
    </extension>
  </complexContent>
 </complexType>
 
 <!-- unsignedByte type -->
 <complexType name="fUnsignedByteType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="unsignedByte"/>
     </extension>
   </complexContent>
 </complexType>

 <!-- unsignedShort type -->
 <complexType name="fUnsignedShortType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="unsignedShort"/>
     </extension>
   </complexContent>
 </complexType>

 <!-- hexBinary type -->
 <complexType name="fHexBinaryType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="hexBinary"/>
     </extension>
   </complexContent>
 </complexType>
 
</schema>
END]]></artwork>
        </figure>
  </section>
      
    <section title="Domain Name Schema">
    
      <t>Domain Name Object XML schema that defines the fields specific to the Domain Name Object.</t>

      <figure>
        <artwork><![CDATA[
BEGIN
<?xml version="1.0" encoding="UTF-8"?>

<schema targetNamespace="urn:ietf:params:xml:ns:dsfDomain-1.0"
       xmlns:dsfDomain="urn:ietf:params:xml:ns:dsfDomain-1.0"
       xmlns:dataSet="urn:ietf:params:xml:ns:dataSet-1.0"
       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
       xmlns="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified">

  <!--
  Import common element types
  -->
  <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
    schemaLocation="eppcom-1.0.xsd"/>
  <import namespace="urn:ietf:params:xml:ns:domain-1.0"
    schemaLocation="domain-1.0.xsd"/>
  <import namespace="urn:ietf:params:xml:ns:secDNS-1.1"
    schemaLocation="secDNS-1.1.xsd"/>
  <import namespace="urn:ietf:params:xml:ns:dataSet-1.0"
    schemaLocation="dataSet-1.0.xsd"/>

  <annotation>
   <documentation>
    Domain Name Data Set File (DSF) Object 
   </documentation>
  </annotation>
  
 <!-- Domain name field -->
 <element name="fName" type="dataSet:fNameRequiredType" 
   substitutionGroup="dataSet:field"/>
        
 <!-- Registration Period -->
 <element name="fPeriod" type="dsfDomain:fPeriodType" 
   substitutionGroup="dataSet:field"/>
 
 <complexType name="fPeriodType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="domain\:pLimitType"/>
     </extension>
   </complexContent>
 </complexType>
    
 <!-- Registration Period Unit -->
 <element name="fPeriodUnit" type="dsfDomain:fPeriodUnitType" 
   substitutionGroup="dataSet:field"/>
 
 <complexType name="fPeriodUnitType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="domain\:pUnitType"/>
     </extension>
   </complexContent>
 </complexType>
    
 <!-- Contact field -->
 <element name="fContact" type="dsfDomain:fContactsType" 
   substitutionGroup="dataSet:field"/>
 
 <complexType name="fContactsType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="dataSet\:contactRoleType"/>
       <attribute name="role" type="dsfDomain:contactRoleType" 
         use="required"/>
     </extension>
   </complexContent>
 </complexType>

 <simpleType name="contactRoleType">
   <restriction base="token">
     <enumeration value="registrant"/>
     <enumeration value="admin"/>
     <enumeration value="tech"/>
     <enumeration value="billing"/>
   </restriction>
 </simpleType>

 <!-- Domain name server -->
 <element name="fNs" type="dsfDomain:fNsType" 
   substitutionGroup="dataSet:field"/>
 
 <complexType name="fNsType">
   <complexContent>
     <extension base="dataSet:fListItemType">
       <sequence/>
       <attribute name="type" type="token"  
         default="domain\:pLimitType"/>
     </extension>
   </complexContent>
 </complexType>

 <!-- DNSSEC field types -->
 
 <!-- Maximum signature lifetime field -->
 <element name="fMaxSigLife" type="dsfDomain:fMaxSigLifeType" 
   substitutionGroup="dataSet:field"/>
 <complexType name="fMaxSigLifeType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="secDNS\:maxSigLifeType"/>
     </extension>
   </complexContent>
 </complexType>

 <!-- Key tag field -->
 <element name="fKeyTag" type="dataSet:fUnsignedShortType" 
   substitutionGroup="dataSet:field"/>

 <!-- DS Algorithm field -->
 <element name="fDsAlg" type="dataSet:fUnsignedByteType" 
   substitutionGroup="dataSet:field"/>
 
 <!-- Digest type field -->
 <element name="fDigestType" type="dataSet:fUnsignedByteType" 
   substitutionGroup="dataSet:field"/>

 <!-- Digest field -->
 <element name="fDigest" type="dataSet:fHexBinaryType" 
   substitutionGroup="dataSet:field"/>
 
 <!-- Flags field -->
 <element name="fFlags" type="dataSet:fUnsignedShortType" 
   substitutionGroup="dataSet:field"/>
 
 <!-- Protocol field -->
 <element name="fProtocol" type="dataSet:fUnsignedByteType" 
   substitutionGroup="dataSet:field"/>

 <!-- Key Algorithm field -->
 <element name="fKeyAlg" type="dataSet:fUnsignedByteType" 
   substitutionGroup="dataSet:field"/>

 <!-- Public Key field -->
 <element name="fPubKey" type="dsfDomain:fPubKeyType" 
   substitutionGroup="dataSet:field"/>
 <complexType name="fPubKeyType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="secDNS\:keyType"/>
     </extension>
   </complexContent>
 </complexType>
    
 <!-- Domain status field -->
 <element name="fStatus" type="dsfDomain:fStatusType" 
   substitutionGroup="dataSet:field"/>

 <!-- Domain status based on domain-1.0.xsd  -->
 <complexType name="fStatusType">
   <complexContent>
     <extension base="dataSet:fListItemType">
       <sequence/>
       <attribute name="type" type="token"  
         default="domain\:statusValueType"/>
     </extension>
   </complexContent>
 </complexType>
  
  <!--
  End of schema.
  -->
</schema>
END]]></artwork>
        </figure>
    </section>      

    <section title="Host Schema">
    
      <t>Host Object XML schema that defines the fields specific to the Host Object.</t>

      <figure>
        <artwork><![CDATA[
BEGIN
<?xml version="1.0" encoding="UTF-8"?>

<schema targetNamespace="urn:ietf:params:xml:ns:dsfHost-1.0"
       xmlns:dsfHost="urn:ietf:params:xml:ns:dsfHost-1.0"
       xmlns:dataSet="urn:ietf:params:xml:ns:dataSet-1.0"
       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
       xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
       xmlns="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified">

  <!--
  Import common element types
  -->
  <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
    schemaLocation="eppcom-1.0.xsd"/>
  <import namespace="urn:ietf:params:xml:ns:host-1.0"
    schemaLocation="host-1.0.xsd"/>
  <import namespace="urn:ietf:params:xml:ns:dataSet-1.0"
    schemaLocation="dataSet-1.0.xsd"/>

  <annotation>
   <documentation>
    Host Name Data Set File (DSF) Object 
   </documentation>
  </annotation>  

 <!-- Host name field -->
 <element name="fName" type="dataSet:fNameRequiredType" 
  substitutionGroup="dataSet:field"/>

 <!-- Host new name field -->
 <element name="fNewName" type="dsfHost:fNewNameType" 
  substitutionGroup="dataSet:field"/> 
 
 <complexType name="fNewNameType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="eppcom\:labelType"/>
     </extension>
   </complexContent>
 </complexType>
 
 <!-- IP address field -->
 <element name="fAddr" type="dsfHost:fAddrType" 
   substitutionGroup="dataSet:field"/>
 
 <complexType name="fAddrType">
   <complexContent>
     <extension base="dataSet:fListItemType">
       <sequence/>
       <attribute name="type" type="token"  
         default="host\:addrStringType"/>
     </extension>
   </complexContent>
 </complexType>
 
 <!-- IP address version field linked to the fAddr field -->
 <element name="fAddrVersion" type="dsfHost:fAddrVersionType" 
  substitutionGroup="dataSet:field"/>
 <complexType name="fAddrVersionType">
  <complexContent>
    <extension base="dataSet:fListItemType">
      <sequence/>
      <attribute name="type" type="token"  
        default="host\:ipType"/>
    </extension>
  </complexContent>
 </complexType>

 <!-- Host status field -->
 <element name="fStatus" type="dsfHost:fStatusType" 
   substitutionGroup="dataSet:field"/>

 <!-- Host status based on host-1.0.xsd  -->
 <complexType name="fStatusType">
   <complexContent>
     <extension base="dataSet:fListItemType">
       <sequence/>
       <attribute name="type" type="token"  
         default="host\:statusValueType"/>
     </extension>
   </complexContent>
 </complexType>

  <!--
  End of schema.
  -->
</schema>
END]]></artwork>
        </figure>
    </section>      

    <section title="Contact Schema">
    
      <t>Contact Object XML schema that defines the fields specific to the Contact Object.</t>

      <figure>
        <artwork><![CDATA[
BEGIN
<?xml version="1.0" encoding="UTF-8"?>

<schema targetNamespace="urn:ietf:params:xml:ns:dsfContact-1.0"
    xmlns:dsfContact="urn:ietf:params:xml:ns:dsfContact-1.0"
    xmlns:dataSet="urn:ietf:params:xml:ns:dataSet-1.0"
    xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
    xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
    xmlns="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified">

<!--
Import common element types.
-->
 <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
   schemaLocation="eppcom-1.0.xsd"/>
 <import namespace="urn:ietf:params:xml:ns:contact-1.0"
   schemaLocation="contact-1.0.xsd"/>
 <import namespace="urn:ietf:params:xml:ns:dataSet-1.0"
   schemaLocation="dataSet-1.0.xsd"/>

 <annotation>
   <documentation>
     Contact Data Set File (DSF) Object 
   </documentation>
 </annotation>


 <!-- Server-unique contact identifier field -->
 <element name="fId" type="dsfContact:fIdType" 
  substitutionGroup="dataSet:field"/>
 <complexType name="fIdType">
  <complexContent>
    <extension base="dataSet:fieldRequiredType">
      <sequence/>
      <attribute name="type" type="token"  
      default="eppcom\:clIDType"/>
    </extension>
  </complexContent>
 </complexType>
 
  
 <!-- Is Registrar Contact field -->
 <element name="fIsRegistrarContact" 
  type="dataSet:fBooleanType" 
  substitutionGroup="dataSet:field"/>


 <!-- voice and fax telephone number fields -->
 <element name="fVoice" type="dsfContact:fE164StringType" 
  substitutionGroup="dataSet:field"/>
 <element name="fFax" type="dsfContact:fE164StringType" 
  substitutionGroup="dataSet:field"/>
 <complexType name="fE164StringType">
  <complexContent>
    <extension base="dataSet:fieldOptionalType">
      <sequence/>
      <attribute name="type" type="token"  
      default="contact\:e164StringType"/>
    </extension>
  </complexContent>
 </complexType>

 <!-- voice and fax telephone extension fields -->
 <element name="fVoiceExt" type="dataSet:fTokenType" 
  substitutionGroup="dataSet:field"/>
 <element name="fFaxExt" type="dataSet:fTokenType" 
  substitutionGroup="dataSet:field"/>

 <!-- contact email address field -->
 <element name="fEmail" type="dsfContact:fEmailType" 
  substitutionGroup="dataSet:field"/>
 <complexType name="fEmailType">
  <complexContent>
    <extension base="dataSet:fieldRequiredType">
      <sequence/>
      <attribute name="type" type="token"  
      default="eppcom\:minTokenType"/>
    </extension>
  </complexContent>
 </complexType>



 <!-- 
   Postal type field
   ("loc" = localized, "int" = internationalized)  
 -->
 <element name="fPostalType" type="dsfContact:fPostalTypeType" 
  substitutionGroup="dataSet:field"/>
 <complexType name="fPostalTypeType">
  <complexContent>
    <extension base="dataSet:fieldOptionalType">
      <sequence/>
      <attribute name="type" type="token"  
      default="contact\:postalInfoEnumType"/>
    </extension>
  </complexContent>
 </complexType>

 <!-- Standard postal line field -->
 <complexType name="fPostalLineType">
  <complexContent>
    <extension base="dataSet:fieldRequiredType">
      <sequence/>
      <attribute name="type" type="token"  
      default="contact\:postalLineType"/>
      <attribute name="isLoc" type="boolean"/>
    </extension>
  </complexContent>
 </complexType>

 <!-- Standard optional postal line field -->
 <complexType name="fOptPostalLineType">
  <complexContent>
    <extension base="dataSet:fieldOptionalType">
      <sequence/>
      <attribute name="type" type="token"  
      default="contact\:optPostalLineType"/>
      <attribute name="isLoc" type="boolean"/>
    </extension>
  </complexContent>
 </complexType>

 <!-- Name of the individual or role field -->
 <element name="fName" type="dsfContact:fPostalLineType" 
  substitutionGroup="dataSet:field"/>
  

 <!-- Name organization field -->
 <element name="fOrg" type="dsfContact:fOptPostalLineType" 
  substitutionGroup="dataSet:field"/>


 <!-- Street address line field with required index attribute  -->
 <!-- starting with index 0.  -->
 <element name="fStreet" type="dsfContact:fStreetType" 
  substitutionGroup="dataSet:field"/>
 <complexType name="fStreetType">
  <complexContent>
    <extension base="dsfContact:fOptPostalLineType">
      <sequence/>
      <attribute name="index" type="int"  
      use="required"/>
    </extension>
  </complexContent>
 </complexType>
 
 <!-- Contact's city field -->
 <element name="fCity" type="dsfContact:fPostalLineType" 
  substitutionGroup="dataSet:field"/>
 
 <!-- Contact's state or province field -->
 <element name="fSp" type="dsfContact:fOptPostalLineType" 
  substitutionGroup="dataSet:field"/>

 <!-- Contact's postal code field -->
 <element name="fPc" type="dsfContact:fPcType" 
  substitutionGroup="dataSet:field"/>
 <complexType name="fPcType">
  <complexContent>
    <extension base="dataSet:fieldOptionalType">
      <sequence/>
      <attribute name="type" type="token"  
      default="contact\:pcType"/>
      <attribute name="isLoc" type="boolean"/>
    </extension>
  </complexContent>
 </complexType>
 
 <!-- Contact's country code field -->
 <element name="fCc" type="dsfContact:fCcType" 
  substitutionGroup="dataSet:field"/>
 <complexType name="fCcType">
  <complexContent>
    <extension base="dataSet:fieldRequiredType">
      <sequence/>
      <attribute name="type" type="token"  
      default="contact\:ccType"/>
      <attribute name="isLoc" type="boolean"/>
    </extension>
  </complexContent>
 </complexType>

 <!-- Disclosure element fields -->
 <!-- Flag of "1" to allow disclosure 
      and "0" to disallow disclosure -->
 <element name="fDiscloseFlag" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <!-- Disclosure of localized name 
      based on fDiscloseFlag? -->
 <element name="fDiscloseNameLoc" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <!-- Disclosure of internationalized name 
      based on fDiscloseFlag? -->
 <element name="fDiscloseNameInt" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <!-- Disclosure of localized org 
      based on fDiscloseFlag? -->
 <element name="fDiscloseOrgLoc" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <!-- Disclosure of internationalized org 
      based on fDiscloseFlag? -->
 <element name="fDiscloseOrgInt" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <!-- Disclosure of localized address 
      based on fDiscloseFlag? -->
 <element name="fDiscloseAddrLoc" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <!-- Disclosure of internationalized address 
      based on fDiscloseFlag? -->
 <element name="fDiscloseAddrInt" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <!-- Disclosure voice telephone number 
      based on fDiscloseFlag? -->
 <element name="fDiscloseVoice" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <!-- Disclosure facsimile telephone number 
      based on fDiscloseFlag? -->
 <element name="fDiscloseFax" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <!-- Disclosure email address 
      based on fDiscloseFlag? -->
 <element name="fDiscloseEmail" type="dsfContact:fBoolean" 
  substitutionGroup="dataSet:field"/>
 <complexType name="fBoolean">
  <complexContent>
    <extension base="dataSet:fieldOptionalType">
      <sequence/>
      <attribute name="type" type="token"  
      default="boolean"/>
    </extension>
  </complexContent>
 </complexType>
 
 <!-- Contact status field -->
 <element name="fStatus" type="dsfContact:fStatusType" 
  substitutionGroup="dataSet:field"/>

 <!-- Host status based on contact-1.0.xsd  -->
 <complexType name="fStatusType">
  <complexContent>
    <extension base="dataSet:fListItemType">
      <sequence/>
      <attribute name="type" type="token"  
        default="contact\:statusValueType"/>
    </extension>
  </complexContent>
 </complexType>

<!--
End of schema.
-->
</schema>
END]]></artwork>
        </figure>
    </section>      

            
    <section title="Verification Code Schema">
    
      <t>Verification Code Object XML schema that defines the fields specific to the Verification Code Object.</t>

      <figure>
        <artwork><![CDATA[
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema 
  targetNamespace=
    "urn:ietf:params:xml:ns:dsfVerificationCode-1.0"
  xmlns:dsfVerificationCode=
    "urn:ietf:params:xml:ns:dsfVerificationCode-1.0"
  xmlns:dataSet="urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">
  
  <annotation>
    <documentation>
      Verification Code Data Set File (DSF) Object 
    </documentation>
  </annotation>

  <import namespace="urn:ietf:params:xml:ns:dataSet-1.0"
    schemaLocation="dataSet-1.0.xsd"/>
  
 <!-- fCode field --> 
 <element name="fCode" type="dsfVerificationCode:fCodeType" 
   substitutionGroup="dataSet:field"/>   
 <complexType name="fCodeType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="dsfVerificationCode\:verificationCodeValueType"/>
       <attribute name="codeType" type="token"/>
     </extension>
   </complexContent>
 </complexType>
 
 <!-- Format of verification code value --> 
 <simpleType name="verificationCodeValueType">
   <restriction base="token">
     <pattern value="\d+-[A-Za-z0-9]+"/>    
   </restriction>
 </simpleType>

 <!-- fEncodedSignedCode field -->
 <element name="fEncodedSignedCode" 
   type="dsfVerificationCode:fEncodedSignedCodeType" 
   substitutionGroup="dataSet:field"/>   
 <complexType name="fEncodedSignedCodeType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="token"/>
       <attribute name="encoding" type="token"
         default="base64"/>
     </extension>
   </complexContent>
 </complexType>
     
</schema>
END]]></artwork>
        </figure>
      </section>      
             
    <section title="Routing Schema">
    
      <t>Routing XML schema that defines the fields specific to routing.</t>

      <figure>
        <artwork><![CDATA[
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema 
  targetNamespace=
    "urn:ietf:params:xml:ns:dsfRouting-1.0"
  xmlns:dsfRouting=
    "urn:ietf:params:xml:ns:dsfRouting-1.0"
  xmlns:dataSet="urn:ietf:params:xml:ns:dataSet-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">
  
  <annotation>
    <documentation>
      Routing Data Set File (DSF) Fields 
    </documentation>
  </annotation>

  <import namespace="urn:ietf:params:xml:ns:dataSet-1.0"
    schemaLocation="dataSet-1.0.xsd"/>
  
 <!-- fSubProduct field --> 
 <element name="fSubProduct" type="dsfRouting:fSubProductType" 
   substitutionGroup="dataSet:field"/>   
 <complexType name="fSubProductType">
   <complexContent>
     <extension base="dataSet:fieldOptionalType">
       <sequence/>
       <attribute name="type" type="token"  
         default="token"/>
     </extension>
   </complexContent>
 </complexType>
      
</schema>
END]]></artwork>
        </figure>
      </section>      
      
    </section>
       
       
    <section anchor="IANA" title="IANA Considerations">
           
      <section anchor="IANA-XML-Namespace" 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 dataSet namespace:
          <list>
            <t>URI: ietf:params:xml:ns:dataSet-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: None. Namespace URIs do not represent an XML specification.</t>
            </list>
         </t>
         <t>Registration request for the dataSet XML schema:
          <list>
            <t>URI: ietf:params:xml:schema:dataSet-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: See the "Formal Syntax" section of this document.</t>
           </list>
        </t>
         
         <t>Registration request for the dsfDomain namespace:
          <list>
            <t>URI: ietf:params:xml:ns:dsfDomain-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: None. Namespace URIs do not represent an XML specification.</t>
            </list>
         </t>
         <t>Registration request for the dsfDomain XML schema:
          <list>
            <t>URI: ietf:params:xml:schema:dsfDomain-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: See the "Formal Syntax" section of this document.</t>
           </list>
        </t>
         
         <t>Registration request for the dsfHost namespace:
          <list>
            <t>URI: ietf:params:xml:ns:dsfHost-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: None. Namespace URIs do not represent an XML specification.</t>
            </list>
         </t>
         <t>Registration request for the dsfHost XML schema:
          <list>
            <t>URI: ietf:params:xml:schema:dsfHost-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: See the "Formal Syntax" section of this document.</t>
           </list>
        </t>
          
         <t>Registration request for the dsfContact namespace:
          <list>
            <t>URI: ietf:params:xml:ns:dsfContact-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: None. Namespace URIs do not represent an XML specification.</t>
            </list>
         </t>
         <t>Registration request for the dsfContact XML schema:
          <list>
            <t>URI: ietf:params:xml:schema:dsfContact-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: See the "Formal Syntax" section of this document.</t>
           </list>
        </t>

         
         <t>Registration request for the dsfVerificationCode namespace:
          <list>
            <t>URI: ietf:params:xml:ns:dsfVerificationCode-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: None. Namespace URIs do not represent an XML specification.</t>
            </list>
         </t>
         <t>Registration request for the dsfVerificationCode XML schema:
          <list>
            <t>URI: ietf:params:xml:schema:dsfVerificationCode-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: See the "Formal Syntax" section of this document.</t>
           </list>
        </t>

         <t>Registration request for the dsfRouting namespace:
          <list>
            <t>URI: ietf:params:xml:ns:dsfRouting-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: None. Namespace URIs do not represent an XML specification.</t>
            </list>
         </t>
         <t>Registration request for the dsfRouting XML schema:
          <list>
            <t>URI: ietf:params:xml:schema:dsfRouting-1.0</t>
            <t>Registrant Contact: See the "Author's Address" section of this document.</t>
               <t>XML: See the "Formal Syntax" section of this document.</t>
           </list>
        </t>
         
         
       </section>
            
    </section>


    <section anchor="Security" title="Security Considerations">
      <t>The data supported by the Data Set File (DSF) format MAY include information that needs 
      to be protected with the use of a secure transport.  For example, the &lt;dataSet:fAuthInfo&gt; field 
      provides object authorization information, and as described in <xref target="RFC5731"/>, both the client 
      and the server MUST ensure that it is stored and exchanged with high-grade encryption mechanisms.  The transport 
      leveraged to exchange the DSF containing sensitive or secure data MUST protect it from inadvertent disclosure.  
      </t>
      <t><xref target="W3C.CR-xmldsig-core2-20120124">XML Signature</xref> is used in this document 
      to verify that the Data Set originated from a trusted source and that it wasn't tampered with in transit 
      from the source to the client to the server.  To support multiple source keys, 
      the source certificate chain MUST be included in the &lt;X509Certificate&gt; elements of the 
      <xref target="signedDefData">Signed Def Data</xref> and MUST chain up and be verified 
      by the server against a set of trusted certificates.</t>
      <t>It is RECOMMENDED that signed definition data does not include white-spaces 
       between the XML elements in order to mitigate risks of invalidating the 
       digital signature when transferring of signed codes between applications 
       takes place.</t>
      <t>Use of XML canonicalization SHOULD be used when generating 
       the signed code.  SHA256/RSA-SHA256 SHOULD be used for digesting and signing.  
       The size of the RSA key SHOULD be at least 2048 bits.</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">
       
      &RFC2045;
      
      &RFC2119;
      
      &RFC3339;
      
      &RFC3688;      

      &RFC5234;
            
      &RFC5730;
 
      &RFC5731;
     
      &RFC5732;
      
      &RFC5733;
      
      &RFC5910;
            
      &W3C.xmldsig;
    
      &I-D.draft-gould-eppext-verificationcode;
      
      <reference anchor="itu-t-V.42" 
        target="https://www.itu.int/rec/T-REC-V.42-200203-I">
         <front>
           <title>ITU-T V.42 Series V: Data Communication Over the Telephone Network</title>
           <author>
             <organization abbrev="ITU">International Telecommunication Union</organization>
           </author>
           <date month="March" year="2002"/>
         </front>
      </reference>
      
      <reference anchor="iso13239"
        target="http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=37010">
         <front>
           <title>ISO 13239</title>
           <author>
             <organization abbrev="ISO">the International Organization for Standardization</organization>
           </author>
           <date month="December" day="20" year="2007"/>
         </front>
      </reference>
      
    
    </references>
  
   <section title="Acknowledgements">
    <t>The author wishes to acknowledge the work done by Scott Hollenbeck in the EPP RFC 5730 
    for providing some of the concepts and text used in this document.
    </t>
    <t>Special suggestions that have been incorporated into this document were provided by 
    John Colosi, Deepak Deshpande, Scott Hollenbeck, Suzy Strier, and Srikanth Veeramachaneni.</t>
   </section>
  
  
   <section title="Change History">
    <section title="Change from 00 to 01" anchor="change-00-to-01">
      <t><list style="numbers">
        <t>Fixed the ABNF.</t>
        <t>Added support for the 1002 "Success with all failures" result code to indicate that the file was successfully processed but that all of the records failed.</t>
        <t>Updated the description for the 1000 "Success" and the 1001 "Success with failures" result codes.</t>
      </list></t>
    </section>
    <section title="Change from 01 to 02" anchor="change-01-to-02">
      <t><list style="numbers">
        <t>Made small editorial changes based upon a review.</t>
      </list></t>
    </section>    
   </section>
    
  </back>

  <!-- vim: set ts=2 sw=2 expandtab: -->
</rfc>
