ICANN Registry Interfaces
draft-lozano-icann-registry-interfaces-06

Abstract

This document describes the interfaces provided by ICANN to Registry Operators in order to fulfill the requirements of Specification 2 and 3 of the New gTLD Base Agreement. The interface provided by ICANN to Data Escrow Agents in order to fulfill the requirements of Specification 2 of the New gTLD Base Agreement is also described in this document.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 12, 2015.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

1.1. Terminology

2. Interfaces for Specification 2 - Data Escrow Reporting

2.1. Registry Operator Reporting
2.2. Data Escrow Agent Reporting

3. Interfaces of Specification 3 - Registry Operator Monthly Reporting

3.1. Per-Registrar Transactions Report
3.2. Registry Functions Activity Report

4. Interface details

4.1. IIRDEA Result Object

5. Formal Syntax

5.1. IIRDEA Result Schema
5.2. Report Object
5.3. Notification Object

6. Acknowledgements
7. Change History

7.1. Version 00
7.2. Version 01
7.3. Version 02
7.4. Version 03
7.5. Version 04

8. IANA Considerations
9. Security Considerations
10. References

10.1. Normative References
10.2. Informative References

Authors' Addresses

1. Introduction

Authentication credentials for the interfaces are provided by ICANN to the Registry Operator per TLD. The Registry Operator receives a set of credentials to be used by the Registry Operator and by the Data Escrow Agent for authentication to the after-mentioned interfaces.

1.1. Terminology

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 RFC 2119 [RFC2119].

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.

2. Interfaces for Specification 2 - Data Escrow Reporting

This section describes the interfaces provided by ICANN to Registry Operators and Data Escrow Agents in order to comply with the reporting provisions detailed in Specification 2 of the New gTLD Base Agreement of the new gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604].

2.1. Registry Operator Reporting

The New gTLD Base Agreement, Specification 2, Part A, Section 7 requires Registry Operators to provide ICANN with a written statement that includes a copy of the report generated upon creation of a deposit and a statement that the deposit has been inspected by the Registry Operator and is complete and accurate.

In order to comply with this provision, the Registry Operator sends a <rdeReport:report> element to ICANN for each deposit successfully sent to the Data Escrow Agent, using the PUT HTTP verb in the interface provided by ICANN at:

https://ry-api.icann.org/report/registry-escrow-report/<TLD>/<id>
Where:
- <TLD> MUST be substituted by the TLD for which the report is being provided. In case of an IDN TLD, the A-label MUST be used.
- <id> MUST be substituted by the identifier assigned to this report, which MUST be the same as the "id" attribute from the <deposit>.
Note: The interface supports overwriting the information of a particular report "id" to support async interfaces between Registry Operators and Data Escrow Agents.

2.1.1. <report> object

The <report> element contains the following child elements:

An <id> element contains the identifier assigned to this report. The report identifier MUST be the same as the "id" attribute from the <deposit>.
A <version> element contains the version of the specification used. This value MUST be 1.
A <rydeSpecEscrow> element contains the version of the Registry Data Escrow Specification (e.g. draft-arias-noguchi-registry-data-escrow-06) used to create the deposit. After the specification is published as an RFC, the value MUST be the RFC number assigned by IANA.
A <rydeSpecMapping> element contains the version of the Domain Name Registration Data (DNRD) Objects Mapping (e.g. draft-arias-noguchi-dnrd-objects-mapping-05) used to create the deposit. After the specification is published as an RFC, the value MUST be the RFC number assigned by IANA.
A <resend> element contains the value of the "resend" attribute of the <deposit>.
A <crDate> element contains the date and time that the deposit was created by the Registry Operator.
A <kind> element is used to identify the kind of deposit: FULL, INCR (Incremental) or DIFF (Differential).
A <watermark> element contains the data and time corresponding to the Timeline Watermark (<watermark> element) of the <deposit>.
A <header> element contains the header of the <deposit>.

Example <report> object:

<?xml version="1.0" encoding="UTF-8"?>
  <rdeReport:report
    xmlns:rdeReport="urn:ietf:params:xml:ns:rdeReport-1.0"
	xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0">
    <rdeReport:id>20101017001</rdeReport:id>
    <rdeReport:version>1</rdeReport:version>
    <rdeReport:rydeSpecEscrow>
      draft-arias-noguchi-registry-data-escrow-06
    </rdeReport:rydeSpecEscrow>
    <rdeReport:rydeSpecMapping>
      draft-arias-noguchi-dnrd-objects-mapping-05
    </rdeReport:rydeSpecMapping>
    <rdeReport:resend>0</rdeReport:resend>
    <rdeReport:crDate>2010-10-17T00:15:00.0Z</rdeReport:crDate>
    <rdeReport:kind>FULL</rdeReport:kind>
    <rdeReport:watermark>2010-10-17T00:00:00Z</rdeReport:watermark>
    <rdeHeader:header>
      <rdeHeader:tld>test</rdeHeader:tld>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeDomain-1.0">2</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeHost-1.0">1</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeContact-1.0">1</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeRegistrar-1.0">1
	    </rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeIDN-1.0">1</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeNNDN-1.0">1</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1
	    </rdeHeader:count>
    </rdeHeader:header>
  </rdeReport:report>

2.2. Data Escrow Agent Reporting

The New gTLD Base Agreement, Specification 2, Part B, Section 7 requires Data Escrow Agents, to deliver to ICANN a notification every time a successfully processed deposit is received from the Registry Operator regardless of the final status of the verification process.

There are three types of notices:

Deposit Receipt Failure Notice (DRFN): generated by the Escrow Agent when no deposit is received pursuant to the schedule specified in Specification 2.
Deposit Verification Failure Notice (DVFN): generated by the Escrow Agent when a deposit is received, but the final result of the verification process is failure.
Deposit Verification Pass Notice (DVPN): generated by the Escrow Agent when a deposit is received and the final result of the verification process is success.

In order to comply with this provision, the Data Escrow Agent sends a <rdeNotification:notification> element to ICANN, using the POST HTTP verb in the interface provided by ICANN at:

https://ry-api.icann.org/report/escrow-agent-notification/<TLD>
Where:
- <TLD> MUST be substituted by the TLD for which the notification is being provided. In case of an IDN TLD, the A-label MUST be used.

If by 23:59 UTC, a deposit has not been successfully processed regardless of the final status of the verification process, a <rdeNotification:notification> with DRFN status MUST be send to ICANN.

2.2.1. <notification> object

The <notification> element contains the following child elements:

A <deaName> element contains the name of the Data Escrow Agent.
A <version> element contains the version of the specification used. This value MUST be 1.
A <repDate> element contains the reported date. In case of a DVPN or DVFN notification this value MUST be the date of the <watermark> element of the <deposit>. In case of a DRFN deposit notification, this value MUST be the date for which no deposit was received from the Registry Operator.
A <status> element is used to specify the status of <repDate>. The possible values of status are: DVPN, DVFN and DRFN.
- DVPN
- DVFN
- DRFN
An OPTIONAL <reDate> element contains the date and time that the deposit was successful received by the Data Escrow Agent. In case of a DRFN deposit notification this element MUST NOT be present.
An OPTIONAL <vaDate> element contains the date and time that the deposit was successfully validated by the Data Escrow Agent. In case of a DRFN deposit notification this element MUST NOT be present.
An OPTIONAL <lastFullDate> element contains the date of the Timeline Watermark (<watermark> element) of the most recent FULL deposit that was successfully validated by the Data Escrow Agent. This element MUST NOT be present if a successfully validated full deposit has never been deposited.
An OPTIONAL <report> element is used by the Data Escrow Agent to provide extended information about the deposit. In case of a DRFN deposit notification this element MUST NOT be present. In case of a DVPN or DVFN deposit notification this element MUST be present. When this element is present, the <rdeHeader:header> element MUST be generated by the Data Escrow Agent for the Timeline Watermark (<watermark> element) of the deposit being processed. If the deposit being processed is a differential or incremental deposit, the Data Escrow Agent MUST process the last full plus all differentials or last full plus last incremental escrow deposits to generate the <rdeHeader:header> element.
Note: In case of a DPVN or DVFN deposit notification, the <rdeReport:id> is used as unique identifier.

Example <notification> object:

<?xml version="1.0" encoding="UTF-8"?>
<rdeNotification:notification
  xmlns:rdeNotification="urn:ietf:params:xml:ns:rdeNotification-1.0"
  xmlns:rdeReport="urn:ietf:params:xml:ns:rdeReport-1.0"
  xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0">
  <rdeNotification:deaName>Escrow Agent Inc.</rdeNotification:deaName>
  <rdeNotification:version>1</rdeNotification:version>
  <rdeNotification:repDate>2010-10-17</rdeNotification:repDate>
  <rdeNotification:status>DVPN</rdeNotification:status>
  <rdeNotification:reDate>
     2010-10-17T03:15:00.0Z
  </rdeNotification:reDate>
  <rdeNotification:vaDate>
     2010-10-17T05:15:00.0Z
  </rdeNotification:vaDate>
  <rdeNotification:lastFullDate>
     2010-10-14
  </rdeNotification:lastFullDate>  
  <rdeReport:report>
    <rdeReport:id>20101017001</rdeReport:id>
    <rdeReport:version>1</rdeReport:version>
    <rdeReport:rydeSpecEscrow>
      draft-arias-noguchi-registry-data-escrow-06
    </rdeReport:rydeSpecEscrow>
    <rdeReport:rydeSpecMapping>
      draft-arias-noguchi-dnrd-objects-mapping-05
    </rdeReport:rydeSpecMapping>
    <rdeReport:resend>0</rdeReport:resend>
    <rdeReport:crDate>2010-10-17T00:15:00.0Z</rdeReport:crDate>
    <rdeReport:kind>FULL</rdeReport:kind>
    <rdeReport:watermark>2010-10-17T00:00:00Z</rdeReport:watermark>
    <rdeHeader:header>
      <rdeHeader:tld>test</rdeHeader:tld>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeDomain-1.0">2</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeHost-1.0">1</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeContact-1.0">1</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeRegistrar-1.0">1
	    </rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeIDN-1.0">1</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeNNDN-1.0">1</rdeHeader:count>
      <rdeHeader:count
        uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1
	    </rdeHeader:count>
    </rdeHeader:header>
  </rdeReport:report>
</rdeNotification:notification>

3. Interfaces of Specification 3 - Registry Operator Monthly Reporting

Specification 3 of the New gTLD Base Agreement requires Registry Operators to provide a set of monthly reports per gTLD. Two type of reports are required to be sent by Registries: Per-Registrar Transactions Report and Registry Functions Activity Report. This section specifies the interfaces provided by ICANN to automate the upload of these reports by Registry Operators.

The cut-off date for the reception of the reports specified in specification 3 is defined in the New gTLD Base Agreement of the new gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604]. Before the cut-off date the Registry Operator could replace a successfully validated report as many times as it needs.

3.1. Per-Registrar Transactions Report

The Per-Registrar Transactions Report is a CSV report described in Section 1 of Specification 3.

In order to comply with this provision, the Registry Operator sends a CSV report on a monthly basis as described in the New gTLD Base Agreement, using the PUT HTTP verb in the interface provided by ICANN at:

https://ry-api.icann.org/report/registrar-transactions/<TLD>/<date>
Where:
- <TLD> MUST be substituted by the TLD for which the reports is being provided. In case of an IDN TLD, the A-label MUST be used.
- <date> MUST be substituted by the month for which the reports is being provided in the form of YYYY-MM. Where 'YYYY' is the year and 'MM' is the two digit month number. For example: 2013-03

3.2. Registry Functions Activity Report

The Registry Functions Activity Report is a CSV report described in Section 2 of Specification 3 of the New gTLD Base Agreement of the new gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604].

https://ry-api.icann.org/report/registry-functions-activity/<TLD>/<date>
Where:
- <TLD> MUST be substituted by the TLD for which the report is being provided. In case of an IDN TLD, the A-label MUST be used.
- <date> MUST be substituted by the month for which the reports is being provided in the form of YYYY-MM. Where 'YYYY' is the year and 'MM' is the two digit month number. For example: 2013-03

4. Interface details

The client MUST set "text/xml" in the HTTP header Content-type when using the Data Escrow Agent Reporting and Registry Operator Reporting interfaces. The client MUST set "text/csv" in the HTTP header Content-type when using the Per-Registrar Transactions Report Registry Functions Activity Report interfaces.

The Data Escrow Agent Reporting and Registry Operator Reporting interfaces support HTTP streams only (HTTP multi-part forms are not supported).

After successfully receiving an input in any of the interfaces described above, ICANN validates it and provides a result code in the same HTTP transaction. The interface set the HTTP header Content-type: text/xml, when sending the IIRDEA result.

The interface provides a HTTP/200 status code if the interface was able to receive the input and no problem was found in the input.
The interface provides a HTTP/400 if the input is incorrect or the syntax of the input is invalid.
The interface provides a HTTP/401 status code if the credentials provided does not authorize the Registry Operator to upload a report for that <TLD>.
The interface provides a HTTP/403 status code if the credentials provided are valid but are being used to access a resource that permission is not granted for or the connecting IP address is not whitelisted for the <TLD>.
The interface provides a HTTP/500 status code if the system is experiencing a general failure. The sending party is responsible to send the input again.

After sending the result code, the interface closes the TCP connection.

4.1. IIRDEA Result Object

After processing the input provided in any of the interfaces described in this document, a response object as defined by the schema in Section 5 is provided in the HTTP Entity-body when an HTTP/200 and HTTP/400 status code is sent by the interface.

An example of a response object is presented below:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response xmlns="urn:ietf:params:xml:ns:iirdea-1.0">
    <result code="2001">
        <msg>The structure of the report is invalid.</msg>
        <description>
           'XX' could not be parsed as a number (line: 2 column:3)
        </description>
    </result>
</response>

The following sections provide the IIRDEA Result Codes per interface:

4.1.1. Registry Operator Reporting

The following table lists the result codes of the interface:

Data Escrow Reporting Result Codes
Result Code	Message
1000	No ERRORs were found and the report has been accepted by ICANN.
2001	The report did not validate against the schema.
2004	Report for a date in the future. The <crDate> and <watermark> date should not be in the future.
2005	Version is not supported.
2006	The <id> in the <report> element and the <id> in the URL path do not match.
2007	Interface is disabled for this TLD.
2008	The <crDate> and <watermark> date should not be before the creation date of the TLD in the system.
2202	The <TLD> in the <header> and the <TLD> in the URL path do not match.
2205	Report regarding a differential deposit received for a Sunday (<watermark>).
2206	csvDomain and rdeDomain count provided in the <header>.

4.1.2. Data Escrow Agent Reporting

The following table lists the result codes of the interface:

Data Escrow Reporting Result Codes
Result Code	Message
1000	No ERRORs were found and the notification has been accepted by ICANN.
2001	The notification did not validate against the schema.
2002	A DVPN notification exists for that date (<repDate>).
2004	Notification for a date in the future. The <crDate> and <watermark> and <repDate> date should not be in the future.
2005	Version is not supported.
2007	Interface is disabled for this TLD.
2008	The <crDate> and <watermark> and <repDate> date should not be before the creation date of the TLD in the system.
2201	The <repDate> and <watermark> in the notification do not match.
2202	The <TLD> in the <header> and the <TLD> in the URL path do not match.
2203	A Deposit Verification Pass Notice (DVPN) notification was received, but the Domain Name count is missing in the <header>.
2204	The notification for the report "id" already exists.
2205	Notification regarding a differential deposit received for a Sunday (<repDate>).
2206	csvDomain and rdeDomain count provided in the <header>.
2207	A DVPN or DVFN was received, but the <report> element is missing in the notification.
2208	A DRFN was received, but a <report> element exists in the notification.

4.1.3. Per-Registrar Transactions Report

The following table lists the result codes of the interface:

Per-Registrar Transactions Report Result Codes
Result Code	Message
1000	No ERRORs were found and the report has been accepted by ICANN.
2001	The structure of the report is invalid.
2002	A report for that month already exists, the cut-off date already passed.
2003	Negative numeric value present in the report.
2004	Report for a month in the future.
2007	Interface is disabled for this TLD.
2008	Reported month before the creation date of the TLD in the system.
2101	Incorrect totals present in the report.
2102	Non ICANN accredited registrar present in the report.
2103	Values found in the second field of the totals line.

4.1.4. Registry Functions Activity Report

The following table lists the result codes of the interface:

Registry Functions Activity Report Result Codes
Result Code	Message
1000	No ERRORs were found and the report has been accepted by ICANN.
2001	The structure of the report is invalid.
2002	A report for that month already exists, the cut-off date already passed.
2003	Negative numeric value present in the report.
2004	Report for a month in the future.
2007	Interface is disabled for this TLD.
2008	Reported month before the creation date of the TLD in the system.

5. Formal Syntax

The schema of the IIRDEA, Reports and Notifications are presented here.

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.

5.1. IIRDEA Result Schema

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

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.

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

BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:iirdea-1.0" 
  xmlns:iirdea="urn:ietf:params:xml:ns:iirdea-1.0" 
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">
  
  <annotation>
    <documentation>
      ICANN interfaces for registries and data escrow agents
    </documentation>
  </annotation>
  
  <element name="response" type="iirdea:responseType"/>
  
  <complexType name="responseType">
    <sequence>
      <element name="result" type="iirdea:resultType"/>
    </sequence>
  </complexType>
  
  <complexType name="resultType">
    <sequence>
      <element name="msg" type="token"/>
      <element name="description" type="string" minOccurs="0"/>
    </sequence>
    <attribute name="code" type="iirdea:codeType" use="required"/>
  </complexType>
  
  <simpleType name="codeType">
    <restriction base="unsignedShort">
      <minInclusive value="1000"/>
      <maxInclusive value="9999"/>
    </restriction>
  </simpleType>
</schema>
END

5.2. Report Object

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

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.

BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rdeReport-1.0"
  xmlns:rdeReport="urn:ietf:params:xml:ns:rdeReport-1.0"
  xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"
  xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">
  
  <import namespace="urn:ietf:params:xml:ns:rde-1.0"
    schemaLocation="rde-1.0.xsd"/>
  <import namespace="urn:ietf:params:xml:ns:rdeHeader-1.0"
    schemaLocation="rde-header-1.0.xsd" />
    
  <annotation>
    <documentation>
      Registry Data Escrow Report schema
    </documentation>
  </annotation>
  
  <!-- Root Element -->
  <element name="report" type="rdeReport:reportType"/>
  
  <!-- Report Type -->
  <complexType name="reportType">
    <sequence>
      <element name="id" type="rde:depositIdType"/>
      <element name="version" type="unsignedShort"/>
      <element name="rydeSpecEscrow" type="token"/>
      <element name="rydeSpecMapping" type="token"/>   
      <element name="resend" type="unsignedShort"/>
      <element name="crDate" type="dateTime"/>
      <element name="kind" type="rde:depositTypeType"/>
      <element name="watermark" type="dateTime"/>
      <element ref="rdeHeader:header"/>
    </sequence>
  </complexType>
</schema>
END

5.3. Notification Object

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

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.

BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rdeNotification-1.0"
  xmlns:rdeNotification="urn:ietf:params:xml:ns:rdeNotification-1.0"
  xmlns:rdeReport="urn:ietf:params:xml:ns:rdeReport-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">
  
  <import namespace="urn:ietf:params:xml:ns:rdeReport-1.0"
    schemaLocation="rde-report-1.0.xsd"/>
    
  <annotation>
    <documentation>
      Registry Data Escrow Notification schema
    </documentation>
  </annotation>
  
  <!-- Root Element -->
  <element name="notification" type="rdeNotification:notificationType"/>
  
  <!-- Notification -->
  <complexType name="notificationType">
    <sequence>
      <element name="deaName" type="rdeNotification:nameType"/>
      <element name="version" type="unsignedShort"/>
      <element name="repDate" type="date"/>
      <element name="status" type="rdeNotification:statusType"/>
      <element name="reDate" type="dateTime" minOccurs="0"/>
      <element name="vaDate" type="dateTime" minOccurs="0"/>
      <element name="lastFullDate" type="date" minOccurs="0"/>
      <element ref="rdeReport:report" minOccurs="0"/>
    </sequence>
  </complexType>
  
  <simpleType name="nameType">
    <restriction base="normalizedString">
      <minLength value="1" />
      <maxLength value="255" />
    </restriction>
  </simpleType>
  
  <simpleType name="statusType">
    <restriction base="token">
      <enumeration value="DVPN"/>
      <enumeration value="DVFN"/>
      <enumeration value="DRFN"/>
    </restriction>
  </simpleType>
</schema>
END

6. Acknowledgements

Special suggestions that have been incorporated into this document were provided by David Kipling, James Gould, Gregory Zaltsman, and Harel Efraim.

7. Change History

7.1. Version 00

Initial version.

7.2. Version 01

<rdeReport:report> and <rdeNotification:notification> moved from escrow drafts to this draft
Added <crDate> to <rdeReport:report>
<reDate> element of <rdeReport:report> is now OPTIONAL
Added <deaName> element to <rdeNotification:notification>
<rydeSpecEscrow> and <rydeSpecMapping> added to the draft
Several report elements are OPTIONAL to support async interfaces between Registry Operators and Data Escrow Agents
Added <TLD> and <id> to registry-escrow-report interface in order to make the interface idempotent and support async RyO-DEA interfaces
Added <TLD> to escrow-agent-notification interface
The escrow-agent-notification uses POST and not PUT, this has been fixed
Several clarifications

7.3. Version 02

Added and updated several result codes.
Added <version> element.
Added Content-type definition.

7.4. Version 03

Added several result codes.
unsignedShort is now used for result code in iirdea schema.
Enumeration was removed from the iirdea schema.

7.5. Version 04

Added result codes: 2207 and 2208.
Removed result codes: 2203.
Added clarification regarding the support of HTTP streams.

8. IANA Considerations

TODO

9. Security Considerations

TODO

10. References

10.1. Normative References

[I-D.arias-noguchi-dnrd-objects-mapping]	Arias, F., Lozano, G., Noguchi, S., Gould, J. and C. Thippeswamy, "Domain Name Registration Data (DNRD) Objects Mapping", Internet-Draft draft-arias-noguchi-dnrd-objects-mapping-05, September 2013.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688]	Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

10.2. Informative References

[ICANN-GTLD-AGB-20120604]

ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2012.

Authors' Addresses

Gustavo Lozano ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, 90292 US Phone: +1.3103015800 EMail: gustavo.lozano@icann.org

Brett Carr ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, 90292 US Phone: +1.3103015800 EMail: brett.carr@icann.org