RFC 9022: Domain Name Registration Data (DNRD) Objects Mapping
- G. Lozano,
- J. Gould,
- C. Thippeswamy
Abstract
This document specifies the format, contents, and semantics of Domain Name Registration Data (DNRD) escrow deposits for a domain name registry.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2021 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
(https://
1. Introduction
Registry Data Escrow (RDE) is the process by which a registry periodically submits data deposits to a third party called an escrow agent. These deposits comprise the minimum data needed by a third party to resume operations if the registry cannot function and is unable or unwilling to facilitate an orderly transfer of service. For example, for a domain name registry or registrar, the data to be deposited would include all the objects related to registered domain names, e.g., names, contacts, name servers, etc.¶
The goal of data escrow is higher resiliency of registration services for the benefit of Internet users. The beneficiaries of a registry are not just those registering information there, but also the users of services relying on the registry data.¶
In the context of domain name registries, registration data escrow is
a requirement for generic top-level domains (e.g., Specification 2 of the ICANN Base Registry Agreement, see [ICANN
This document defines the standard set of objects for a domain name registry that uses the Registry Data Escrow Specification described in [RFC8909] for escrow. The set of objects include:¶
- Domain:
- Internet domain names that are typically provisioned in a domain name registry using the Extensible Provisioning Protocol (EPP) domain name mapping [RFC5731]. The attributes defined in the EPP domain name mapping [RFC5731] are fully supported by this document.¶
- 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.¶
- 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.¶
- Registrar:
- The organization that sponsors objects like domains, hosts, and contacts in a domain name registry.¶
- NNDN (NNDN's not domain name):
- Domain Name Registries may maintain domain names without being persisted as domain objects in the registry system, for example, a list of reserved names not available for registration. The NNDN is a lightweight domain-like object that is used to escrow domain names not maintained as domain name objects.¶
This document defines the following pseudo-objects:¶
- IDN table reference:
- Internationalize
d Domain Names (IDN) included in the domain object data escrow include references to the IDN table and policy used in IDN registration.¶ - EPP parameters:
- Contains the EPP parameters supported by the registry operator.¶
- Header:
- Used to specify counters of objects in the database at a certain point in time (Timeline Watermark).¶
- Policy:
- Used to specify OPTIONAL elements from this specification that are REQUIRED based on the business model of the registry.¶
Extensible Markup Language (XML) 1.0 as described in [W3C
2. Models
This document defines two different models that can be used to
deposit data escrow objects: XML and CSV
The data escrow deposit MAY contain a mix of both models, but an object MUST be escrowed only in one model.¶
This document does not suggest the use of a particular model, and both are equivalent. A domain name registry may choose the model that is more appropriate for the peculiarities of its systems. For example, a registry may use the CSV-export functionality of the Relational Database Management System (RDBMS) for escrow; therefore, the CSV model may be more appropriate. Another registry may use the code developed for EPP to implement escrow.¶
2.1. XML Model
The XML model includes all the deposit information (metadata
and data) in an XML document. The definition of the XML format is
fully defined in the XML schemas. As a convention, the objects represented
using the XML model are referenced using RDE and an XML namespace that is
prefixed with "rde". For example, the Domain Name object represented using
the XML model can be referred to as the RDE Domain Name with the XML
namespace including rdeDomain
2.2. CSV Model
The CSV model uses XML to define the data escrow format of the
data contained in referenced CSV files. As a
convention, the objects represented using the CSV model is referenced
using CSV and an XML namespace that is prefixed with "csv". For example,
the domain name object represented using the CSV model can be referred
to as the CSV Domain Name with the XML namespace including csvDomain
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
3.1. Glossary
In the following section, the most common terms are briefly explained:¶
- Allocated:
- A status of some label with respect to a zone, whereby the label is associated administrativel
y to some entity that has requested the label. This term (and its cognates "allocation" and "to allocate") may represent the first step on the way to delegation in the DNS.¶ - Comma-Separated Values (CSV):
- See [RFC4180].¶
- Domain Name:
- See the definition of Domain Name in Section 2 of [RFC8499].¶
- Extensible Provisioning Protocol (EPP):
- See the definition of the Extensible Provisioning Protocol in Section 9 of [RFC8499].¶
- Fully-Qualified Domain Name (FQDN):
- See the definition of FQDN in Section 2 of [RFC8499].¶
-
Internationaliz
ed Domain Name (IDN): - See the definition of Internationaliz
ed Domain Name in Section 2 of [RFC8499].¶ - Label
- See the definition of Label in Section 2 of [RFC8499].¶
- Registrant:
- See the definition of Registrant in Section 9 of [RFC8499].¶
- Registrar:
- See the definition of Registrar in Section 9 of [RFC8499].¶
- Registry:
- See the definition of Registry in Section 9 of [RFC8499].¶
- 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 an affiliate company) provides Registry Services for other organizations or individuals. For example: .COM, .ORG, .BIZ, .CO.JP, .B.BR.¶
- Registry Data Escrow (RDE):
- Registry Data Escrow is the process by which a registry periodically submits data deposits to a third party called an escrow agent. These deposits comprise the minimum data needed by a third party to resume operations if the registry cannot function and is unable or unwilling to facilitate an orderly transfer of service.¶
- 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; responding to queries for contact and other information concerning DNS registrations in the RCDN; and 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.¶
- SRS:
- Shared Registration System, see also [ICANN
-GTLD ].¶-AGB -20120604 - Top-Level Domain Name (TLD):
- See the definition of Top-Level Domain in Section 2 of [RFC8499].¶
- UTC:
- Coordinated Universal Time, as maintained by the Bureau International des Poids et Mesures (BIPM), see also [RFC3339].¶
4. Conventions Used in This Document
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 facsimile) 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 0x2B), followed by a country code defined in [ITU-E164], followed by a dot (".", ASCII value 0x2E), followed by a sequence of digits representing the telephone number.¶
4.4. CSV Integrity Check
A checksum MAY be used to verify the integrity of the CSV files, for example, if another layer (i.e., encryption of an archive containing the deposit files) does not provide integrity. By default, the CRC32 algorithm (see Section 8.1.1.6.2 of [V42]) is used. A stronger algorithm, such as SHA-256 (see [RFC6234]) MAY be used for enhanced security if required.¶
4.5. IP Addresses
The syntax of IP addresses MUST conform to the text representation of either Internet Protocol Version 4 [RFC0791] or Internet Protocol Version 6 [RFC5952].¶
4.6. Conventions Applicable to the CSV Model
4.6.1. CSV Parent Child Relationship
The CSV model represents a relational model where the CSV files represent relational tables, the fields of the CSV files represent columns of the tables, and each line of the CSV file represents a record. As in a relational model, the CSV files can have relationships utilizing primary keys in the parent CSV file definitions and foreign keys in the child CSV file definitions for a one-to-many relationship. The primary keys are not explicitly defined, but the foreign keys are using the boolean "parent" field attribute in the child CSV file. The relationships between the CSV files are used to support a cascade replace or cascade delete of records starting from the parent record in Differential and Incremental Deposits (see [RFC8909]).¶
The following is an example of the CSV file definitions, using the element <rdeCsv:csv> (see Section 4.6.2.1), for a Sample object consisting of a parent "sample" CSV File Definition
and a child "sample
4.6.2. CSV Elements
4.6.2.1. <rdeCsv:csv> Element
To support the CSV model, an element is defined
for each object that substitutes for the <rde:content> element and for the <rde:delete> element, that contains one or more
<rdeCsv:csv> elements. For example, the 'Domain Name Object' (Section 5.1) defines the <csv
- <rdeCsv:fields>
- Ordered list of CSV fields used in the CSV files. There are one or more
child elements that substitute for the <rdeCsv:field> abstract element. Each element
defines the format of the CSV field contained in the CSV files. The <rdeCsv:field> elements
support the "type" attribute that defines the XML simple data type of the field element. The <rdeCsv:field>
elements support the "isRequired" attribute, which has a default value of "false". When set to "true", this indicates that the field must be non-empty
in the CSV files, and when set to "false", this indicates that the field MAY be empty in the CSV files. The "isRequired"
attribute MAY be specifically set for the field elements within the XML schema and MAY be overridden when specifying
the fields under the <rdeCsv:fields> element. The <rdeCsv:field> element supports an OPTIONAL "parent" attribute
that identifies the field as a reference to a parent object, as defined in the 'CSV Parent Child Relationship' (Section 4.6.1).
For example, the <rdeCsv:csv name
="domain Statuses"> <csv Domain :f Name> field SHOULD set the "parent" attribute to "true" to identify it as the parent domain name of the domain status.¶ - <rdeCsv:files>
-
A list of one or more CSV files using the <rdeCsv:file> child element. The <rdeCsv:file> child element defines a reference to the CSV file name and has the following optional attributes:¶
- compression
- If the CSV file is compressed, the "compression" attribute defines the compression format. For example, setting this attribute to "gzip" signals that the CSV file is compressed using the GZIP file format (see [RFC1952]). The supported compression formats are negotiated out of band.¶
- encoding
- Defines the encoding of the CSV file with the default encoding of "UTF-8".¶
- cksum
- Defines the checksum of the CSV file, as described in Section 4.4, using the algorithm defined by the "cksumAlg" attribute. If the "cksumAlg" attribute is not present, the checksum is calculated using "CRC32".¶
- cksumAlg
- Defines the checksum algorithm used to calculate the "cksum" attribute, with the default value of "CRC32". If the value "SHA256" is specified, the SHA-256 algorithm (see [RFC6234]) MUST be used to calculate the "cksum" attribute. Parties receiving and processing data escrow deposits MUST support CRC32 and SHA-256. If this attribute is present, the "cksum" attribute MUST also be present. Additional checksum algorithms are negotiated out of band.¶
The <rdeCsv:csv> element requires a "name" attribute that defines the purpose of the CSV file with values like "domain", "host", "contact". The supported "name" attribute values are defined for each object type. The OPTIONAL "sep" attribute defines the CSV separator character with the default separator character of ",". The need for quoting or escaping of the CSV data could be avoided by choosing a separator character that is not in the data set of the CSV files.¶
The following is an example of the <csv
The following is an example of the domain
The following is an example of the <csv
The following is example of the domain
4.6.2.2. CSV Common Field Elements
The <rdeCsv:fields> element defined in the
'<rdeCsv:csv> Element' (Section 4.6.2.1)
has child elements that substitute for the abstract <rdeCsv:field> element.
By convention, <rdeCsv:field> elements include an "f" prefix to identify them as field
definition elements. There are a set of common field elements that are used across
multiple data escrow objects. The common field elements are defined using the
"urn
- <rdeCsv:fUName>
- UTF-8 encoded name field with type
="eppcom :label Type" .¶ - <rdeCsv:fRoid>
- Repository Object IDentifier (ROID) field with type
="eppcom :roid Type" and is Required ="true" .¶ - <rde
Csv :f Registrant> - Registrant contact identifier with type
="eppcom :cl IDType" .¶ - <rde
Csv :f Status Description> - The object status description, which is free-form text describing the rationale for the status, with type
="normalized String" .¶ - <rdeCsv:fClID>
- Identifier of the client (registrar) that sponsors the object with type
="eppcom :cl IDType" and is Required ="true" .¶ - <rdeCsv:fCrRr>
- Identifier of the registrar, defined in Section 5.4, of the client that created the object with type
="eppcom :cl IDType" .¶ - <rdeCsv:fCrID>
- Identifier of the client that created the object with type
="eppcom :cl IDType" .¶ - <rdeCsv:fUpRr>
- Identifier of the registrar, defined in Section 5.4, of the client that last updated the object with type
="eppcom :cl IDType" .¶ - <rdeCsv:fUpID>
- Identifier of the client that last updated the object with type
="eppcom :cl IDType" .¶ - <rdeCsv:fReRr>
- Identifier of the registrar, defined in Section 5.4, of the client that requested the transfer with type
="eppcom :cl IDType" and is Required ="true" .¶ - <rdeCsv:fReID>
- Identifier of the client that requested the transfer with type
="eppcom :cl IDType" .¶ - <rdeCsv:fAcRr>
- Identifier of the registrar, defined in Section 5.4, of the client that should take or took action with type
="eppcom :cl IDType" and is Required ="true" .¶ - <rdeCsv:fAcID>
- Identifier of the client that should take or took action for transfer with type
="eppcom :cl IDType" .¶ - <rdeCsv:fCrDate>
- Created date of object with type
="date Time" .¶ - <rdeCsv:fUpDate>
- Updated date of object with type
="date Time" .¶ - <rdeCsv:fExDate>
- Expiration date of object with type
="date Time" .¶ - <rdeCsv:fReDate>
- Date that transfer was requested with type="dateTime" and is
Required ="true" .¶ - <rdeCsv:fAcDate>
- Date that transfer action should be taken or has been taken with type="dateTime" and is
Required ="true" .¶ - <rdeCsv:fTrDate>
- Date of last transfer with type
="date Time" .¶ - <rde
Csv :f Tr Status> - State of the most recent transfer request with type
="eppcom :tr Status Type" and is Required ="true" .¶ - <rde
Csv :f Token Type> - General token field with type="token".¶
- <rdeCsv:fLang>
- General language field with type
="language" .¶ - <rde
Csv :f Idn Table Id> - IDN table identifier used for IDN domain names with type="token".¶
- <rde
Csv :f Positive Integer Type> - General positive integer field with type
="positive Integer" .¶ - <rdeCsv:fUrl>
- Contains the URL of an object like a registrar object with type="anyURI".¶
- <rdeCsv:fCustom>
- Custom field with name attribute that defines the custom field name with type="token".¶
4.6.3. Internationalized and Localized Elements
Some elements MAY be provided in either internationaliz
The field elements below of the "registrar" <rdeCsv:csv> <rdeCsv:fields> element
specify the internationaliz
The following is an example of using the <csv
5. Object Description
This section describes the base objects supported by this specification:¶
5.1. Domain Name Object
The domain name object is based on the EPP domain name mapping specified in [RFC5731]. The domain name object supports both the XML model and the CSV model, defined in 'Models' (Section 2). The elements used for both models are defined in the following sections.¶
5.1.1. XML Model
There are
two elements used in the data escrow of the domain name objects for the XML model, including the
<rde
5.1.1.1. <rdeDomain: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 [RFC5731], Registry Grace Period (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 <abstract
The <domain> element contains the following child elements:¶
The following is an example of a domain name object:¶
5.1.1.2. <rdeDomain:delete> Object
The <rde
The following is an example of an <rde
5.1.2. CSV Model
For the CSV model of the domain name object, the <csv
Differential and Incremental Deposits are based on changes to the domain name objects. The updated domain name object
data under the <csv
5.1.2.1. <csvDomain:contents>
The <csv
5.1.2.1.1. "domain" CSV File Definition
The "domain" CSV File Definition defines the fields and CSV file references
used for the parent domain name object records. All the other domain name CSV file definitions are
child CSV files based on the inclusion of the <csv
The following "csvDomain" field elements MUST be used in the "domain" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Domain :f Name> - Domain name field with type
="eppcom :label Type" and is Required ="true" .¶
The following "csvDomain" field elements MAY be used in the "domain" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Domain :f Original Name> - Fully qualified name of the original IDN domain name object related to the
variant domain name object with type
="eppcom :label Type" .¶
The following "rdeCsv" and "csvRegistrar" fields, MUST be used in the "domain" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fRoid>
- ROID for the domain name object with is
Required ="true" .¶ - <rdeCsv:fClID> or <csv
Registrar :f Gurid> -
A choice of the following:¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2), MAY be used in the "domain" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fCrRr>
- Identifier of the registrar, defined in Section 5.4, of the client that created the domain name object.¶
- <rdeCsv:fCrID>
- Identifier of the client that created the domain name object.¶
- <rdeCsv:fUpRr>
- Identifier of the registrar, defined in Section 5.4, of the client that last updated the domain name object.¶
- <rdeCsv:fUpID>
- Identifier of the client that last updated the domain name object.¶
- <rdeCsv:fUName>
- UTF-8 encoded domain name for the <csv
Domain :f Name> field element.¶ - <rde
Csv :f Idn Table Id> - IDN table identifier used for the IDN domain name object that MUST match an <rde
Csv :f Idn Table Id> field element in the "idnLanguage" CSV files, as defined in Section 5.5.2.¶ - <rde
Csv :f Registrant> - Registrant contact identifier for the domain name object.¶
- <rdeCsv:fCrDate>
- Date and time of the domain name object creation.¶
- <rdeCsv:fUpDate>
- Date and time of the last update to the domain name object. This field MUST NOT be set if the domain name object has never been modified.¶
- <rdeCsv:fExDate>
- Expiration date and time for the domain name object.¶
- <rdeCsv:fTrDate>
- Date and time of the last transfer for the domain name object. This field MUST NOT be set if the domain name object has never been transferred.¶
The following is an example of a "domain" <csv
The following is an example of the corresponding domain
5.1.2.1.2. "domainContacts" CSV File Definition
The "domain
The following "csvDomain" field elements, defined for the '"domain" CSV File Definition' (Section 5.1.2.1.1),
MUST be used in the "domain
- <csv
Domain :f Name> - The name of the domain object that is linked to the contact object with is
Required ="true" .¶ - <csv
Domain :f Contact Type> - The contact type for the contact object link with type
="domain :contact Attr Type" and is Required ="true" . The supported contact type values include "admin" for the administration contact, "billing" for the billing contact, and "tech" for the technical contact.¶
The following "csvContact" fields, defined for the '"contact" CSV File Definition' (Section 5.3.2.1.1),
MUST be used in the "domain
- <csvContact:fId>
- The server-unique contact identifier with is
Required ="true" .¶
The following is an example of a "domain
The following is an example of the corresponding domain
5.1.2.1.3. "domainStatuses" CSV File Definition
The "domain
The following "csvDomain" fields, defined for the '"domain" CSV File Definition' (Section 5.1.2.1.1),
MUST be used in the "domain
- <csv
Domain :f Name> - Domain name of status with is
Required ="true" .¶ - <csv
Domain :f Status> - The status of the domain name with type
="domain :status Value Type" and is Required ="true" .¶ - <csv
Domain :f Rgp Status> - The RGP status, as a sub-status of the <csv
Domain :f Status> "pendingDelete" status value, with type ="rgp :status Value Type" as defined in [RFC3915].¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2),
MAY be used in the "domain
- <rde
Csv :f Status Description> - Domain name object status description, which is free-form text describing the rationale for the status.¶
- <rdeCsv:fLang>
- Language of the <rde
Csv :f Status Description> field.¶
The following is an example of a "domain
The following is an example of the corresponding domain
5.1.2.1.4. "domainNameServers" CSV File Definition
The "domain
The following "csvDomain" fields, defined for the '"domain" CSV File Definition' (Section 5.1.2.1.1),
MUST be used in the "domain
- <csv
Domain :f Name> - Domain name using the delegated host with is
Required ="true" .¶
The following "csvHost" and "rdeCsv" field elements MUST be used in the "domain
- <csvHost:fName> or <rdeCsv:fRoid>
-
A choice of the following:¶
The following is an example of a "domain
The following is an example of the corresponding domain
5.1.2.1.5. "domainNameServersAddresses" CSV File Definition
The "domain
The following "csvDomain" fields, defined for the '"domain" CSV File Definition' (Section 5.1.2.1.1),
MUST be used in the "domain
- <csv
Domain :f Name> - Domain name using the delegated host with host <csvHost:fName> and is
Required ="true" .¶
The following "rdeCsv" fields, defined in 'CSV Model' (Section 5.2.2),
MUST be used in the "domain
- <csvHost:fName>
- Host name field with type
="eppcom :label Type" and is Required ="true" .¶
The following "csvHost" fields, defined in 'CSV Model' (Section 5.2.2),
MAY be used in the "domain
- <csvHost:fAddr>
- IP addresses associated with the host object with type
="host :addr String Type" .¶ - <csv
Host :f Addr Version> - IP addresses version associated with the host object with type
="host :ip Type" . "host:ipType" has the enumerated values of "v4" or "v6".¶
The following is an example of a "domain
The following is an example of the corresponding domain
5.1.2.1.6. "dnssec" CSV File Definition
The "dnssec" CSV File Definition defines the fields and CSV file references used for the domain name object DNSSEC records (Delegation Signer (DS) or key data).¶
The following "csvDomain" field elements MUST be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element when the DS Data Interface per [RFC5910] is used:¶
- <csv
Domain :f Key Tag> - Contains the DS key tag value per [RFC5910] with type
="unsigned Short" and is Required ="true" .¶ - <csv
Domain :f Ds Alg> - Contains the DS algorithm value per [RFC5910] with type
="unsigned Byte" and is Required ="true" .¶ - <csv
Domain :f Digest Type> - Contains the DS digest type value per [RFC5910] with type
="unsigned Byte" and is Required ="true" .¶ - <csv
Domain :f Digest> - Contains the DS digest value per [RFC5910] with type
="hex Binary" and is Required ="true" .¶
The following "csvDomain" field elements MUST be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element when the Key Data Interface per [RFC5910] is used and MAY be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element when the DS Data Interface per [RFC5910] is used:¶
- <csv
Domain :f Flags> - Contains the flags field value per [RFC5910] with type
="unsigned Short" and is Required ="true" .¶ - <csv
Domain :f Protocol> - Contains the key protocol value per [RFC5910] with type
="unsigned Byte" and is Required ="true" .¶ - <csv
Domain :f Key Alg> - Contains the key algorithm value per [RFC5910] with type
="unsigned Byte" and is Required ="true" .¶ - <csv
Domain :f Pub Key> - Contains the public key value per [RFC5910] with type
="sec DNS :key Type" and is Required ="true" .¶
The following "csvDomain" field elements MAY be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Domain :f Max Sig Life> - Indicates a child's preference for the number of seconds
after signature generation when the parent's signature on the DS information provided by the child
will expire with type
="sec DNS :max Sig Life Type" defined in [RFC5910].¶
The following "domain" fields, defined for the '"domain" CSV File Definition' (Section 5.1.2.1.1), MUST be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Domain :f Name> - Domain name of the domain name object associated with the DNSSEC record and is
Required ="true" .¶
The following is an example of a "dnssec" <csv
The following is an example of the corresponding dnssec
The following is an example of a "dnssec" <csv
The following is an example of the corresponding dnssec
5.1.2.1.7. "domainTransfer" CSV File Definition
The "domain
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2),
MUST be used in the "domain
- <rde
Csv :f Tr Status> - State of the most recent transfer request with is
Required ="true" .¶ - <rdeCsv:fReRr>
- Identifier of the registrar, defined in Section 5.4, of the client that requested the transfer with is
Required ="true" .¶ - <rdeCsv:fReDate>
- Date and time that the transfer was requested with is
Required ="true" .¶ - <rdeCsv:fAcRr>
- Identifier of the registrar, defined in Section 5.4, of the client that should take or took action with is
Required ="true" .¶ - <rdeCsv:fAcDate>
- Date and time that the transfer action should be taken or has been taken with is
Required ="true" .¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2),
MAY be used in the "domain
- <rdeCsv:fExDate>
- Expiration date if the transfer command caused or causes a change in the validity period.¶
- <rdeCsv:fReID>
- Identifier of the client that requested the transfer.¶
- <rdeCsv:fAcID>
- Identifier of the client that should take or took action for transfer.¶
The following "csvDomain" fields, defined for the '"domain" CSV File Definition' (Section 5.1.2.1.1),
MUST be used in the "domain
- <csv
Domain :f Name> - Domain name of the domain name object involved in the transfer with is
Required ="true" .¶
The following is an example of a "domain
The following is an example of the corresponding domain
5.1.2.2. <csvDomain:deletes>
The <csv
5.1.2.2.1. "domain" Deletes CSV File Definition
The following "csvDomain" field elements MUST be used in the deletes "domain" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Domain :f Name> - Domain name field with type
="eppcom :label Type" and is Required ="true" .¶
The following is an example of a "domain" <csv
The following is an example of the corresponding domain
5.2. Host Object
The host object is based on the EPP host name mapping in [RFC5732]. The
host object supports both the XML model and the CSV model, defined in 'Models' (Section 2). The
elements used for both models are defined in the following sections. Both the <csv
5.2.1. XML Model
There are
two elements used in the data escrow of the host objects for the XML model including the
<rdeHost:host> element, under the <rde
An <rdeHost:host> element substitutes for the <rde
5.2.1.1. <rdeHost:host> Element
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:¶
The following is an example of a <host> object:¶
5.2.1.2. <rdeHost:delete> Object
The <rde
The following is an example of an <rde
5.2.2. CSV Model
For the CSV model of the host object, the <csv
Differential and Incremental Deposits are based on changes to the host objects. The updated host object
data under the <csv
5.2.2.1. <csvHost:contents>
The <csv
5.2.2.1.1. "host" CSV File Definition
The "host" CSV File Definition defines the fields and CSV file references used for the host object records.¶
The following "csvHost" field elements MUST be used in the "host" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csvHost:fName>
- Host name field with type
="eppcom :label Type" and is Required ="true" .¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2), MUST be used in the "host" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fRoid>
- ROID assigned to the host object with is
Required ="true" .¶
The following "rdeCsv" and "csvRegistrar" fields MAY be used in the "host" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fClID> or <csv
Registrar :f Gurid> -
A choice of the following:¶
- <rdeCsv:fCrRr>
- Identifier of the registrar, defined in Section 5.4, of the client that created the host object.¶
- <rdeCsv:fCrID>
- Identifier of the client that created the host object.¶
- <rdeCsv:fUpRr>
- Identifier of the registrar, defined in Section 5.4, of the client that last updated the host object.¶
- <rdeCsv:fUpID>
- Identifier of the client that last updated the host object.¶
- <rdeCsv:fCrDate>
- Date and time that the host object was created.¶
- <rdeCsv:fUpDate>
- Date and time that the host object was last updated. This field MUST NOT be set if the domain name object has never been modified.¶
- <rdeCsv:fTrDate>
- Date and time that the host object was last transferred. This field MUST NOT be set if the domain name object has never been transferred.¶
The following is an example of a "host" <csv
The following is an example of the corresponding host
5.2.2.1.2. "hostStatuses" CSV File Definition
The "hostStatuses" CSV File Definition defines the fields and CSV file references used for the host object statuses.¶
The following "csvHost" fields, defined for the '"host" CSV File Definition' (Section 5.2.2.1.1), MUST be used in the "hostStatuses" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Host :f Status> - The status of the host with type
="host :status Value Type" and is Required ="true" .¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2), MUST be used in the "hostStatuses" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fRoid>
- Host object ROID assigned to the host object with is
Required ="true" .¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2), MAY be used in the "hostStatuses" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rde
Csv :f Status Description> - Host object status description, which is free-form text describing the rationale for the status.¶
- <rdeCsv:fLang>
- Language of the <rde
Csv :f Status Description> field.¶
The following is an example of a "hostStatuses" <csv
The following is an example of the corresponding host
5.2.2.1.3. "hostAddresses" CSV File Definition
The "hostAddresses" CSV File Definition defines the fields and CSV file references used for the host object IP addresses.¶
The following "csvHost" field elements MUST be used in the "hostAddresses" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csvHost:fAddr>
- IP addresses associated with the host object with type
="host :addr String Type" . The attribute "isRequired" MUST equal "true".¶ - <csv
Host :f Addr Version> - IP addresses version associated with the host object with type
="host :ip Type" . "host:ipType" has the enumerated values of "v4" or "v6". The attribute "isRequired" MUST equal "true".¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2), MUST be used in the "hostAddresses" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fRoid>
- Host object ROID assigned to the host object with is
Required ="true" .¶
The following is an example of a "hostAddresses" <csv
The following is an example of the corresponding host
5.2.2.2. <csvHost:deletes>
The <csv
5.2.2.2.1. "host" Deletes CSV File Definition
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2), MUST be used in the "host" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fRoid>
- ROID assigned to the host object with is
Required ="true" .¶
The following is an example of a "host" <csv
The following is an example of the host
5.3. Contact Object
The contact object is based on the EPP contact name mapping in [RFC5733]. The contact object supports both the XML model and the CSV model, defined in 'Models' (Section 2). The elements used for both models are defined in the following sections.¶
5.3.1. XML Model
There are
two elements used in the data escrow of the contact objects for the XML model including the
<rde
A <contact> element substitutes for the <abstract
5.3.1.1. <rdeContact: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:¶
The following is an example of a <contact> object:¶
5.3.1.2. <rdeContact:delete> Object
The <rde
The following is an example of an <rde
5.3.2. CSV Model
For the CSV model of the contact object, the <csv
Differential and Incremental Deposits are based on changes to the contact objects. The updated contact object
data under the <csv
5.3.2.1. <csvContact:contents>
The <csv
5.3.2.1.1. "contact" CSV File Definition
The "contact" CSV File Definition defines the fields and CSV file references used for the contact object records.¶
The following "csvContact" field elements MUST be used in the "contact" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csvContact:fId>
- Contains the server-unique contact identifier with type
="eppcom :cl IDType" and is Required ="true" .¶ - <csv
Contact :f Email> - Contains the contact's email address with type
="eppcom :min Token Type" and is Required ="true" .¶
The following field elements MAY be used in the "contact" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Contact :f Voice> - Contains the contact's voice telephone number with type
="contact :e164String Type" .¶ - <csv
Contact :f Voice Ext> - Contains the contact's voice telephone number extension with type="token".¶
- <csv
Contact :f Fax> - Contains the contact's facsimile telephone number with type
="contact :e164String Type" .¶ - <csv
Contact :f Fax Ext> - Contains the contact's facsimile telephone number extension with type="token".¶
The following "rdeCsv" and "csvRegistrar" fields MUST be used in the "contact" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fRoid>
- The ROID for the contact object with is
Required ="true" .¶ - <rdeCsv:fClID> or <csv
Registrar :f Gurid> -
A choice of the following:¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2), MAY be used in the "contact" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fCrRr>
- Identifier of the registrar, defined in Section 5.4, of the client that created the contact object.¶
- <rdeCsv:fCrID>
- Identifier of the client that created the contact object.¶
- <rdeCsv:fUpRr>
- Identifier of the registrar, defined in Section 5.4, of the client that last updated the contact object.¶
- <rdeCsv:fUpID>
- Identifier of the client that last updated the contact object.¶
- <rdeCsv:fCrDate>
- Date and time of the contact object creation.¶
- <rdeCsv:fUpDate>
- Date and time of the last update to the contact object. This field MUST NOT be set if the domain name object has never been modified.¶
- <rdeCsv:fTrDate>
- Date and time of the last transfer for the contact object. This field MUST NOT be set if the domain name object has never been transferred.¶
The following is an example of a "contact" <csv
The following is an example of the contact
5.3.2.1.2. "contactStatuses" CSV File Definition
The "contact
The following "csvContact" field elements, defined in the '"contact" CSV File Definition' (Section 5.3.2.1.1),
MUST be used in the "contact
- <csvContact:fId>
- Server-unique contact identifier of status with is
Required ="true" and parent="true".¶ - <csv
Contact :f Status> - The status of the contact with type
="contact :status Value Type" and is Required ="true" .¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2),
MAY be used in the "contact
- <rde
Csv :f Status Description> - The contact object status description, which is free-form text describing the rationale for the status.¶
- <rdeCsv:fLang>
- Language of the <rde
Csv :f Status Description> field.¶
The following is an example of a "contact
The following is an example of the corresponding contact
5.3.2.1.3. "contactPostal" CSV File Definition
The "contactPostal" CSV File Definition defines the fields and CSV file references used for the contact postal info object records.¶
The following "csvContact" field elements MUST be used in the "contactPostal" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Contact :f Postal Type> - Contains the form of the postal address information with type
="contact :postal Line Type" and is Required ="true" . This field specifies the form ("int" or "loc"), as defined in Section 4.6.3, of the <csv Contact :f Name>, <csv Contact :f Org>, <csv Contact :f Street>, <csv Contact :f City>, <csv Contact :f Sp>, <csv Contact :f Pc>, and <csv Contact :f Cc> fields.¶ - <csv
Contact :f Name> - Contains the contact's name of the individual or role represented by the contact with type
="contact :postal Line Type" and is Required ="true" . An OPTIONAL "isLoc" attribute is used to indicate the localized or internationaliz ed form as defined in Section 4.6.3.¶ - <csv
Contact :f Street> - Contains the contact's street address line with type
="contact :f Postal Line Type" . An "index" attribute is required to indicate which street address line the field represents with index="0" for the first line and incrementing for each line up to index="2" for the third line. An OPTIONAL "isLoc" attribute is used to indicate the localized or internationaliz ed form as defined in Section 4.6.3.¶ - <csv
Contact :f City> - Contains the contact's city with type
="contact :postal Line Type" and is Required ="true" . An OPTIONAL "isLoc" attribute is used to indicate the localized or internationaliz ed form as defined in Section 4.6.3.¶ - <csvContact:fCc>
- Contains the contact's country code with type
="contact :cc Type" and is Required ="true" . An OPTIONAL "isLoc" attribute is used to indicate the localized or internationaliz ed form as defined in Section 4.6.3.¶
The following "csvContact" field elements MAY be used in the "contactPostal" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Contact :f Org> - Contains the name of the organization with which the contact is affiliated with type
="contact :opt Postal Line Type" . An OPTIONAL "isLoc" attribute is used to indicate the localized or internationaliz ed form as defined in Section 4.6.3.¶ - <csvContact:fSp>
- Contains the contact's state or province with type
="contact :opt Postal Line Type" . An OPTIONAL "isLoc" attribute is used to indicate the localized or internationaliz ed form as defined in Section 4.6.3.¶ - <csvContact:fPc>
- Contains the contact's postal code with type
="contact :pc Type" . An OPTIONAL "isLoc" attribute is used to indicate the localized or internationaliz ed form as defined in Section 4.6.3.¶
The following "csvContact" fields, defined in the '"contact" CSV File Definition' (Section 5.3.2.1.1), MUST be used in the "contactPostal" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csvContact:fId>
- Server-unique contact identifier for the contact object with is
Required ="true" and parent="true".¶
The following is an example of a "contactPostal" <csv
The following is an example of the contact
5.3.2.1.4. "contactTransfer" CSV File Definition
The "contact
- <rde
Csv :f Tr Status> - State of the most recent transfer request with is
Required ="true" .¶ - <rdeCsv:fReRr>
- Identifier of the registrar, defined in Section 5.4, of the client that requested the transfer with is
Required ="true" .¶ - <rdeCsv:fReDate>
- Date and time that the transfer was requested with is
Required ="true" .¶ - <rdeCsv:fAcRr>
- Identifier of the registrar, defined in Section 5.4, of the client that should take or took action with is
Required ="true" .¶ - <rdeCsv:fAcDate>
- Date and time that the transfer action should be taken or has been taken with is
Required ="true" .¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2),
MAY be used in the "contact
- <rdeCsv:fReID>
- Identifier of the client that requested the transfer.¶
- <rdeCsv:fAcID>
- Identifier of the client that should take or took action for transfer.¶
The following "csvContact" fields, defined for the '"contact" CSV File Definition' (Section 5.3.2.1.1),
MUST be used in the "contact
- <csvContact:fId>
- Server-unique contact identifier for the contact object with is
Required ="true" .¶
The following is an example of a "contact
The following is an example of the contact
5.3.2.1.5. "contactDisclose" CSV File Definition
The "contact
The following "csvContact" field elements MAY be used in the "contact
- <csv
Contact :f Disclose Flag> - Contains flag with a value of "true" or "1" (one) notes the preference
to allow disclosure of the specified elements as an exception to the stated data-collection policy.
A value of "false" or "0" (zero) notes a client preference to not allow disclosure of the specified elements as an exception
to the stated data-collection policy with type="boolean". The additional fields define specific exceptional disclosure
preferences based on the <csv
Contact :f Disclose Flag> field.¶ - <csv
Contact :f Disclose Name Loc> - Exceptional disclosure preference flag for the localized form of the contact name with type="boolean".¶
- <csv
Contact :f Disclose Name Int> - Exceptional disclosure preference flag for the internationaliz
ed form of the contact name with type="boolean".¶ - <csv
Contact :f Disclose Org Loc> - Exceptional disclosure preference flag for the localized form of the contact organization with type="boolean".¶
- <csv
Contact :f Disclose Org Int> - Exceptional disclosure preference flag for the internationaliz
ed form of the contact organization with type="boolean".¶ - <csv
Contact :f Disclose Addr Loc> - Exceptional disclosure preference flag for the localized form of the contact address with type="boolean".¶
- <csv
Contact :f Disclose Addr Int> - Exceptional disclosure preference flag for the internationaliz
ed form of the contact address with type="boolean".¶ - <csv
Contact :f Disclose Voice> - Exceptional disclosure preference flag of the contact voice telephone number with type="boolean".¶
- <csv
Contact :f Disclose Fax> - Exceptional disclosure preference flag of the contact facsimile telephone number with type="boolean".¶
- <csv
Contact :f Disclose Email> - Exceptional disclosure preference flag of the contact email address with type="boolean".¶
The following "csvContact" fields, defined for the '"contact" CSV File Definition' (Section 5.3.2.1.1),
MUST be used in the "contact
- <csvContact:fId>
- Server-unique contact identifier for the contact object with is
Required ="true" .¶
The following is an example of a "contact
The following is an example of the contact
5.3.2.2. <csvContact:deletes>
The <csv
5.3.2.2.1. "contact" Deletes CSV File Definition
The following "csvContact" field elements MUST be used in the deletes "contact" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csvContact:fId>
- Contains the server-unique contact identifier with type
="eppcom :cl IDType" and is Required ="true" .¶
The following is an example of a "contact" <csv
The following is an example of the contact
5.4. Registrar Object
The registrar object represents the sponsoring client for other objects and is typically referred to as the sponsoring registrar. The registrar object supports both the XML model and the CSV model, defined in Section 2. The elements used for both models are defined in the following sections.¶
5.4.1. XML Model
There are
two elements used in the data escrow of the registrar objects for the XML model including the
<rde
An <rde
5.4.1.1. <rdeRegistrar:registrar> Element
The <registrar> element contains the following child elements:¶
The following is an example of a <registrar> object:¶
5.4.1.2. <rdeRegistrar:delete> Object
The <rde
The following is an example of <rde
5.4.2. CSV Model
For the CSV model of the registrar object, the <csv
Differential and Incremental Deposits are based on changes to the registrar objects. The updated registrar object
data under the <csv
5.4.2.1. <csvRegistrar:contents>
The <csv
5.4.2.1.1. "registrar" CSV File Definition
The "registrar" CSV File Definition defines the fields and CSV file references used for the registrar object records.¶
The following "csvRegistrar" field elements MUST be used in the "registrar" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Registrar :f Id> or <csv Registrar :f Gurid> -
A choice of the following:¶
- <csv
Registrar :f Name> - Contains the name of the registrar with type
="normalized String" and is Required ="true" .¶
The following field elements MAY be used in the "registrar" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Registrar :f Status> - Contains the status of the registrar with type
="csv Registrar :status Value Type" .¶ - <csv
Registrar :f Gurid> - Contains the ID assigned by ICANN with type
="positive Integer" . This field is included in this section in addition to the section above to support optionally providing the <csv Registrar :f Gurid> field when the <csv Registrar :f Id> field is used.¶ - <csv
Registrar :f Whois Url> - Contains the Whois URL of the registrar with type="anyURI".¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2), MAY be used in the "registrar" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fCrDate>
- Date and time of the registrar object creation.¶
- <rdeCsv:fUpDate>
- Date and time of the last update to the registrar object. This field MUST NOT be set if the domain name object has never been modified.¶
- <rdeCsv:fUrl>
- URL for the registrar web home page.¶
The following "csvContact" fields, defined in 'Contact Object' (Section 5.3), MAY be used in the "registrar" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Contact :f Street> - Registrar street address line with an "index" attribute that represents the order of the street address line from "0" to "2".
An OPTIONAL "isLoc" attribute that is used to indicate the localized or internationaliz
ed form, as defined in Section 4.6.3.¶ - <csv
Contact :f City> - Registrar city with an OPTIONAL "isLoc" attribute that is used to
indicate the localized or internationaliz
ed form, as defined in Section 4.6.3.¶ - <csvContact:fCc>
- Registrar country code with an OPTIONAL "isLoc" attribute that is used to
indicate the localized or internationaliz
ed form, as defined in Section 4.6.3.¶ - <csv
Contact :f Email> - Registrar email address. The attribute "isRequired" MUST equal "false".¶
- <csvContact:fSp>
- Registrar state or province with an OPTIONAL "isLoc" attribute that is used to
indicate the localized or internationaliz
ed form, as defined in Section 4.6.3.¶ - <csvContact:fPc>
- Registrar postal code with an OPTIONAL "isLoc" attribute that is used to
indicate the localized or internationaliz
ed form, as defined in Section 4.6.3.¶ - <csv
Contact :f Voice> - Registrar voice telephone number.¶
- <csv
Contact :f Voice Ext> - Registrar voice telephone number extension.¶
- <csv
Contact :f Fax> - Registrar facsimile telephone number.¶
- <csv
Contact :f Fax Ext> - Registrar facsimile telephone number extension.¶
The following is an example of a "registrar" <csv
The following is an example of the registrar
5.4.2.2. <csvRegistrar:deletes>
The <csv
5.4.2.2.1. "registrar" Deletes CSV File Definition
The following "csvRegistrar" field elements MUST be used in the deletes "registrar" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
Registrar :f Id> or <csv Registrar :f Gurid> -
A choice of the following:¶
The following is an example of a "registrar" <csv
The following is an example of the registrar
5.5. IDN Table Reference Object
The Internationaliz
5.5.1. XML Model
There is
one element used in the data escrow of the IDN table reference objects for the XML model, and that is the
<rde
5.5.1.1. <rdeIDN:idnTableRef> Object
The <rde
The following is an example of <idnTableRef> object:¶
5.5.2. CSV Model
The IDN domain names, defined in Section 5.1, MAY have references
to the IDN language identifier using the <rde
5.5.2.1. <csvIDN:contents>
The <csv
5.5.2.1.1. "idnLanguage" CSV File Definition
The "idnLanguage" CSV File Definition defines the fields and CSV file references used for the IDN table reference object records.¶
The following "rdeCsv" fields, defined in Section 4.6.2.2, MUST be used in the "idnLanguage" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rde
Csv :f Idn Table Id> - The language identifier that matches the values for the <rde
Csv :f Idn Table Id> field element in the '"domain" CSV File Definition' (Section 5.1.2.1.1) files. The attribute "isRequired" MUST equal "true".¶ - <rdeCsv:fUrl>
- URL that defines the character code points that can be
used for <csv
Domain :f Name> field in the '"domain" CSV File Definition' (Section 5.1.2.1.1) files. The attribute "isRequired" MUST equal "true".¶
The following is an example of a "idnLanguage" <csv
The following is an example of the corresponding idn
5.5.2.2. <csvIDN:deletes>
The <csv
5.5.2.2.1. "idnLanguage" Deletes CSV File Definition
The following "idnLanguage" field elements MUST be used in the deletes "idnLanguage" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rde
Csv :f Idn Table Id> - The language identifier that matches the values for the <rde
Csv :f Idn Table Id> field element in the '"domain" CSV File Definition' (Section 5.1.2.1.1) files. The attribute "isRequired" MUST equal "true".¶
The following is an example of a "idnLanguage" <csv
The following is an example of the idn
5.6. NNDN Object
An NNDN (NNDN's not domain name) can be used to store registry reserved names or (blocked, withheld, or mirrored) IDN variants.¶
Domain name registries may maintain domain names without their being persisted as domain objects in the registry system, for example, a list of reserved names not available for registration. The NNDN is a lightweight domain-like object that is used to escrow domain names not maintained as domain name objects.¶
A domain name can only exist as a domain name object or an NNDN object, but not both.¶
The NNDN object supports both the XML and the CSV model, defined in 'Models' (Section 2). The elements used for both models are defined in the following sections.¶
5.6.1. XML Model
There are
two elements used in the data escrow of the NNDN objects for the XML model including the
<rdeNNDN:NNDN> element, under the <rde:contents> element, and the <rde
An <rdeNNDN:NNDN> element substitutes for the <rde
5.6.1.1. <rdeNNDN:NNDN> Object
The <rdeNNDN:NNDN> element contains the following child elements:¶
The following is an example of an <rdeNNDN:NNDN> object:¶
5.6.1.2. <rdeNNDN:delete> Object
The <rde
The following is an example of an <rde
5.6.2. CSV Model
For the CSV model of the NNDN object, the <csv
5.6.2.1. <csvNNDN:contents>
The <csv
5.6.2.1.1. "NNDN" CSV File Definition
The "NNDN" CSV File Definition defines the fields and CSV file references used for the NNDN object records.¶
The following "csvNNDN" field elements MUST be used in the "NNDN" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csvNNDN:fAName>
- Fully qualified name of the NNDN with type
="eppcom :label Type" and is Required ="true" . For IDNs, the A-label is used (see [RFC5891], Section 4.4).¶ - <csv
NNDN :f Name State> - State of the NNDN: blocked or withheld with type
="rde NNDN :name State" and is Required ="true" . See Section 5.6.1.1 for a description of the possible values for the <rde NNDN :name State> element.¶
The following field elements MAY be used in the "NNDN" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csv
NNDN :f Original Name> - Domain name used to generate the IDN variant with type
="eppcom :label Type" .¶ - <csv
NNDN :f Mirroring NS> - Defines whether the "mirroring" <csv
NNDN :f Name State> uses the NS mirror mechanism, as described for the <rde NNDN :name State> "mirroringNS" attribute in Section 5.6.1.1, with type="boolean". If the field element is not defined the default value is "true".¶
The following "rdeCsv" fields, defined in 'CSV Common Field Elements' (Section 4.6.2.2), MAY be used in the "NNDN" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <rdeCsv:fCrDate>
- Date and time of the NNDN object creation.¶
- <rdeCsv:fUName>
- Name of the NNDN in the Unicode character set for the <csv
NNDN :f AName> field element.¶ - <rde
Csv :f Idn Table Id> - IDN table identifier for the NNDN that matches an IDN table reference object record, as defined in Section 5.5.2.¶
The following is an example of an "NNDN" <csv
The following is an example of the corresponding NNDN
5.6.2.2. <csvNNDN:deletes>
The <csv
5.6.2.2.1. "NNDN" Deletes CSV File Definition
The following "NNDN" field elements MUST be used in the deletes "NNDN" <rdeCsv:csv> <rdeCsv:fields> element:¶
- <csvNNDN:fAName>
- Fully qualified name of the NNDN with type
="eppcom :label Type" and is Required ="true" .¶
The following is an example of an "NNDN" <csv
The following is an example of the corresponding NNDN
5.7. EPP Parameters Object
The EPP parameters object is a pseudo-object that defines the set of object and object extension services
supported by the registry, as defined in [RFC5730]. The
EPP parameters object is only defined as XML but could be used in either the XML model or CSV model.
The EPP parameters object is defined using the
<rde
The syntax and content of the <rde
The following is an example of <eppParams> element object:¶
5.8. Policy Object
The policy object is a pseudo-object that is used to specify which OPTIONAL elements from the XML model are REQUIRED based on the business model of the registry. For the CSV model, the OPTIONAL "isRequired" attribute of the <rdeCsv:field> elements, defined in Section 4.6.2.1, is used to specify which OPTIONAL fields are REQUIRED based on the business model of the registry.¶
5.8.1. <rdePolicy:policy> Object
The OPTIONAL <policy> contains the following attributes:¶
The following is an example of <rde
5.9. Header Object
The header object is a pseudo-object that is used to specify the number
of objects in the repository at a specific point in time (Timeline Watermark) regardless
of the type of deposit: Differential, Full, or Incremental Deposit.
The header object may also be used to provide additional information on the contents of the deposit.
The header object
is only defined as XML but one header object MUST always be present
per escrow deposit regardless of using the XML model or CSV model.
The header object is defined using the <rde
5.10. DNRD Common Objects Collection
The DNRD common objects collection contains data structures referenced by two or more of the main objects in the XML model.¶
6. RDE IDN Variants Handling
Depending on the registration policy of the registry, for a domain name there may be
multiple variant names. See [variant
A registry could choose to escrow IDN variants as domains or NNDN objects. A specific IDN variant can be represented in the escrow deposit, as a domain or as an NNDN object, but not both.¶
If using domain objects to represent IDN variants, the normal behavior during restoration of an SRS based on an escrow deposit is to restore the IDN variants as a mirrored variant. If the registration data of the IDN variant is different from the original name, the details of this specific implementation MUST be described in the IDN policy document.¶
An NNDN or a domain name are explicit representations of an IDN variant while an IDN variant that is 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 for defining a profile that matches its particular business model. The profile mechanism allows a registry to extend this specification.¶
A profile is the process of the following:¶
8. Data Escrow Agent Extended Verification Process
A data escrow agent SHOULD perform an extended verification process that starts by creating a dataset to be tested by following Section 5.2 of [RFC8909].¶
The following are the minimum suggested tests on the dataset:¶
9. Formal Syntax
This standard is specified in XML Schema notation. The formal syntax presented here is a complete schema representation suitable for automated validation.¶
The <CODE BEGINS> and <CODE ENDS> tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.¶
10. 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, the use of UTF-8 is RECOMMENDED.¶
11. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. The following URIs have been assigned by IANA.¶
RDE CSV namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde Csv -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE CSV XML schema:¶
See Section 9.1 of this document.¶
RDE domain namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde Domain -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE domain XML schema:¶
See Section 9.2 of this document.¶
CSV domain namespace:¶
- URI:
- urn
:ietf :params :xml :ns :csv Domain -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
CSV domain XML schema:¶
See Section 9.3 of this document.¶
RDE host namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde Host -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE host XML schema:¶
See Section 9.4 of this document.¶
CSV host namespace:¶
- URI:
- urn
:ietf :params :xml :ns :csv Host -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
CSV host XML schema:¶
See Section 9.5 of this document.¶
RDE contact namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde Contact -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE contact XML schema:¶
See Section 9.6 of this document.¶
CSV contact namespace:¶
- URI:
- urn
:ietf :params :xml :ns :csv Contact -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
CSV contact XML schema:¶
See Section 9.7 of this document.¶
RDE registrar namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde Registrar -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE registrar XML schema:¶
See Section 9.8 of this document.¶
CSV registrar namespace:¶
- URI:
- urn
:ietf :params :xml :ns :csv Registrar -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
CSV registrar XML schema:¶
See Section 9.9 of this document.¶
RDE IDN namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde IDN -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE IDN XML schema:¶
See Section 9.10 of this document.¶
CSV IDN namespace:¶
- URI:
- urn
:ietf :params :xml :ns :csv IDN -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
CSV IDN XML schema:¶
See Section 9.11 of this document.¶
RDE EPP parameters namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde Epp Params -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE EPP parameters XML schema:¶
See Section 9.12 of this document.¶
RDE NNDN namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde NNDN -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE NNDN XML schema:¶
See Section 9.13 of this document.¶
CSV NNDN namespace:¶
- URI:
- urn
:ietf :params :xml :ns :csv NNDN -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
CSV NNDN XML schema:¶
See Section 9.14 of this document.¶
RDE Policy namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde Policy -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE Policy XML schema:¶
See Section 9.15 of this document.¶
RDE Header namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde Header -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE Header XML schema:¶
See Section 9.16 of this document.¶
RDE Common Objects namespace:¶
- URI:
- urn
:ietf :params :xml :ns :rde Dnrd Common -1 .0¶ - Registrant Contact:
- IESG¶
- XML:
- None. Namespace URIs do not represent an XML specification.¶
RDE Common Objects XML schema:¶
See Section 9.17 of this document.¶
12. 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 parties SHOULD take all the necessary precautions such as encrypting the data at rest and in transit to avoid inadvertent disclosure of private data. Regardless of the precautions taken by the parties regarding data at rest and in transit, authentication credentials MUST NOT be escrowed.¶
Authentication of the parties passing data escrow deposit files is also of the utmost importance. The escrow agent MUST properly authenticate the registry's identity before accepting data escrow deposits. The registry MUST authenticate the escrow agent's identity before submitting any data, and the data escrow agent MUST authenticate the identity of the party receiving the data escrow deposits for the purposes deemed appropriate.¶
Additionally, the registry and the escrow agent MUST use integrity checking mechanisms to ensure the data transmitted is what the source intended. Validation of the contents by the parties is RECOMMENDED to ensure that the file was transmitted correctly from the registry or escrow agent and that the contents are "meaningful".¶
A few elements in this specification contain URLs; the use of HTTP over TLS (Transport Layer Security) [RFC2818] is RECOMMENDED on the URLs.¶
The various data structures in the document include a few places that have internal redundancy, and if the values become inconsistent there can be harmful consequences, such as different entities using different fields as their reference.¶
13. Privacy Considerations
This specification defines a format that may be used to escrow personal data. The process of data escrow is governed by a legal document that is agreed to by the parties, and such a legal document must ensure that privacy
14. Example of a Full Deposit Using the XML Model
The following is an example of a Full Deposit using the XML model:¶
15. Example of a Differential Deposit Using the XML Model
The following is an example of a Differential Deposit using the XML model:¶
16. Example of a Full Deposit Using the CSV Model
The following is an example of a Full Deposit using the CSV model:¶
17. Example of a Differential Deposit Using the CSV Model
The following is an example of a Differential Deposit using the CSV model:¶
18. References
18.1. Normative References
- [BCP195]
-
Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, .<https://
www >.rfc -editor .org /info /bcp195 - [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, .
- [ITU-E164]
-
International Telecommunicati
on Union , "The international public telecommunication numbering plan" , ITU-T Recommendation E.164, . - [RFC0791]
-
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10
.17487 , , <https:///RFC0791 www >..rfc -editor .org /info /rfc791 - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC3339]
-
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10
.17487 , , <https:///RFC3339 www >..rfc -editor .org /info /rfc3339 - [RFC3915]
-
Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, DOI 10
.17487 , , <https:///RFC3915 www >..rfc -editor .org /info /rfc3915 - [RFC5730]
-
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10
.17487 , , <https:///RFC5730 www >..rfc -editor .org /info /rfc5730 - [RFC5731]
-
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10
.17487 , , <https:///RFC5731 www >..rfc -editor .org /info /rfc5731 - [RFC5732]
-
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10
.17487 , , <https:///RFC5732 www >..rfc -editor .org /info /rfc5732 - [RFC5733]
-
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10
.17487 , , <https:///RFC5733 www >..rfc -editor .org /info /rfc5733 - [RFC5891]
-
Klensin, J., "Internationaliz
ed Domain Names in Applications (IDNA): Protocol" , RFC 5891, DOI 10.17487 , , <https:///RFC5891 www >..rfc -editor .org /info /rfc5891 - [RFC5910]
-
Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, DOI 10
.17487 , , <https:///RFC5910 www >..rfc -editor .org /info /rfc5910 - [RFC5952]
-
Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10
.17487 , , <https:///RFC5952 www >..rfc -editor .org /info /rfc5952 - [RFC6234]
-
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10
.17487 , , <https:///RFC6234 www >..rfc -editor .org /info /rfc6234 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8499]
-
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10
.17487 , , <https:///RFC8499 www >..rfc -editor .org /info /rfc8499 - [RFC8909]
-
Lozano, G., "Registry Data Escrow Specification", RFC 8909, DOI 10
.17487 , , <https:///RFC8909 www >..rfc -editor .org /info /rfc8909 - [V42]
-
International Telecommunicati
on Union , "V.42 : Error-correcting procedures for DCEs using asynchronous , ITU-T Recommendation V.42, , <https://-to -synchronous conversion" www >..itu .int /rec /T -REC -V .42 /en - [W3C
.REC -xml -20081126] -
Bray, T., Paoli, J., Sperberg
-Mc , Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition) RECQueen, C. M. -xml , W3C Recommendation, , <https://-20081126" www >..w3 .org /TR /2008 /REC -xml -20081126 / - [W3C
.REC -xmlschema -1 -20041028] -
Thompson, H. S., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition REC
-xmlschema , W3C Recommendation, , <https://-1 -20041028" www >..w3 .org /TR /2004 /REC -xmlschema -1 -20041028 / - [W3C
.REC -xmlschema -2 -20041028] -
Biron, P. V. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition REC
-xmlschema , W3C Recommendation, , <https://-2 -20041028" www >..w3 .org /TR /2004 /REC -xmlschema -2 -20041028 / - [W3C
.REC -xpath -31 -20170321] -
Robie, J., Dyck, M., and J. Spiegel, "XML Path Language (XPath) 3.1", W3C Recommendation, , <https://
www >..w3 .org /TR /2017 /REC -xpath -31 -20170321 /
18.2. Informative References
- [ICANN
-GTLD -AGB -20120604] -
ICANN, "gTLD Applicant Guidebook Version 2012-06-04", , <http://
newgtlds >..icann .org /en /applicants /agb /guidebook -full -04jun12 -en .pdf - [ICANN
-GTLD -RA -20170731] -
ICANN, "Base Registry Agreement 2017-07-31", , <https://
newgtlds >..icann .org /sites /default /files /agreements /agreement -approved -31jul17 -en .pdf - [RFC1952]
-
Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10
.17487 , , <https:///RFC1952 www >..rfc -editor .org /info /rfc1952 - [RFC2818]
-
Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10
.17487 , , <https:///RFC2818 www >..rfc -editor .org /info /rfc2818 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC3912]
-
Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10
.17487 , , <https:///RFC3912 www >..rfc -editor .org /info /rfc3912 - [RFC4180]
-
Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) Files", RFC 4180, DOI 10
.17487 , , <https:///RFC4180 www >..rfc -editor .org /info /rfc4180 - [RFC6672]
-
Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10
.17487 , , <https:///RFC6672 www >..rfc -editor .org /info /rfc6672 - [variant
TLDs Report] -
ICANN, "A Study of Issues Related to the Management of IDN Variant TLDs", , <https://
www >..icann .org /en /system /files /files /idn -vip -integrated -issues -final -clean -20feb12 -en .pdf
Acknowledgments
Parts of this document are based on EPP [RFC5730] and related RFCs by Scott Hollenbeck.¶
Special suggestions that have been incorporated into this document were provided by Edward Lewis, Jaap Akkerhuis, Lawrence Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek, Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari, Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew Sullivan, Hiro Hotta, Christopher Browne, Daniel Kalchev, David Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi, Alexander Mayrhofer, and Benjamin Kaduk.¶
Shoji Noguchi and Francisco Arias participated as coauthors through version 05 of earlier drafts of this document and provided invaluable support.¶