Network Working Group F. Arias
Internet-Draft G. Lozano
Intended status: Standards Track ICANN
Expires: September 13, 2013 S. Noguchi
JPRS
J. Gould
C. Thippeswamy
VeriSign
March 12, 2013
Domain Name Registration Data (DNRD) Objects Mapping
draft-arias-noguchi-dnrd-objects-mapping-02
Abstract
This document specifies the format, contents and semantics of Domain
Name Registration Data (DNRD) Escrow deposits for a Domain Name
Registry. It includes the following objects:
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 September 13, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Arias, et al. Expires September 13, 2013 [Page 1]
Internet-Draft DNRD Objects Mapping March 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. General Conventions . . . . . . . . . . . . . . . . . . . . . 6
4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Country names . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Telephone numbers . . . . . . . . . . . . . . . . . . . . 6
4.4. IP addresses . . . . . . . . . . . . . . . . . . . . . . . 6
5. Object Description . . . . . . . . . . . . . . . . . . . . . . 6
5.1. RDE Domain object . . . . . . . . . . . . . . . . . . . . 6
5.2. RDE Host object . . . . . . . . . . . . . . . . . . . . . 10
5.3. RDE Contact object . . . . . . . . . . . . . . . . . . . . 12
5.4. RDE Registrar object . . . . . . . . . . . . . . . . . . . 16
5.5. RDE IDN Practices . . . . . . . . . . . . . . . . . . . . 19
5.6. RDE NNDN . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.7. RDE EPP Parameters object . . . . . . . . . . . . . . . . 21
5.8. RDE Policy object . . . . . . . . . . . . . . . . . . . . 23
5.9. Header object . . . . . . . . . . . . . . . . . . . . . . 23
6. RDE IDN Variants handling . . . . . . . . . . . . . . . . . . 24
7. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Appendix A. Example of a full deposit using the XML model
only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Appendix B. Example of differential deposit using the XML
model only . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Appendix C. Data escrow agent extended verification process . 31
11. Appendix D. Data escrow notifications . . . . . . . . . . . . 32
11.1. Notifications from Registry Operators to Third Parties . . 32
11.2. Notifications from Data Escrow Agents to Third Parties . . 34
11.3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 35
11.4. Policy Object . . . . . . . . . . . . . . . . . . . . . . 58
12. Internationalization Considerations . . . . . . . . . . . . . 60
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
14. Security Considerations . . . . . . . . . . . . . . . . . . . 63
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
16. Change History . . . . . . . . . . . . . . . . . . . . . . . . 64
16.1. Changes from
draft-arias-noguchi-registry-data-escrow-02 to
-dnrd-objects-mapping-00 . . . . . . . . . . . . . . . . . 64
16.2. Changes from version 00 to 01 . . . . . . . . . . . . . . 64
16.3. Changes from version 01 to 02 . . . . . . . . . . . . . . 65
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Arias, et al. Expires September 13, 2013 [Page 2]
Internet-Draft DNRD Objects Mapping March 2013
17.1. Normative References . . . . . . . . . . . . . . . . . . . 65
17.2. Informative References . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
Arias, et al. Expires September 13, 2013 [Page 3]
Internet-Draft DNRD Objects Mapping March 2013
1. Introduction
This document defines the data escrow structure of the standard set
of objects for a Domain Name Registry which include:
o Domain: Internet domain names that are typically provisioned in a
Domain Name Registry using the EPP domain name mapping [RFC5731].
The attributes defined in the EPP domain name mapping [RFC5731]
are fully supported by this document.
o Host: Internet host names that are typically provisioned in a
Domain Name Registry using the EPP host mapping [RFC5732]. The
attributes defined in the EPP host mapping [RFC5732] are fully
supported by this document.
o Contact: Individual or organization social information provisioned
in a Domain Name Registry using the EPP contact mapping [RFC5733].
The attributes defined in the EPP contact mapping [RFC5733] are
fully supported by this document.
o Registrar: The organization that sponsors objects like domains,
hosts, and contacts in a Domain Name Registry.
o NNDN: A lightweight domain object that is not linked to a
Registrar.
This document defines the following pseudo-objects:
o IDN practices: Internationalized Domain Names (IDN) included in
the Domain Object Data Escrow include references to the languages
rules that define the set of character code points allowed for a
specific language.
o EPP parameters: Definition of the specific EPP parameters
supported by the Registry Operator.
o Header: Used to specify counters of objects in the SRS database at
a certain point in time (watermark).
o Policy: Used to specify OPTIONAL elements from this specification
that are REQUIRED based on the business model of the registry.
2. Models
This document defines two different models that can be used to
deposit data escrow objects:
Arias, et al. Expires September 13, 2013 [Page 4]
Internet-Draft DNRD Objects Mapping March 2013
o XML: The XML model includes all of the deposit information (meta-
data and data) in an XML document. The definition of the XML
format is fully defined in the XML schemas.
o CSV: The CSV model uses XML to define the data escrow format of
the data contained in referenced Comma-Separated Values (CSV)
files.
The data escrow deposit MAY contain a mix of both models but an
object MUST be escrowed only in one model.
3. 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 BCP 14, [RFC2119].
REGISTRY. In the context of this draft the definition will be
overloaded (from the definition in the base protocol) to indicate an
organization providing Registry Services for a REGISTRY-CLASS DOMAIN
NAME.
REGISTRY-CLASS DOMAIN NAME (RCDN): Refers to a top-level domain (TLD)
or any other domain name at any level in the DNS tree for which a
Registry (either directly or through and affiliate company) provides
Registry Services for other organizations or individuals. For
example: .COM, .ORG, .BIZ, .CO.JP, .B.BR.
REGISTRY SERVICES. Services offered by the Registry critical to the
following tasks: the provisioning of domain names on receipt of
requests and data from registrars; responding to registrar queries
for status information relating to the DNS servers for the RCDN;
dissemination of RCDN zone files; operation of the Registry DNS
servers; and responding to queries for contact and other information
concerning DNS registrations in the RCDN. Any other products or
services that only a Registry is capable of providing, by reason of
its designation as the Registry. Typical examples of Registry
Services are: DNS resolution for the RCDN, WHOIS and EPP.
ALLOCATED. A status of some label with respect to a zone, whereby
the label is associated administratively to some entity that has
requested the label. This term (and its cognates "allocation" and
"to allocate") may represents the first step on the way to delegation
in the DNS.
Arias, et al. Expires September 13, 2013 [Page 5]
Internet-Draft DNRD Objects Mapping March 2013
4. General Conventions
4.1. Date and Time
Numerous fields indicate "dates", such as the creation and expiry
dates for domain names. These fields SHALL contain timestamps
indicating the date and time in UTC as specified in [RFC3339], with
no offset from the zero meridian.
4.2. Country names
Country identifiers SHALL be represented using two character
identifiers as specified in [ISO-3166-1].
4.3. Telephone numbers
Telephone numbers (both voice and fascimile) SHALL be formatted based
on structures defined in [ITU-E164]. Telephone numbers described in
this specification are character strings that MUST begin with a plus
sign ("+", ASCII value 0x002B), followed by a country code defined in
[ITU-E164], followed by a dot (".", ASCII value 0x002E), followed by
a sequence of digits representing the telephone number.
4.4. IP addresses
IP addresses syntax MUST conform either to, Internet Protocol
[RFC0791], for IPv4 addresses, or IP Version 6 Addressing
Architecture [RFC4291], for IPv6 addresses.
5. Object Description
This section describes the base objects supported by this
specification:
5.1. RDE Domain object
The RDE domain object is based on the EPP domain name mapping
specified in [RFC5731]. There are two elements used in this format
related to domains: the domain object per se, used inside the
<contents> element and the <rdeDomain:delete> object used inside the
<deletes> element.
5.1.1. <domain> object
The domain element is based on the EPP domain <info> response for an
authorized client (see Section 3.1.2. of [RFC5731]) with additional
data from an EPP <transfer> Query Response, see Section 3.1.3. of
Arias, et al. Expires September 13, 2013 [Page 6]
Internet-Draft DNRD Objects Mapping March 2013
[RFC5731], RGP status from [RFC3915], and data from the EPP <secDns:
create> command, see Section 5.2.1. of [RFC5910].
A <domain> element substitutes for the <abstractDomain> abstract
element to define a concrete definition of a domain. The
<abstractDomain> element can be replaced by other domain definitions
using the XML schema substitution groups feature.
The <domain> element contains the following child elements:
o A <name> element that contains the fully qualified name of the
domain name object.
o A <roid> element that contains the repository object identifier
assigned to the domain name object when it was created.
o An OPTIONAL <uName> element that contains the name of the domain
name in Unicode character set. It MUST be provided if available.
o An OPTIONAL <idnTableId> element that references the IDN Table
used for the IDN. This corresponds to the "id" attribute of the
<idnTableRef> element. This element MUST be present if the domain
name is an IDN.
o An OPTIONAL <originalName> element is used to indicate that the
domain name is an IDN variant. This element contains the domain
name used to generate the IDN variant.
o One or more <status> elements that contain the current status
descriptors associated with the domain name.
o Zero or more OPTIONAL <rgpStatus> element to represent
"pendingDelete" sub-statuses, including "redemptionPeriod",
"pendingRestore", and "pendingDelete", that a domain name can be
in as a result of grace period processing as specified in
[RFC3915].
o An OPTIONAL <registrant> element that contain the identifier for
the human or organizational social information object associated
as the holder of the domain name object.
o Zero or more OPTIONAL <contact> elements that contain identifiers
for the human or organizational social information objects
associated with the domain name object.
o An OPTIONAL <ns> element that contains the fully qualified names
of the delegated host objects or host attributes (name servers)
associated with the domain name object. See Section 1.1 of
Arias, et al. Expires September 13, 2013 [Page 7]
Internet-Draft DNRD Objects Mapping March 2013
[RFC5731] for a description of the elements used to specify host
objects or host attributes.
o A <clID> element that contains the identifier of the sponsoring
registrar.
o A <crRr> element that contains the identifier of the registrar
that created the domain name object. An OPTIONAL client attribute
is used to specify the client that performed the operation.
o An OPTIONAL <crDate> element that contains the date and time of
the domain name object creation. This element MUST be present if
the domain name has been allocated.
o An OPTIONAL <exDate> element that contains the date and time
identifying the end (expiration) of the domain name object's
registration period. This element MUST be present if the domain
name has been allocated.
o An OPTIONAL <upRr> element that contains the identifier of the
registrar that last updated the domain name object. This element
MUST NOT be present if the domain has never been modified. An
OPTIONAL client attribute is used to specify the client that
performed the operation.
o An OPTIONAL <upDate> element that contains the date and time of
the most recent domain-name-object modification. This element
MUST NOT be present if the domain name object has never been
modified.
o An OPTIONAL <secDNS> element that contains the public key
information associated with Domain Name System security (DNSSEC)
extensions for the domain name as specified in [RFC5910].
o An OPTIONAL <trDate> element that contains the date and time of
the most recent domain object successful transfer. This element
MUST NOT be present if the domain name object has never been
transfered.
o An OPTIONAL <trnData> element that contains the following child
elements related to the last transfer request of the domain name
object. This element MUST NOT be present if a transfer request
for the domain name has never been created.
* A <trStatus> element that contains the state of the most recent
transfer request.
Arias, et al. Expires September 13, 2013 [Page 8]
Internet-Draft DNRD Objects Mapping March 2013
* A <reRr> element that contains the identifier of the registrar
that requested the domain name object transfer. An OPTIONAL
client attribute is used to specify the client that performed
the operation.
* A <reDate> element that contains the date and time that the
transfer was requested.
* An <acRr> element that contains the identifier of the registrar
that SHOULD act upon a PENDING transfer request. For all other
status types, the value identifies the registrar that took the
indicated action. An OPTIONAL client attribute is used to
specify the client that performed the operation.
* An <acDate> element that contains the date and time of a
required or completed response. For a PENDING request, the
value identifies the date and time by which a response is
required before an automated response action will be taken by
the registry. For all other status types, the value identifies
the date and time when the request was completed.
* An OPTIONAL <exDate> element that contains the end of the
domain name object's validity period (expiry date) if the
transfer caused or causes a change in the validity period.
Example of a domain object:
...
<rdeDom:domain>
<rdeDom:name>example1.test</rdeDom:name>
<rdeDom:roid>Dexample1-TEST</rdeDom:roid>
<rdeDom:status s="ok"/>
<rdeDom:registrant>jd1234</rdeDom:registrant>
<rdeDom:contact type="admin">sh8013</rdeDom:contact>
<rdeDom:contact type="tech">sh8013</rdeDom:contact>
<rdeDom:ns>
<domain:hostObj>ns1.example.com</domain:hostObj>
<domain:hostObj>ns1.example1.test</domain:hostObj>
</rdeDom:ns>
<rdeDom:clID>RegistrarX</rdeDom:clID>
<rdeDom:crRr client="jdoe">RegistrarX</rdeDom:crRr>
<rdeDom:crDate>1999-04-03T22:00:00.0Z</rdeDom:crDate>
<rdeDom:exDate>2015-04-03T22:00:00.0Z</rdeDom:exDate>
</rdeDom:domain>
...
Arias, et al. Expires September 13, 2013 [Page 9]
Internet-Draft DNRD Objects Mapping March 2013
5.1.2. <rdeDomain:delete> object
The <rdeDomain:delete> element contains the fully qualified domain
name that was deleted and purged.
Example of <rdeDomain:delete> object:
...
<rde:deletes>
...
<rdeDomain:delete>
<rdeDomain:name>foo.test</rdeDomain:name>
<rdeDomain:name>bar.test</rdeDomain:name>
</rdeDomain:delete>
...
</rde:deletes>
...
5.2. RDE Host object
The RDE host object is based on the EPP host name mapping in
[RFC5732]. There are two elements used in this format related to
hosts: the host object per se, used inside the <contents> element and
the <rdeHost:delete> object used inside the <deletes> element.
A <host> element substitutes for the <abstractHost> abstract element
to define a concrete definition of a host. The <abstractHost>
element can be replaced by other host definitions using the XML
schema substitution groups feature.
5.2.1. <host> object
The RDE host object is based on the EPP host <info> response for an
authorized client (Section 3.1.2. of [RFC5732]).
The OPTIONAL <host> element contains the following child elements:
o A <name> element that contains the fully qualified name of the
host object.
o A <roid> element that contains the repository object identifier
assigned to the host object when the object was created.
o One or more <status> elements that describe the status of the host
object.
Arias, et al. Expires September 13, 2013 [Page 10]
Internet-Draft DNRD Objects Mapping March 2013
o Zero or more <addr> elements that contain the IP addresses
associated with the host object.
o A <clID> element that contains the identifier of the sponsoring
registrar.
o A <crRr> element that contains the identifier of the registrar
that created the host object. An OPTIONAL client attribute is
used to specify the client that performed the operation.
o A <crDate> element that contains the date and time of host-object
creation.
o An OPTIONAL <upRr> element that contains the identifier of the
registrar that last updated the host object. This element MUST
NOT be present if the host object has never been modified. An
OPTIONAL client attribute is used to specify the client that
performed the operation.
o An OPTIONAL <upDate> element that contains the date and time of
the most recent host-object modification. This element MUST NOT
be present if the host object has never been modified.
o An OPTIONAL <trDate> element that contains the date and time of
the most recent host object successful transfer. This element
MUST NOT be present if the domain name object has never been
transfered.
Example of <host> object:
...
<rdeHost:host>
<rdeHost:name>ns1.example1.test</rdeHost:name>
<rdeHost:roid>Hns1_example_test-TEST</rdeHost:roid>
<rdeHost:status s="ok"/>
<rdeHost:status s="linked"/>
<rdeHost:addr ip="v4">192.0.2.2</rdeHost:addr>
<rdeHost:addr ip="v4">192.0.2.29</rdeHost:addr>
<rdeHost:addr ip="v6">1080:0:0:0:8:800:200C:417A</rdeHost:addr>
<rdeHost:clID>RegistrarX</rdeHost:clID>
<rdeHost:crRr>RegistrarX</rdeHost:crRr>
<rdeHost:crDate>1999-05-08T12:10:00.0Z</rdeHost:crDate>
<rdeHost:upRr>RegistrarX</rdeHost:upRr>
<rdeHost:upDate>2009-10-03T09:34:00.0Z</rdeHost:upDate>
</rdeHost:host>
...
Arias, et al. Expires September 13, 2013 [Page 11]
Internet-Draft DNRD Objects Mapping March 2013
5.2.2. <rdeHost:delete> object
The <rdeHost:delete> element contains the fully qualified domain name
of a host that was deleted.
Example of <rdeHost:delete> object:
...
<rde:deletes>
...
<rdeHost:delete>
<rdeHost:name>ns1.example.test</rdeHost:name>
</rdeHost:delete>
...
</rde:deletes>
...
5.3. RDE Contact object
The RDE contact object is based on the EPP contact name mapping in
[RFC5733]. There are two elements used in this format related to
contacts: the contact object per se, used inside the <contents>
element and the <rdeContact:delete> object used inside the <deletes>
element.
A <contact> element substitutes for the <abstractContact> abstract
element to define a concrete definition of a contact. The
<abstractContact> element can be replaced by other contact
definitions using the XML schema substitution groups feature.
5.3.1. <contact> object
The contact object is based on the EPP contact <info> response for an
authorized client (Section 3.1.2. of [RFC5733]) with some additions
including the data from an EPP <transfer> Query Response, see Section
3.1.3. of [RFC5733].
The OPTIONAL <contact> element contains the following child elements:
o An <id> element that contains the repository object identifier
assigned to the contact object when the object was created.
o A <roid> element that contains the repository object identifier
assigned to the contact object when it was created.
o One or more <status> elements that describe the status of the
contact object.
Arias, et al. Expires September 13, 2013 [Page 12]
Internet-Draft DNRD Objects Mapping March 2013
o One or two <postalInfo> elements that contain postal-address
information. Two elements are provided so that address
information can be provided in both internationalized and
localized forms; a "type" attribute is used to identify the two
forms. If an internationalized form (type="int") is provided,
element content MUST be represented in a subset of UTF-8 that can
be represented in the 7-bit US-ASCII character set. If a
localized form (type="loc") is provided, element content MAY be
represented in unrestricted UTF-8. The <postalInfo> element
contains the following child elements:
* A <name> element that contains the name of the individual or
role represented by the contact.
* An OPTIONAL <org> element that contains the name of the
organization with which the contact is affiliated.
* An <addr> element that contains address information associated
with the contact. An <addr> element contains the following
child elements:
+ One, two, or three OPTIONAL <street> elements that contain
the contact's street address.
+ A <city> element that contains the contact's city.
+ An OPTIONAL <sp> element that contains the contact's state
or province.
+ An OPTIONAL <pc> element that contains the contact's postal
code.
+ A <cc> element that contains the contact's two-letter
country code.
o An OPTIONAL <voice> element that contains the contact's voice
telephone number.
o An OPTIONAL <fax> element that contains the contact's facsimile
telephone number.
o An <email> element that contains the contact's email address.
o A <clID> element that contains the identifier of the sponsoring
registrar.
o A <crRr> element that contains the identifier of the registrar
that created the contact object. An OPTIONAL client attribute is
Arias, et al. Expires September 13, 2013 [Page 13]
Internet-Draft DNRD Objects Mapping March 2013
used to specify the client that performed the operation.
o A <crDate> element that contains the date and time of contact-
object creation.
o An OPTIONAL <upRr> element that contains the identifier of the
registrar that last updated the contact object. This element MUST
NOT be present if the contact has never been modified. An
OPTIONAL client attribute is used to specify the client that
performed the operation.
o An OPTIONAL <upDate> element that contains the date and time of
the most recent contact-object modification. This element MUST
NOT be present if the contact object has never been modified.
o An OPTIONAL <trDate> element that contains the date and time of
the most recent contact object successful transfer. This element
MUST NOT be present if the contact object has never been
transferred.
o An OPTIONAL <trnData> element that contains the following child
elements related to the last transfer request of the contact
object:
* A <trStatus> element that contains the state of the most recent
transfer request.
* A <reRr> element that contains the identifier of the registrar
that requested the domain name object transfer. An OPTIONAL
client attribute is used to specify the client that performed
the operation.
* An <acRr> element that contains the identifier of the registrar
that SHOULD act upon a PENDING transfer request. For all other
status types, the value identifies the registrar that took the
indicated action. An OPTIONAL client attribute is used to
specify the client that performed the operation.
* A <reDate> element that contains the date and time that the
transfer was requested.
* An <acDate> element that contains the date and time of a
required or completed response. For a PENDING request, the
value identifies the date and time by which a response is
required before an automated response action will be taken by
the registry. For all other status types, the value identifies
the date and time when the request was completed.
Arias, et al. Expires September 13, 2013 [Page 14]
Internet-Draft DNRD Objects Mapping March 2013
o An OPTIONAL <disclose> element that identifies elements that
requiring exceptional server-operator handling to allow or
restrict disclosure to third parties. See Section 2.9 of
[RFC5733] for a description of the child elements contained within
the <disclose> element.
Example <contact> object:
...
<rdeContact:contact>
<rdeContact:id>sh8013</rdeContact:id>
<rdeContact:roid>Csh8013-TEST</rdeContact:roid>
<rdeContact:status s="linked"/>
<rdeContact:status s="clientDeleteProhibited"/>
<rdeContact:postalInfo type="int">
<contact:name>John Doe</contact:name>
<contact:org>Example Inc.</contact:org>
<contact:addr>
<contact:street>123 Example Dr.</contact:street>
<contact:street>Suite 100</contact:street>
<contact:city>Dulles</contact:city>
<contact:sp>VA</contact:sp>
<contact:pc>20166-6503</contact:pc>
<contact:cc>US</contact:cc>
</contact:addr>
</rdeContact:postalInfo>
<rdeContact:voice x="1234">+1.7035555555</rdeContact:voice>
<rdeContact:fax>+1.7035555556</rdeContact:fax>
<rdeContact:email>jdoe@example.test</rdeContact:email>
<rdeContact:clID>RegistrarX</rdeContact:clID>
<rdeContact:crRr client="jdoe">RegistrarX</rdeContact:crRr>
<rdeContact:crDate>2009-09-13T08:01:00.0Z</rdeContact:crDate>
<rdeContact:upRr client="jdoe">RegistrarX</rdeContact:upRr>
<rdeContact:upDate>2009-11-26T09:10:00.0Z</rdeContact:upDate>
<rdeContact:trDate>2009-12-03T09:05:00.0Z</rdeContact:trDate>
<rdeContact:trnData>
<rdeContact:trStatus>pending</rdeContact:trStatus>
<rdeContact:reRr client="jstiles">clientW</rdeContact:reRr>
<rdeContact:reDate>2011-03-08T19:38:00.0Z</rdeContact:reDate>
<rdeContact:acRr client="rmiles">RegistrarX</rdeContact:acRr>
<rdeContact:acDate>2011-03-13T23:59:59.0Z</rdeContact:acDate>
</rdeContact:trnData>
<rdeContact:disclose flag="0">
<contact:voice/>
<contact:email/>
</rdeContact:disclose>
</rdeContact:contact>
Arias, et al. Expires September 13, 2013 [Page 15]
Internet-Draft DNRD Objects Mapping March 2013
...
5.3.2. <rdeContact:delete> object
The <rdeContact:delete> element contains the id of a contact that was
deleted.
Example of <rdeContact:delete> object:
...
<rde:deletes>
...
<rdeContact:delete>
<rdeContact:id>sh8013-TEST</rdeContact:id>
<rdeContact:id>co8013-TEST</rdeContact:id>
</rdeContact:delete>
...
</rde:deletes>
...
5.4. RDE Registrar object
The RDE registrar object is the sponsoring client of other RDE
objects, for operational purposes MAY be the registry operator.
There are two elements used in this format related to registrars: the
registrar object per se, used inside the <contents> element and the
<rdeRegistrar:delete> object used inside the <deletes> element.
A <registrar> element substitutes for the <abstractRegistrar>
abstract element to define a concrete definition of a registrar. The
<abstractRegistrar> element can be replaced by other domain
definitions using the XML schema substitution groups feature.
5.4.1. <registrar> object
The <registrar> element contains the following child elements:
o An <id> element that contains the Registry-unique identifier of
the registrar object. This <id> has a superordinate relationship
to a subordinate <clID>, <crRr> or <upRr> of domain, contact and
host objects.
o An <name> element that contains the name of the registrar.
o An OPTIONAL <gurid> element that contains the ID assigned by
ICANN.
Arias, et al. Expires September 13, 2013 [Page 16]
Internet-Draft DNRD Objects Mapping March 2013
o A <status> element that contains the operational status of the
registrar. Possible values are: ok, readonly and terminated.
o One or two <postalInfo> elements that contain postal- address
information. Two elements are provided so that address
information can be provided in both internationalized and
localized forms; a "type" attribute is used to identify the two
forms. If an internationalized form (type="int") is provided,
element content MUST be represented in a subset of UTF-8 that can
be represented in the 7-bit US-ASCII character set. If a
localized form (type="loc") is provided, element content MAY be
represented in unrestricted UTF-8. The <postalInfo> element
contains the following child elements:
* A <addr> element that contains address information associated
with the registrar. The <addr> element contains the following
child elements:
+ One, two, or three OPTIONAL <street> elements that contain
the registrar's street address.
+ A <city> element that contains the registrar's city.
+ An OPTIONAL <sp> element that contains the registrar's state
or province.
+ An OPTIONAL <pc> element that contains the registrar's
postal code.
+ A <cc> element that contains the registrar's country code.
o An OPTIONAL <voice> element that contains the registrar's voice
telephone number.
o An OPTIONAL <fax> element that contains the registrar's facsimile
telephone number.
o An <email> element that contains the registrar's email address.
o An OPTIONAL <url> element that contains the registrar's URL.
o An OPTIONAL <whoisInfo> elements that contains whois information.
The <whoisInfo> element contains the following child elements:
* An OPTIONAL <name> element that contains the name of the
registrar WHOIS server listening on TCP port 43 as specified in
[RFC3912].
Arias, et al. Expires September 13, 2013 [Page 17]
Internet-Draft DNRD Objects Mapping March 2013
* An OPTIONAL <url> element that contains the name of the
registrar WHOIS server listening on TCP port 80/443.
o A <crDate> element that contains the date and time of registrar-
object creation.
o An OPTIONAL <upDate> element that contains the date and time of
the most recent RDE registrar-object modification. This element
MUST NOT be present if the rdeRegistrar object has never been
modified.
Example of <registrar> object:
...
<rdeRegistrar:registrar>
<rdeRegistrar:id>RegistrarX</rdeRegistrar:id>
<rdeRegistrar:name>Registrar X</rdeRegistrar:name>
<rdeRegistrar:gurid>123</rdeRegistrar:gurid>
<rdeRegistrar:status>ok</rdeRegistrar:status>
<rdeRegistrar:postalInfo type="int">
<rdeRegistrar:addr>
<rdeRegistrar:street>123 Example Dr.</rdeRegistrar:street>
<rdeRegistrar:street>Suite 100</rdeRegistrar:street>
<rdeRegistrar:city>Dulles</rdeRegistrar:city>
<rdeRegistrar:sp>VA</rdeRegistrar:sp>
<rdeRegistrar:pc>20166-6503</rdeRegistrar:pc>
<rdeRegistrar:cc>US</rdeRegistrar:cc>
</rdeRegistrar:addr>
</rdeRegistrar:postalInfo>
<rdeRegistrar:voice x="1234">+1.7035555555</rdeRegistrar:voice>
<rdeRegistrar:fax>+1.7035555556</rdeRegistrar:fax>
<rdeRegistrar:email>jdoe@example.test</rdeRegistrar:email>
<rdeRegistrar:url>http://www.example.test</rdeRegistrar:url>
<rdeRegistrar:whoisInfo>
<rdeRegistrar:name>whois.example.test</rdeRegistrar:name>
<rdeRegistrar:url>http://whois.example.test</rdeRegistrar:url>
</rdeRegistrar:whoisInfo>
<rdeRegistrar:crDate>2005-04-23T11:49:00.0Z</rdeRegistrar:crDate>
<rdeRegistrar:upDate>2009-02-17T17:51:00.0Z</rdeRegistrar:upDate>
</rdeRegistrar:registrar>
...
5.4.2. <rdeRegistrar:delete> object
The <rdeRegistrar:delete> element contains the id of a registrar that
was deleted.
Arias, et al. Expires September 13, 2013 [Page 18]
Internet-Draft DNRD Objects Mapping March 2013
Example of <rdeRegistrar:delete> object:
...
<rde:deletes>
...
<rdeRegistrar:delete>
<rdeRegistrar:id>agnt0001-TEST</rdeRegistrar:id>
</rdeRegistrar:delete>
...
</rde:deletes>
...
5.5. RDE IDN Practices
The RDE Internationalized Domain Names (IDN) Practices reference is a
pseudo-object that is used to provide a short reference to the IDN
Table and Policy used in IDN registrations. The <idnTableRef>
element has an "id" attribute that is used to uniquely identify an
IDN Table stored externally.
5.5.1. <idnTableRef> object
The OPTIONAL <idnTableRef> contains the following elements. An id
attribute is used to specify an identifier for the IDN table.
o An <url> element that contains the URL of the IDN table that is
being referenced.
o A <urlPolicy> element that contains the URL of the IDN policy
document. If IDN variants are generated algorithmically, the
policy document MUST define the algorithm and the state of the
implicit generated IDN variants. For a list of suggested states
for implicit IDN variants, please see [variantTLDsReport].
Example of <idnTableRef> object:
...
<rdeIDN:idnTableRef id="pt-BR">
<rdeIDN:url>
http://www.iana.org/domains/idn-tables/tables/br_pt-br_1.0.html
</rdeIDN:url>
<rdeIDN:urlPolicy>
http://registro.br/dominio/regras.html
</rdeIDN:urlPolicy>
</rdeIDN:idnTableRef>
...
Arias, et al. Expires September 13, 2013 [Page 19]
Internet-Draft DNRD Objects Mapping March 2013
5.6. RDE NNDN
A NNDN (NNDN's not domain name) does not exist as a domain object; it
is stored in the SRS database. NNDNs can optionally be used to store
registry reserved names or IDN variant handling (blocked and
withheld). A NNDN is a lightweight domain object that is not linked
to a Registrar. A FQDN can only exist as a domain name or NNDN, but
not both.
A <NNDN> element substitutes for the <abstractNNDN> abstract element
to define a concrete definition of a NNDN. The <abstractDomain>
element can be replaced by other NNDN definitions using the XML
schema substitution groups feature.
5.6.1. <NNDN> object
The OPTIONAL <NNDN> element contains the following child elements:
o An <aName> element that contains the ASCII Compatible Encoding
(ACE) of the NNDN.
o An OPTIONAL <uName> element that contains the name of the NNDN in
Unicode character set. It MUST be provided if available.
o An OPTIONAL <idnTableId> element that references the IDN Table
used for the NNDN. This corresponds to the "id" attribute of the
<idnTableRef> element. This element MUST be present if the NNDN
is an IDN.
o An OPTIONAL <originalName> element is used to indicate that the
NNDN is an IDN variant. This element contains the domain name
used to generate the IDN variant.
o A <nameState> element that indicates the state of the NNDN:
blocked or withheld.
* If a NNDN is considered undesirable for registration (i.e.,
unavailable for allocation to anyone), then the NNDN will be
tagged as "blocked".
* If a NNDN is created to allow the registration of a domain
object to a particular registrant then the NNDN will be tagged
as "withheld".
o A <crDate> element that contains the date and time of the NNDN
object creation.
Example of <NNDN> object:
Arias, et al. Expires September 13, 2013 [Page 20]
Internet-Draft DNRD Objects Mapping March 2013
...
<rdeNNDN:NNDN>
<rdeNNDN:aName>xn--exampl-gva.test</rdeNNDN:aName>
<rdeNNDN:idnTableId>pt-BR</rdeNNDN:idnTableId>
<rdeNNDN:originalName>Dexample1-TEST</rdeNNDN:originalName>
<rdeNNDN:nameState>withheld</rdeNNDN:nameState>
<rdeNNDN:crDate>2005-04-23T11:49:00.0Z</rdeNNDN:crDate>
</rdeNNDN:NNDN>
...
5.6.2. <rdeNNDN:delete> object
The <rdeNNDN:delete> element contains the ACE of a NNDN that was
deleted, i.e., the <aName>.
Example of <rdeNDN:delete> object:
...
<rde:deletes>
...
<rdeNNDN:delete>
<rdeNNDN:aName>xn--pingino-q2a.test</rdeNDN:aName>
</rdeNNDN:delete>
...
</rde:deletes>
...
5.7. RDE EPP Parameters object
An OPTIONAL <eppParams> element contains some EPP parameters that may
be helpful when rebuilding a registry from the escrow deposits. The
element SHOULD be included in Deposits if the registry uses EPP.
The syntax and content of the <eppParams> children elements is as
explained in section 2.4 of [RFC5730]. The children of the
<eppParams> are as follows:
o One or more <version> elements that indicate the EPP versions
supported by the registry.
o One or more <lang> elements that indicate the identifiers of the
text response languages supported by the registry's EPP server.
o One or more <objURI> elements that contain namespace URIs
representing the objects that the registry's EPP server is capable
of managing.
Arias, et al. Expires September 13, 2013 [Page 21]
Internet-Draft DNRD Objects Mapping March 2013
o An OPTIONAL <svcExtension> element that contains one or more
<extURI> elements that contain namespace URIs representing object
extensions supported by the registry's EPP server.
o A <dcp> element that contains child elements used to describe the
server's privacy policy for data collection and management. See
section 2.4 of [RFC5730] for more details.
Example of <eppParams> element object:
...
<rdeEppParams:eppParams>
<rdeEppParams:version>1.0</rdeEppParams:version>
<rdeEppParams:lang>en</rdeEppParams:lang>
<rdeEppParams:objURI>urn:ietf:params:xml:ns:domain-1.0
</rdeEppParams:objURI>
<rdeEppParams:objURI>urn:ietf:params:xml:ns:contact-1.0
</rdeEppParams:objURI>
<rdeEppParams:objURI>urn:ietf:params:xml:ns:host-1.0
</rdeEppParams:objURI>
<rdeEppParams:svcExtension>
<epp:extURI>urn:ietf:params:xml:ns:rgp-1.0</epp:extURI>
<epp:extURI>urn:ietf:params:xml:ns:secDNS-1.1</epp:extURI>
</rdeEppParams:svcExtension>
<rdeEppParams:dcp>
<epp:access><epp:all/></epp:access>
<epp:statement>
<epp:purpose>
<epp:admin/>
<epp:prov/>
</epp:purpose>
<epp:recipient>
<epp:ours/>
<epp:public/>
</epp:recipient>
<epp:retention>
<epp:stated/>
</epp:retention>
</epp:statement>
</rdeEppParams:dcp>
</rdeEppParams:eppParams>
...
Arias, et al. Expires September 13, 2013 [Page 22]
Internet-Draft DNRD Objects Mapping March 2013
5.8. RDE Policy object
The RDE Policy is a pseudo-object that is used to specify which
OPTIONAL elements from this specification are REQUIRED based on the
business model of the registry.
5.8.1. <policy> object
The OPTIONAL <policy> contains the following attributes:
o An <element> that defines that the referenced <element> is
REQUIRED.
Example of <policy> object:
...
<rdePolicy:policy element="rdeDom:registrant" />
...
5.9. Header object
The RDE Header is a pseudo-object that is used to specify the number
of objects in the SRS at a specific point in time (watermark)
regardless of the type of deposit: differential, full or incremental.
5.9.1. <header> object
The <header> contains the following attributes:
o A <tld> element that defines TLD being escrowed.
o A <count> element that number of objects being escrowed. An uri
attribute is used to define the type of object.
Example of <header> object:
Arias, et al. Expires September 13, 2013 [Page 23]
Internet-Draft DNRD Objects Mapping March 2013
...
<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>
...
6. RDE IDN Variants handling
Depending on the Registration Policy of the Registry; for a
particular domain name there may be multiple variant names. See
[variantTLDsReport] for further detail on IDN variants.
A registry could choose to escrow IDN variants as domains or NNDN
objects.
A NNDN or a domain name are explicit representations of an IDN
variant while an IDN variant computed based on an algorithm is an
implicit representation. Explicit representation of an IDN variant
takes precedence over an implicit representation.
7. Profile
Different business models of registries exist, therefore the registry
is responsible to define a profile that matches its particular
business model. The profile mechanism allows a registry to extend
this specification.
A profile is the process of:
Arias, et al. Expires September 13, 2013 [Page 24]
Internet-Draft DNRD Objects Mapping March 2013
1. Extending base objects with the mechanisms defined for XML and
CSV models.
* In the case of the XML model, abstract elements could be use
to extend the following objects: <domain>, <host>, <contact>,
<NNDN> and <registrar> using XML schema substitution groups
feature.
2. Defining a <policy> object to specify which OPTIONAL elements of
this base specification are required based on the business model
of the registry. An example is the <registrant> element that is
usually REQUIRED but it is specified as OPTIONAL in this
specification to accomodate existing business models.
3. Adding new escrowed objects using the <rde:contents> and <rde:
deletes> elements.
4. Providing the XML schemas to third parties that require them to
validate the escrow deposits.
8. Appendix A. Example of a full deposit using the XML model only
Example of a full deposit using the XML model only:
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit type="FULL" id="20101017001" prevId="20101010001"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"
xmlns:rdeDom="urn:ietf:params:xml:ns:rdeDomain-1.0"
xmlns:rdeHost="urn:ietf:params:xml:ns:rdeHost-1.0"
xmlns:rdeContact="urn:ietf:params:xml:ns:rdeContact-1.0"
xmlns:rdeRegistrar="urn:ietf:params:xml:ns:rdeRegistrar-1.0"
xmlns:rdeIDN="urn:ietf:params:xml:ns:rdeIDN-1.0"
xmlns:rdeNNDN="urn:ietf:params:xml:ns:rdeNNDN-1.0"
xmlns:rdeEppParams="urn:ietf:params:xml:ns:rdeEppParams-1.0"
xmlns:rdePolicy="urn:ietf:params:xml:ns:rdePolicy-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0">
<rde:watermark>2010-10-17T00:00:00Z</rde:watermark>
<rde:rdeMenu>
<rde:version>1.0</rde:version>
<rde:objURI>urn:ietf:params:xml:ns:rdeHeader-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeContact-1.0</rde:objURI>
Arias, et al. Expires September 13, 2013 [Page 25]
Internet-Draft DNRD Objects Mapping March 2013
<rde:objURI>urn:ietf:params:xml:ns:rdeHost-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeDomain-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeRegistrar-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeIDN-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeNNDN-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeEppParams-1.0</rde:objURI>
</rde:rdeMenu>
<!-- Contents -->
<rde:contents>
<!-- Header -->
<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>
<!-- Domian: example1.test -->
<rdeDom:domain>
<rdeDom:name>example1.test</rdeDom:name>
<rdeDom:roid>Dexample1-TEST</rdeDom:roid>
<rdeDom:status s="ok"/>
<rdeDom:registrant>jd1234</rdeDom:registrant>
<rdeDom:contact type="admin">sh8013</rdeDom:contact>
<rdeDom:contact type="tech">sh8013</rdeDom:contact>
<rdeDom:ns>
<domain:hostObj>ns1.example.com</domain:hostObj>
<domain:hostObj>ns1.example1.test</domain:hostObj>
</rdeDom:ns>
<rdeDom:clID>RegistrarX</rdeDom:clID>
<rdeDom:crRr client="jdoe">RegistrarX</rdeDom:crRr>
<rdeDom:crDate>1999-04-03T22:00:00.0Z</rdeDom:crDate>
<rdeDom:exDate>2015-04-03T22:00:00.0Z</rdeDom:exDate>
</rdeDom:domain>
Arias, et al. Expires September 13, 2013 [Page 26]
Internet-Draft DNRD Objects Mapping March 2013
<!-- Domian: example2.test -->
<rdeDom:domain>
<rdeDom:name>example2.test</rdeDom:name>
<rdeDom:roid>Dexample2-TEST</rdeDom:roid>
<rdeDom:status s="ok"/>
<rdeDom:status s="clientUpdateProhibited"/>
<rdeDom:registrant>jd1234</rdeDom:registrant>
<rdeDom:contact type="admin">sh8013</rdeDom:contact>
<rdeDom:contact type="tech">sh8013</rdeDom:contact>
<rdeDom:clID>RegistrarX</rdeDom:clID>
<rdeDom:crRr>RegistrarX</rdeDom:crRr>
<rdeDom:crDate>1999-04-03T22:00:00.0Z</rdeDom:crDate>
<rdeDom:exDate>2015-04-03T22:00:00.0Z</rdeDom:exDate>
</rdeDom:domain>
<!-- Host: ns1.example.test -->
<rdeHost:host>
<rdeHost:name>ns1.example1.test</rdeHost:name>
<rdeHost:roid>Hns1_example_test-TEST</rdeHost:roid>
<rdeHost:status s="ok"/>
<rdeHost:status s="linked"/>
<rdeHost:addr ip="v4">192.0.2.2</rdeHost:addr>
<rdeHost:addr ip="v4">192.0.2.29</rdeHost:addr>
<rdeHost:addr ip="v6">1080:0:0:0:8:800:200C:417A</rdeHost:addr>
<rdeHost:clID>RegistrarX</rdeHost:clID>
<rdeHost:crRr>RegistrarX</rdeHost:crRr>
<rdeHost:crDate>1999-05-08T12:10:00.0Z</rdeHost:crDate>
<rdeHost:upRr>RegistrarX</rdeHost:upRr>
<rdeHost:upDate>2009-10-03T09:34:00.0Z</rdeHost:upDate>
</rdeHost:host>
<!-- Contact: sh8013 -->
<rdeContact:contact>
<rdeContact:id>sh8013</rdeContact:id>
<rdeContact:roid>Csh8013-TEST</rdeContact:roid>
<rdeContact:status s="linked"/>
<rdeContact:status s="clientDeleteProhibited"/>
<rdeContact:postalInfo type="int">
<contact:name>John Doe</contact:name>
<contact:org>Example Inc.</contact:org>
<contact:addr>
<contact:street>123 Example Dr.</contact:street>
<contact:street>Suite 100</contact:street>
<contact:city>Dulles</contact:city>
<contact:sp>VA</contact:sp>
<contact:pc>20166-6503</contact:pc>
<contact:cc>US</contact:cc>
Arias, et al. Expires September 13, 2013 [Page 27]
Internet-Draft DNRD Objects Mapping March 2013
</contact:addr>
</rdeContact:postalInfo>
<rdeContact:voice x="1234">+1.7035555555</rdeContact:voice>
<rdeContact:fax>+1.7035555556</rdeContact:fax>
<rdeContact:email>jdoe@example.test</rdeContact:email>
<rdeContact:clID>RegistrarX</rdeContact:clID>
<rdeContact:crRr client="jdoe">RegistrarX</rdeContact:crRr>
<rdeContact:crDate>2009-09-13T08:01:00.0Z</rdeContact:crDate>
<rdeContact:upRr client="jdoe">RegistrarX</rdeContact:upRr>
<rdeContact:upDate>2009-11-26T09:10:00.0Z</rdeContact:upDate>
<rdeContact:trDate>2009-12-03T09:05:00.0Z</rdeContact:trDate>
<rdeContact:disclose flag="0">
<contact:voice/>
<contact:email/>
</rdeContact:disclose>
</rdeContact:contact>
<!-- Registrar: RegistrarX -->
<rdeRegistrar:registrar>
<rdeRegistrar:id>RegistrarX</rdeRegistrar:id>
<rdeRegistrar:name>Registrar X</rdeRegistrar:name>
<rdeRegistrar:gurid>123</rdeRegistrar:gurid>
<rdeRegistrar:status>ok</rdeRegistrar:status>
<rdeRegistrar:postalInfo type="int">
<rdeRegistrar:addr>
<rdeRegistrar:street>123 Example Dr.</rdeRegistrar:street>
<rdeRegistrar:street>Suite 100</rdeRegistrar:street>
<rdeRegistrar:city>Dulles</rdeRegistrar:city>
<rdeRegistrar:sp>VA</rdeRegistrar:sp>
<rdeRegistrar:pc>20166-6503</rdeRegistrar:pc>
<rdeRegistrar:cc>US</rdeRegistrar:cc>
</rdeRegistrar:addr>
</rdeRegistrar:postalInfo>
<rdeRegistrar:voice x="1234">+1.7035555555</rdeRegistrar:voice>
<rdeRegistrar:fax>+1.7035555556</rdeRegistrar:fax>
<rdeRegistrar:email>jdoe@example.test</rdeRegistrar:email>
<rdeRegistrar:url>http://www.example.test</rdeRegistrar:url>
<rdeRegistrar:whoisInfo>
<rdeRegistrar:name>whois.example.test</rdeRegistrar:name>
<rdeRegistrar:url>http://whois.example.test</rdeRegistrar:url>
</rdeRegistrar:whoisInfo>
<rdeRegistrar:crDate>2005-04-23T11:49:00.0Z</rdeRegistrar:crDate>
<rdeRegistrar:upDate>2009-02-17T17:51:00.0Z</rdeRegistrar:upDate>
</rdeRegistrar:registrar>
<!-- IDN Table -->
<rdeIDN:idnTableRef id="pt-BR">
<rdeIDN:url>
Arias, et al. Expires September 13, 2013 [Page 28]
Internet-Draft DNRD Objects Mapping March 2013
http://www.iana.org/domains/idn-tables/tables/br_pt-br_1.0.html
</rdeIDN:url>
<rdeIDN:urlPolicy>
http://registro.br/dominio/regras.html
</rdeIDN:urlPolicy>
</rdeIDN:idnTableRef>
<!-- NNDN: pinguino.test -->
<rdeNNDN:NNDN>
<rdeNNDN:aName>xn--exampl-gva.test</rdeNNDN:aName>
<rdeNNDN:idnTableId>pt-BR</rdeNNDN:idnTableId>
<rdeNNDN:originalName>Dexample1-TEST</rdeNNDN:originalName>
<rdeNNDN:nameState>withheld</rdeNNDN:nameState>
<rdeNNDN:crDate>2005-04-23T11:49:00.0Z</rdeNNDN:crDate>
</rdeNNDN:NNDN>
<!-- EppParams -->
<rdeEppParams:eppParams>
<rdeEppParams:version>1.0</rdeEppParams:version>
<rdeEppParams:lang>en</rdeEppParams:lang>
<rdeEppParams:objURI>
urn:ietf:params:xml:ns:domain-1.0
</rdeEppParams:objURI>
<rdeEppParams:objURI>
urn:ietf:params:xml:ns:contact-1.0
</rdeEppParams:objURI>
<rdeEppParams:objURI>
urn:ietf:params:xml:ns:host-1.0
</rdeEppParams:objURI>
<rdeEppParams:svcExtension>
<epp:extURI>urn:ietf:params:xml:ns:rgp-1.0</epp:extURI>
<epp:extURI>urn:ietf:params:xml:ns:secDNS-1.1</epp:extURI>
</rdeEppParams:svcExtension>
<rdeEppParams:dcp>
<epp:access><epp:all/></epp:access>
<epp:statement>
<epp:purpose>
<epp:admin/>
<epp:prov/>
</epp:purpose>
<epp:recipient>
<epp:ours/>
<epp:public/>
</epp:recipient>
<epp:retention>
<epp:stated/>
</epp:retention>
</epp:statement>
Arias, et al. Expires September 13, 2013 [Page 29]
Internet-Draft DNRD Objects Mapping March 2013
</rdeEppParams:dcp>
</rdeEppParams:eppParams>
<rdePolicy:policy element="rdeDom:registrant" />
</rde:contents>
</rde:deposit>
9. Appendix B. Example of differential deposit using the XML model only
Example of a differential deposit using the XML model only:
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit type="DIFF" id="20101017002" prevId="20101017001"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"
xmlns:rdeDom="urn:ietf:params:xml:ns:rdeDomain-1.0"
xmlns:rdeHost="urn:ietf:params:xml:ns:rdeHost-1.0"
xmlns:rdeContact="urn:ietf:params:xml:ns:rdeContact-1.0"
xmlns:rdeRegistrar="urn:ietf:params:xml:ns:rdeRegistrar-1.0"
xmlns:rdeIDN="urn:ietf:params:xml:ns:rdeIDN-1.0"
xmlns:rdeNNDN="urn:ietf:params:xml:ns:rdeNNDN-1.0"
xmlns:rdeEppParams="urn:ietf:params:xml:ns:rdeEppParams-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0">
<rde:watermark>2010-10-17T00:00:00Z</rde:watermark>
<rde:rdeMenu>
<rde:version>1.0</rde:version>
<rde:objURI>urn:ietf:params:xml:ns:rdeHeader-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeContact-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeHost-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeDomain-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeRegistrar-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeIDN-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeNNDN-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeEppParams-1.0</rde:objURI>
</rde:rdeMenu>
<!-- Deletes -->
<rde:deletes>
<rdeDom:delete>
<rdeDom:name>example2.test</rdeDom:name>
</rdeDom:delete>
</rde:deletes>
Arias, et al. Expires September 13, 2013 [Page 30]
Internet-Draft DNRD Objects Mapping March 2013
<!-- Contents -->
<rde:contents>
<!-- Header -->
<rdeHeader:header>
<rdeHeader:tld>test</rdeHeader:tld>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:rdeDomain-1.0">1</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>
</rde:contents>
</rde:deposit>
10. Appendix C. Data escrow agent extended verification process
The Data Escrow Agent MAY perform a extended verification process
using the contents of data escrow deposits to a point in time
(watermark), last full plus all differentials or last full plus last
incremental escrow deposits. The following are the minimum suggested
tests:
o Validate the escrow deposits using the definition agreed with the
registry.
* In the case of the XML model, the contents of the escrow
deposits MUST be validated using the XML schemas of the
profile.
o Count the objects and validate that number of objects is equal to
the number objects reported in the <header> element of the escrow
deposit of that point in time (watermark).
o All contacts linked to domain names are present.
Arias, et al. Expires September 13, 2013 [Page 31]
Internet-Draft DNRD Objects Mapping March 2013
o All registrars linked to other objects are present.
o An FQDN exists only as a domain name or NNDN.
o The elements listed in the <policy> element are present.
o All idnTableRef definitions linked from other objects are present.
11. Appendix D. Data escrow notifications
Data escrowing involves several parties interacting with the
objective of restoring the operations of a Domain Registry in case of
an emergency. The following section defines several notifications
that are suggested to be sent between the interacting parties. The
parties based on the notification can know the status of the data
escrow deposit even if no access to the data escrow deposit file is
available.
11.1. Notifications from Registry Operators to Third Parties
Registry Operators MAY notify Third Parties that a data escrow
deposit file was sent to the Data Escrow Agent.
11.1.1. <report> object
The <report> object is used by Registry Operator to notify Third
Parties about successful delivery of a data escrow deposit to a Data
Escrow Agent.
The <report> element contains the following child elements:
o An <id> element contains the identifier assigned to this report.
An OPTIONAL resend attribute is used to specify the number of
retries needed for a successful reception/validator of the data
escrow deposit by the data escrow agent. It is recommended that
the report identifier be the same as the data escrow deposit
identifier.
o A <reDate> element contains the date and time that the data escrow
deposit was successful received by the data escrow agent.
o An OPTIONAL <vaDate> element contains the date and time that the
data escrow deposit was successfuly validated by the data escrow
agent.
o A <kind> element is used to identify the kind of deposit: FULL,
INCR (Incremental) or DIFF (Differential).
Arias, et al. Expires September 13, 2013 [Page 32]
Internet-Draft DNRD Objects Mapping March 2013
o A <lastFullDate> element contains the date and time of the last
FULL data escrow deposit that was successfuly validated by the
data escrow agent.
o A <watermark> element contains the data-time corresponding to the
Timeline Watermark of the deposit.
o A <header> element contains the header of the data escrow 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:reDate>2010-10-17T01:51:10.0Z</rdeReport:reDate>
<rdeReport:vaDate>2010-10-17T02:51:10.0Z</rdeReport:vaDate>
<rdeReport:kind>FULL</rdeReport:kind>
<rdeReport:lastFullDate>2010-10-16</rdeReport:lastFullDate>
<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>
Arias, et al. Expires September 13, 2013 [Page 33]
Internet-Draft DNRD Objects Mapping March 2013
11.2. Notifications from Data Escrow Agents to Third Parties
Data Escrow Agents MAY notify Third Parties that a data escrow
deposit file was received or it is missing for a specific date.
11.2.1. <notification> object
The <notification> object is used by Data Escrow Agents to notify
Third Parties about sucessful reception/validation of a data escrow
deposit for a specific date. If multiple deposits are received in a
day, the latest received deposit MUST be used to generate the
notification.
The <notification> element contains the following child elements:
o An <reDate> element contains the reported date.
o A <status> element is used to specify the status of <reDate>. The
possible values of status are: valid, invalid and missing.
* Valid: The last received data escrow deposit for the specified
date in <reDate> was successfully validated.
* Invalid: The last received data escrow deposit for the
specified date in <reDate> was not successfully validated.
* Missing: No data escrow deposit was received on the date
specified in <reDate>.
o A <report> element it is used by the data escrow agent to provide
extended information about the data escrow deposit. The <header>
element MUST be generated by the data escrow agent for a certain
point in time (watermark) based on the contents of the escrow
deposits. The last full plus all differentials or last full plus
last incremental escrow deposits MUST be used to generate <header>
element.
Example <notification> object:
Arias, et al. Expires September 13, 2013 [Page 34]
Internet-Draft DNRD Objects Mapping March 2013
<?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:reDate>2010-10-17</rdeNotification:reDate>
<rdeNotification:status>valid</rdeNotification:status>
<rdeReport:report>
<rdeReport:id>20101017001</rdeReport:id>
<rdeReport:reDate>2010-10-17T02:51:10.0Z</rdeReport:reDate>
<rdeReport:vaDate>2010-10-17T01:51:10.0Z</rdeReport:vaDate>
<rdeReport:kind>FULL</rdeReport:kind>
<rdeReport:lastFullDate>2010-10-16</rdeReport:lastFullDate>
<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>
11.3. Formal Syntax
Seven schemas are presented here. The first schema is the base RDE
schema. The second schema defines domain object for RDE. The third
schema defines host object for RDE. The fourth schema defines
contact object for RDE. The fifth schema defines registrar object
for RDE. The sixth schema defines the idnTableRef and IDN objects.
The last schema defines the eppParams objects.
Arias, et al. Expires September 13, 2013 [Page 35]
Internet-Draft DNRD Objects Mapping March 2013
11.3.1. RDE Domain Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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:rdeDomain-1.0"
xmlns:rdeDomain="urn:ietf:params:xml:ns:rdeDomain-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rgp="urn:ietf:params:xml:ns:rgp-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 namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd" />
Arias, et al. Expires September 13, 2013 [Page 36]
Internet-Draft DNRD Objects Mapping March 2013
<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:rgp-1.0"
schemaLocation="rgp-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:rde-1.0"
schemaLocation="rde-1.0.xsd"/>
<annotation>
<documentation>
Registry Data Escrow Domain provisioning schema
</documentation>
</annotation>
<element name="abstractDomain" type="rdeDomain:abstractContentType"
substitutionGroup="rde:content" abstract="true"/>
<element name="domain" substitutionGroup="rdeDomain:abstractDomain"/>
<element name="delete" type="rdeDomain:deleteType"
substitutionGroup="rde:delete"/>
<!-- Content Type -->
<complexType name="abstractContentType">
<complexContent>
<extension base="rde:contentType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="roid" type="eppcom:roidType"/>
<element name="uName" type="eppcom:labelType" minOccurs="0"/>
<element name="idnTableId" type="IDREF" minOccurs="0"/>
<element name="originalName" type="eppcom:labelType"
minOccurs="0"/>
<element name="status" type="domain:statusType"
maxOccurs="11"/>
<element name="rgpStatus" type="rgp:statusType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="registrant" type="eppcom:clIDType"
minOccurs="0"/>
<element name="contact" type="domain:contactType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="ns" type="domain:nsType" minOccurs="0"/>
<element name="clID" type="eppcom:clIDType"/>
<element name="crRr" type="rde:rrType"/>
<element name="crDate" type="dateTime" minOccurs="0"/>
<element name="exDate" type="dateTime" minOccurs="0"/>
<element name="upRr" type="rde:rrType" minOccurs="0"/>
<element name="upDate" type="dateTime" minOccurs="0"/>
<element name="secDNS" type="secDNS:dsOrKeyType"
Arias, et al. Expires September 13, 2013 [Page 37]
Internet-Draft DNRD Objects Mapping March 2013
minOccurs="0"/>
<element name="trDate" type="dateTime" minOccurs="0"/>
<element name="authInfo" type="domain:authInfoType"
minOccurs="0"/>
<element name="trnData" type="rdeDomain:transferDataType"
minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="transferDataType">
<sequence>
<element name="trStatus" type="eppcom:trStatusType"/>
<element name="reRr" type="rde:rrType"/>
<element name="reDate" type="dateTime"/>
<element name="acRr" type="rde:rrType"/>
<element name="acDate" type="dateTime"/>
<element name="exDate" type="dateTime" minOccurs="0"/>
</sequence>
</complexType>
<!-- Delete Type -->
<complexType name="deleteType">
<complexContent>
<extension base="rde:deleteType">
<sequence>
<element name="name" type="eppcom:labelType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
END
11.3.2. RDE Host Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
Arias, et al. Expires September 13, 2013 [Page 38]
Internet-Draft DNRD Objects Mapping March 2013
o 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.
o 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:rdeHost-1.0"
xmlns:rdeHost="urn:ietf:params:xml:ns:rdeHost-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-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 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:rde-1.0"
schemaLocation="rde-1.0.xsd"/>
<annotation>
<documentation>
Registry Data Escrow Host provisioning schema
</documentation>
</annotation>
<element name="host" type="rdeHost:contentType"
substitutionGroup="rde:content"/>
<element name="delete" type="rdeHost:deleteType"
Arias, et al. Expires September 13, 2013 [Page 39]
Internet-Draft DNRD Objects Mapping March 2013
substitutionGroup="rde:delete"/>
<!-- Content Type -->
<complexType name="contentType">
<complexContent>
<extension base="rde:contentType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="roid" type="eppcom:roidType"/>
<element name="status" type="host:statusType" maxOccurs="7"/>
<element name="addr" type="host:addrType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="clID" type="eppcom:clIDType"/>
<element name="crRr" type="rde:rrType"/>
<element name="crDate" type="dateTime"/>
<element name="upRr" type="rde:rrType" minOccurs="0"/>
<element name="upDate" type="dateTime" minOccurs="0"/>
<element name="trDate" type="dateTime" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- Delete Type -->
<complexType name="deleteType">
<complexContent>
<extension base="rde:deleteType">
<sequence>
<element name="name" type="eppcom:labelType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
END
11.3.3. RDE Contact Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
Arias, et al. Expires September 13, 2013 [Page 40]
Internet-Draft DNRD Objects Mapping March 2013
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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:rdeContact-1.0"
xmlns:rdeContact="urn:ietf:params:xml:ns:rdeContact-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-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:rde-1.0"
schemaLocation="rde-1.0.xsd"/>
<annotation>
<documentation>
Registry Data Escrow contact provisioning schema
</documentation>
</annotation>
Arias, et al. Expires September 13, 2013 [Page 41]
Internet-Draft DNRD Objects Mapping March 2013
<element name="abstractContact" type="rdeContact:abstractContentType"
substitutionGroup="rde:content" abstract="true"/>
<element name="contact"
substitutionGroup="rdeContact:abstractContact"/>
<element name="delete" type="rdeContact:deleteType"
substitutionGroup="rde:delete"/>
<!-- Contact Type -->
<complexType name="abstractContentType">
<complexContent>
<extension base="rde:contentType">
<sequence>
<element name="id" type="eppcom:clIDType"/>
<element name="roid" type="eppcom:roidType"/>
<element name="status" type="contact:statusType"
maxOccurs="7"/>
<element name="postalInfo" type="contact:postalInfoType"
maxOccurs="2"/>
<element name="voice" type="contact:e164Type" minOccurs="0"/>
<element name="fax" type="contact:e164Type" minOccurs="0"/>
<element name="email" type="eppcom:minTokenType"/>
<element name="clID" type="eppcom:clIDType"/>
<element name="crRr" type="rde:rrType"/>
<element name="crDate" type="dateTime"/>
<element name="upRr" type="rde:rrType" minOccurs="0"/>
<element name="upDate" type="dateTime" minOccurs="0"/>
<element name="trDate" type="dateTime" minOccurs="0"/>
<element name="trnData" type="rdeContact:transferDataType"
minOccurs="0"/>
<element name="disclose" type="contact:discloseType"
minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="transferDataType">
<sequence>
<element name="trStatus" type="eppcom:trStatusType"/>
<element name="reRr" type="rde:rrType"/>
<element name="reDate" type="dateTime"/>
<element name="acRr" type="rde:rrType"/>
<element name="acDate" type="dateTime"/>
</sequence>
</complexType>
<!-- Delete Type -->
Arias, et al. Expires September 13, 2013 [Page 42]
Internet-Draft DNRD Objects Mapping March 2013
<complexType name="deleteType">
<complexContent>
<extension base="rde:deleteType">
<sequence>
<element name="id" type="eppcom:clIDType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
END
11.3.4. RDE Registrar Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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
Arias, et al. Expires September 13, 2013 [Page 43]
Internet-Draft DNRD Objects Mapping March 2013
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rdeRegistrar-1.0"
xmlns:rdeRegistrar="urn:ietf:params:xml:ns:rdeRegistrar-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
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:contact-1.0"
schemaLocation="contact-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:rde-1.0"
schemaLocation="rde-1.0.xsd"/>
<annotation>
<documentation>
Registry Data Escrow registrar provisioning schema
</documentation>
</annotation>
<element name="abstractRegistrar"
type="rdeRegistrar:abstractContentType"
substitutionGroup="rde:content" abstract="true"/>
<element name="registrar"
substitutionGroup="rdeRegistrar:abstractRegistrar"/>
<element name="delete" type="rdeRegistrar:deleteType"
substitutionGroup="rde:delete"/>
<!-- Content Type -->
<complexType name="abstractContentType">
<complexContent>
<extension base="rde:contentType">
<sequence>
<element name="id" type="eppcom:clIDType"/>
<element name="name" type="rdeRegistrar:nameType"/>
<element name="gurid" type="positiveInteger" minOccurs="0"/>
<element name="status" type="rdeRegistrar:statusType"/>
<element name="postalInfo" type="rdeRegistrar:postalInfoType"
maxOccurs="2"/>
<element name="voice" type="contact:e164Type" minOccurs="0"/>
<element name="fax" type="contact:e164Type" minOccurs="0"/>
<element name="email" type="eppcom:minTokenType"/>
Arias, et al. Expires September 13, 2013 [Page 44]
Internet-Draft DNRD Objects Mapping March 2013
<element name="url" type="anyURI" minOccurs="0"/>
<element name="whoisInfo" type="rdeRegistrar:whoisInfoType"
minOccurs="0"/>
<element name="crDate" type="dateTime"/>
<element name="upDate" type="dateTime" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<simpleType name="nameType">
<restriction base="normalizedString">
<minLength value="1" />
<maxLength value="255" />
</restriction>
</simpleType>
<simpleType name="statusType">
<restriction base="token">
<enumeration value="ok"/>
<enumeration value="readonly"/>
<enumeration value="terminated"/>
</restriction>
</simpleType>
<complexType name="postalInfoType">
<sequence>
<element name="addr" type="rdeRegistrar:addrType" />
</sequence>
<attribute name="type" type="rdeRegistrar:postalInfoEnumType"
use="required" />
</complexType>
<simpleType name="postalInfoEnumType">
<restriction base="token">
<enumeration value="loc" />
<enumeration value="int" />
</restriction>
</simpleType>
<complexType name="addrType">
<sequence>
<element name="street" type="rdeRegistrar:optPostalLineType"
minOccurs="0" maxOccurs="3" />
<element name="city" type="rdeRegistrar:postalLineType" />
<element name="sp" type="rdeRegistrar:optPostalLineType"
minOccurs="0" />
<element name="pc" type="rdeRegistrar:pcType" minOccurs="0" />
Arias, et al. Expires September 13, 2013 [Page 45]
Internet-Draft DNRD Objects Mapping March 2013
<element name="cc" type="rdeRegistrar:ccType" />
</sequence>
</complexType>
<simpleType name="postalLineType">
<restriction base="normalizedString">
<minLength value="1" />
<maxLength value="255" />
</restriction>
</simpleType>
<simpleType name="optPostalLineType">
<restriction base="normalizedString">
<maxLength value="255" />
</restriction>
</simpleType>
<simpleType name="pcType">
<restriction base="token">
<maxLength value="16" />
</restriction>
</simpleType>
<simpleType name="ccType">
<restriction base="token">
<length value="2" />
</restriction>
</simpleType>
<complexType name="whoisInfoType">
<sequence>
<element name="name" type="eppcom:labelType" minOccurs="0"/>
<element name="url" type="anyURI" minOccurs="0"/>
</sequence>
</complexType>
<!-- Delete Type -->
<complexType name="deleteType">
<complexContent>
<extension base="rde:deleteType">
<sequence>
<element name="id" type="eppcom:clIDType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Arias, et al. Expires September 13, 2013 [Page 46]
Internet-Draft DNRD Objects Mapping March 2013
END
11.3.5. RDE IDN and IDN Table Reference Objects
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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.
Arias, et al. Expires September 13, 2013 [Page 47]
Internet-Draft DNRD Objects Mapping March 2013
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rdeIDN-1.0"
xmlns:rdeIDN="urn:ietf:params:xml:ns:rdeIDN-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"/>
<annotation>
<documentation>
Registry Data Escrow IDN provisioning schema
</documentation>
</annotation>
<element name="idnTableRef" type="rdeIDN:contentType"
substitutionGroup="rde:content"/>
<!-- Content Type -->
<complexType name="contentType">
<complexContent>
<extension base="rde:contentType">
<sequence>
<element name="url" type="anyURI"/>
<element name="urlPolicy" type="anyURI"/>
</sequence>
<attribute name="id" type="rdeIDN:IdType" use="required"/>
</extension>
</complexContent>
</complexType>
<simpleType name="IdType">
<restriction base="ID">
<whiteSpace value="collapse"/>
</restriction>
</simpleType>
</schema>
END
11.3.6. EPP Parameters Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
Arias, et al. Expires September 13, 2013 [Page 48]
Internet-Draft DNRD Objects Mapping March 2013
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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.
Arias, et al. Expires September 13, 2013 [Page 49]
Internet-Draft DNRD Objects Mapping March 2013
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rdeEppParams-1.0"
xmlns:rdeEppParams="urn:ietf:params:xml:ns:rdeEppParams-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<import namespace="urn:ietf:params:xml:ns:epp-1.0"
schemaLocation="epp-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:rde-1.0"
schemaLocation="rde-1.0.xsd"/>
<annotation>
<documentation>
Registry Data Escrow EPP Parameters schema
</documentation>
</annotation>
<!-- Content Type -->
<element name="eppParams"
substitutionGroup="rdeEppParams:abstractEppParams"/>
<!-- Abstract Content Type -->
<element name="abstractEppParams"
type="rdeEppParams:abstractContentType"
substitutionGroup="rde:content" abstract="true"/>
<complexType name="abstractContentType">
<complexContent>
<extension base="rde:contentType">
<sequence>
<element name="version" type="epp:versionType"
maxOccurs="unbounded"/>
<element name="lang" type="language" maxOccurs="unbounded"/>
<element name="objURI" type="anyURI" maxOccurs="unbounded"/>
<element name="svcExtension" type="epp:extURIType"
minOccurs="0"/>
<element name="dcp" type="epp:dcpType"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
END
Arias, et al. Expires September 13, 2013 [Page 50]
Internet-Draft DNRD Objects Mapping March 2013
11.3.7. NNDN Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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:rdeNNDN-1.0"
xmlns:rdeNNDN="urn:ietf:params:xml:ns:rdeNNDN-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:rde-1.0"
schemaLocation="rde-1.0.xsd"/>
Arias, et al. Expires September 13, 2013 [Page 51]
Internet-Draft DNRD Objects Mapping March 2013
<annotation>
<documentation>
Registry Data Escrow NNDN provisioning schema
</documentation>
</annotation>
<element name="abstractNNDN" type="rdeNNDN:abstractContentType"
substitutionGroup="rde:content" abstract="true"/>
<element name="NNDN" substitutionGroup="rdeNNDN:abstractNNDN"/>
<element name="delete" type="rdeNNDN:deleteType"
substitutionGroup="rde:delete"/>
<!-- Content Type -->
<complexType name="abstractContentType">
<complexContent>
<extension base="rde:contentType">
<sequence>
<element name="aName" type="eppcom:labelType"/>
<element name="uName" type="eppcom:labelType" minOccurs="0"/>
<element name="idnTableId" type="IDREF" minOccurs="0"/>
<element name="originalName" type="eppcom:labelType"
minOccurs="0"/>
<element name="nameState" type="rdeNNDN:nameState"/>
<element name="crDate" type="dateTime"/>
</sequence>
</extension>
</complexContent>
</complexType>
<simpleType name="nameState">
<restriction base="token">
<enumeration value="withheld"/>
<enumeration value="blocked"/>
</restriction>
</simpleType>
<!-- Delete Type -->
<complexType name="deleteType">
<complexContent>
<extension base="rde:deleteType">
<sequence>
<element name="aName" type="eppcom:labelType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Arias, et al. Expires September 13, 2013 [Page 52]
Internet-Draft DNRD Objects Mapping March 2013
END
11.3.8. Header Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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.
Arias, et al. Expires September 13, 2013 [Page 53]
Internet-Draft DNRD Objects Mapping March 2013
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rdeHeader-1.0"
xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd" />
<import namespace="urn:ietf:params:xml:ns:rde-1.0"
schemaLocation="rde-1.0.xsd"/>
<annotation>
<documentation>
Registry Data Escrow Header schema
</documentation>
</annotation>
<!-- Root Element -->
<element name="header" type="rdeHeader:contentType"
substitutionGroup="rde:content"/>
<!-- Content Type -->
<complexType name="contentType">
<complexContent>
<extension base="rde:contentType">
<sequence>
<element name="tld" type="eppcom:labelType"/>
<element name="count" type="rdeHeader:countType"
maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="countType">
<simpleContent>
<extension base="long">
<attribute name="uri" type="anyURI"/>
</extension>
</simpleContent>
</complexType>
</schema>
END
Arias, et al. Expires September 13, 2013 [Page 54]
Internet-Draft DNRD Objects Mapping March 2013
11.3.9. Report Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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.
Arias, et al. Expires September 13, 2013 [Page 55]
Internet-Draft DNRD Objects Mapping March 2013
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="reDate" type="dateTime"/>
<element name="vaDate" type="dateTime" minOccurs="0"/>
<element name="kind" type="rde:depositTypeType"/>
<element name="lastFullDate" type="date"/>
<element name="watermark" type="dateTime"/>
<element ref="rdeHeader:header"/>
</sequence>
</complexType>
</schema>
END
11.3.10. Notifiaction Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
Arias, et al. Expires September 13, 2013 [Page 56]
Internet-Draft DNRD Objects Mapping March 2013
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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.
Arias, et al. Expires September 13, 2013 [Page 57]
Internet-Draft DNRD Objects Mapping March 2013
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="reDate" type="date"/>
<element name="status" type="rdeNotification:statusType"/>
<element ref="rdeReport:report"/>
</sequence>
</complexType>
<simpleType name="statusType">
<restriction base="token">
<enumeration value="valid"/>
<enumeration value="invalid"/>
<enumeration value="missing"/>
</restriction>
</simpleType>
</schema>
END
11.4. Policy Object
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
Arias, et al. Expires September 13, 2013 [Page 58]
Internet-Draft DNRD Objects Mapping March 2013
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o 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.
o 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.
Arias, et al. Expires September 13, 2013 [Page 59]
Internet-Draft DNRD Objects Mapping March 2013
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rdePolicy-1.0"
xmlns:rdePolicy="urn:ietf:params:xml:ns:rdePolicy-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<annotation>
<documentation>
Registry Data Escrow Policy schema
</documentation>
</annotation>
<import namespace="urn:ietf:params:xml:ns:rde-1.0"
schemaLocation="rde-1.0.xsd"/>
<element name="policy" type="rdePolicy:policyType"
substitutionGroup="rde:content"/>
<complexType name="policyType">
<complexContent>
<extension base="rde:contentType">
<attribute name="element" type="anyURI" use="required"/>
</extension>
</complexContent>
</complexType>
</schema>
END
12. Internationalization Considerations
Data Escrow deposits are represented in XML, which provides native
support for encoding information using the Unicode character set and
its more compact representations including UTF-8. Conformant XML
processors recognize both UTF-8 and UTF-16. Though XML includes
provisions to identify and use other character encodings through use
of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
RECOMMENDED.
13. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. Fourteen
URI assignments have been registered by the IANA.
Arias, et al. Expires September 13, 2013 [Page 60]
Internet-Draft DNRD Objects Mapping March 2013
Registration request for the RDE domain namespace:
URI: urn:ietf:params:xml:ns:rdeDomain-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the RDE domain XML schema:
URI: urn:ietf:params:xml:schema:rdeDomain-1.0
Registrant Contact: See the "Author's Address" section of this
document.
See the "Formal Syntax" section of this document.
Registration request for the RDE host namespace:
URI: urn:ietf:params:xml:ns:rdeHost-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the RDE host XML schema:
URI: urn:ietf:params:xml:schema:rdeHost-1.0
Registrant Contact: See the "Author's Address" section of this
document.
See the "Formal Syntax" section of this document.
Registration request for the RDE contact namespace:
URI: urn:ietf:params:xml:ns:rdeContact-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the RDE contact XML schema:
Arias, et al. Expires September 13, 2013 [Page 61]
Internet-Draft DNRD Objects Mapping March 2013
URI: urn:ietf:params:xml:schema:rdeContact-1.0
Registrant Contact: See the "Author's Address" section of this
document.
See the "Formal Syntax" section of this document.
Registration request for the RDE registrar namespace:
URI: urn:ietf:params:xml:ns:rdeRegistrar-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the RDE registrar XML schema:
URI: urn:ietf:params:xml:schema:rdeRegistrar-1.0
Registrant Contact: See the "Author's Address" section of this
document.
See the "Formal Syntax" section of this document.
Registration request for the RDE IDN namespace:
URI: urn:ietf:params:xml:ns:rdeIDN-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the RDE IDN XML schema:
URI: urn:ietf:params:xml:schema:rdeIDN-1.0
Registrant Contact: See the "Author's Address" section of this
document.
See the "Formal Syntax" section of this document.
Registration request for the RDE EPP parameters namespace:
URI: urn:ietf:params:xml:ns:rdeEppParams-1.0
Arias, et al. Expires September 13, 2013 [Page 62]
Internet-Draft DNRD Objects Mapping March 2013
Registrant Contact: See the "Author's Address" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the RDE EPP parameters XML schema:
URI: urn:ietf:params:xml:schema:rdeEppParams-1.0
Registrant Contact: See the "Author's Address" section of this
document.
See the "Formal Syntax" section of this document.
14. Security Considerations
This specification does not define the security mechanisms to be used
in the transmission of the data escrow deposits, since it only
specifies the minimum necessary to enable the rebuilding of a
Registry from deposits without intervention from the original
Registry.
Depending on local policies, some elements or most likely, the whole
deposit will be considered confidential. As such the Registry
transmitting the data to the Escrow Agent SHOULD take all the
necessary precautions like encrypting the data itself and/or the
transport channel to avoid inadvertent disclosure of private data.
It is also of the utmost importance the authentication of the parties
passing data escrow deposit files. The Escrow Agent SHOULD properly
authenticate the identity of the Registry before accepting data
escrow deposits. In a similar manner, the Registry SHOULD
authenticate the identity of the Escrow Agent before submitting any
data.
Additionally, the Registry and the Escrow Agent SHOULD use integrity
checking mechanisms to ensure the data transmitted is what the source
intended. Validation of the contents by the Escrow Agent is
RECOMMENDED to ensure not only the file was transmitted correctly
from the Registry, but also the contents are also "meaningful".
15. Acknowledgments
Parts of this document are based on EPP [RFC5730] and related RFCs by
Scott Hollenbeck.
Arias, et al. Expires September 13, 2013 [Page 63]
Internet-Draft DNRD Objects Mapping March 2013
TBD
16. Change History
[[RFC Editor: Please remove this section.]]
16.1. Changes from draft-arias-noguchi-registry-data-escrow-02 to
-dnrd-objects-mapping-00
1. Added definition for child elements under the <domain> element.
2. Added definition for child elements under the <host> element.
3. Added definition for child elements under the <contact> element.
4. Rewrote the IDN Variants Handling section to use the variant
states as described in ICANN's Study of Issues Related to the
Management of IDN Variant TLDs.
5. Renamed <icannID> to <gurid> in the <rdeRegistrar>.
6. Renamed <dnssec> to <secDNS> in the <domain> element.
7. Renamed <transfData> to <trnData> in the <domain> element.
8. Added <whoisInfo> element under <rdeRegistrar> element.
9. Fixed some typographical errors and omissions.
16.2. Changes from version 00 to 01
1. Specify OPTIONAL elements in the draft.
2. Added NNDN object to support list of reserved names and different
IDN variants models.
3. Removed subordinated host element from the domain object.
4. Added eppParams object.
5. Added variantGenerator element to the domain object.
6. Added lgr to the IDN table object.
Arias, et al. Expires September 13, 2013 [Page 64]
Internet-Draft DNRD Objects Mapping March 2013
16.3. Changes from version 01 to 02
1. Updates to the all objects based on feedback from the list.
2. Start of XML and CSV drafts merge.
3. Added header object.
4. Added report object.
5. Added notification object.
6. Added Data Escrow Agent Extended Verification Process section.
7. Added Notifications from Registries to Third Parties.
8. Added Notifications from Data Escrow Agents to Third Parties.
9. Added FULL, DIFF deposit examples using the XML model only.
17. References
17.1. Normative References
[ISO-3166-1]
International Organization for Standardization, "Codes for
the representation of names of countries and their
subdivisions -- Part 1: Country codes", ISO Standard 3166,
November 2006.
[ITU-E164]
International Telecommunication Union, "The international
public telecommunication numbering plan", ITU-T
Recommendation E.164, February 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for
the Extensible Provisioning Protocol (EPP)", RFC 3915,
September 2004.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, August 2009.
Arias, et al. Expires September 13, 2013 [Page 65]
Internet-Draft DNRD Objects Mapping March 2013
[RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", STD 69, RFC 5732, August 2009.
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", STD 69, RFC 5733, August 2009.
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 5910, May 2010.
17.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
Engineering Team (JET) Guidelines for Internationalized
Domain Names (IDN) Registration and Administration for
Chinese, Japanese, and Korean", RFC 3743, April 2004.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004.
[RFC4290] Klensin, J., "Suggested Practices for Registration of
Internationalized Domain Names (IDN)", RFC 4290,
December 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009.
[variantTLDsReport]
Internet Corporation for Assigned Names and Numbers
(ICANN), "A Study of Issues Related to the Management of
IDN Variant TLDs", February 2012, <http://www.icann.org/
en/topics/idn/
idn-vip-integrated-issues-final-clean-20feb12-en.pdf>.
Arias, et al. Expires September 13, 2013 [Page 66]
Internet-Draft DNRD Objects Mapping March 2013
Authors' Addresses
Francisco Arias
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles 90292
United States of America
Phone: +1.310.823.9358
Email: francisco.arias@icann.org
Gustavo Lozano
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles 90292
United States of America
Phone: +1.310.823.9358
Email: gustavo.lozano@icann.org
Shoji Noguchi
Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
Phone: +81.3.5215.8451
Email: noguchi@jprs.co.jp
James Gould
VeriSign, Inc.
12061 Bluemont Way
Reston 20190
United States of America
Email: jgould@verisign.com
Arias, et al. Expires September 13, 2013 [Page 67]
Internet-Draft DNRD Objects Mapping March 2013
Chethan Thippeswamy
VeriSign, Inc.
12061 Bluemont Way
Reston 20190
United States of America
Email: cthippeswamy@verisign.com
Arias, et al. Expires September 13, 2013 [Page 68]