From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9022.txt | 7748 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 7748 insertions(+) create mode 100644 doc/rfc/rfc9022.txt (limited to 'doc/rfc/rfc9022.txt') diff --git a/doc/rfc/rfc9022.txt b/doc/rfc/rfc9022.txt new file mode 100644 index 0000000..127de19 --- /dev/null +++ b/doc/rfc/rfc9022.txt @@ -0,0 +1,7748 @@ + + + + +Internet Engineering Task Force (IETF) G. Lozano +Request for Comments: 9022 ICANN +Category: Standards Track J. Gould +ISSN: 2070-1721 C. Thippeswamy + VeriSign + May 2021 + + + Domain Name Registration Data (DNRD) Objects Mapping + +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://www.rfc-editor.org/info/rfc9022. + +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://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Models + 2.1. XML Model + 2.2. CSV Model + 3. Terminology + 3.1. Glossary + 4. Conventions Used in This Document + 4.1. Date and Time + 4.2. Country Names + 4.3. Telephone Numbers + 4.4. CSV Integrity Check + 4.5. IP Addresses + 4.6. Conventions Applicable to the CSV Model + 5. Object Description + 5.1. Domain Name Object + 5.2. Host Object + 5.3. Contact Object + 5.4. Registrar Object + 5.5. IDN Table Reference Object + 5.6. NNDN Object + 5.7. EPP Parameters Object + 5.8. Policy Object + 5.9. Header Object + 5.10. DNRD Common Objects Collection + 6. RDE IDN Variants Handling + 7. Profile + 8. Data Escrow Agent Extended Verification Process + 9. Formal Syntax + 9.1. RDE CSV Schema + 9.2. RDE Domain Object + 9.3. CSV Domain Object + 9.4. RDE Host Object + 9.5. CSV Host Object + 9.6. RDE Contact Object + 9.7. CSV Contact Object + 9.8. RDE Registrar Object + 9.9. CSV Registrar Object + 9.10. RDE IDN Table Reference Objects + 9.11. CSV IDN Language Object + 9.12. EPP Parameters Object + 9.13. NNDN Object + 9.14. CSV NNDN Object + 9.15. Policy Object + 9.16. Header Object + 9.17. DNRD Common Objects + 10. Internationalization Considerations + 11. IANA Considerations + 12. Security Considerations + 13. Privacy Considerations + 14. Example of a Full Deposit Using the XML Model + 15. Example of a Differential Deposit Using the XML Model + 16. Example of a Full Deposit Using the CSV Model + 17. Example of a Differential Deposit Using the CSV Model + 18. References + 18.1. Normative References + 18.2. Informative References + Acknowledgments + Authors' Addresses + +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-GTLD-RA-20170731]) and + some country code top-level domain managers are also currently + escrowing data. There is also a similar requirement for ICANN- + accredited domain registrars. + + 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: Internationalized 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.REC-xml-20081126] and XML Schema notation as described in + [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are + used in this specification. + +2. Models + + This document defines two different models that can be used to + deposit data escrow objects: XML and CSV (comma-separated values). + + 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 + (urn:ietf:params:xml:ns:rdeDomain-1.0). + +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 + (urn:ietf:params:xml:ns:csvDomain-1.0). + +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 administratively 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]. + + Internationalized Domain Name (IDN): See the definition of + Internationalized 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 (see Section 4.6.2.1), for a Sample object + consisting of a parent "sample" CSV File Definition and a child + "sampleStatuses" CSV File Definition. The primary key for the Sample + object is the field that is used as the foreign key + in the "sampleStatuses" CSV File Definition by specifying the + "parent=true" attribute. If a Sample record is updated or deleted in + a Differential or Incremental Deposit, it should cascade replace the + data using the records included in the child "sampleStatuses" CSV + File Definition or cascade delete the existing records in the child + "sampleStatuses" CSV File Definition, respectively. + + + ... + + + + + + + + + + + + + + + sample-YYYYMMDD.csv + + + + + + + + + + + + + sampleStatuses-YYYYMMDD.csv + + + + ... + + +4.6.2. CSV Elements + +4.6.2.1. Element + + To support the CSV model, an element is defined for each object that + substitutes for the element and for the + element, that contains one or more elements. For + example, the 'Domain Name Object' (Section 5.1) defines the + element, that substitutes for the + element, and the element, that substitutes for + the element. Both the element and + the elements contain one or more + elements. The element has the following child elements: + + Ordered list of CSV fields used in the CSV files. + There are one or more child elements that substitute for the + abstract element. Each element defines the format + of the CSV field contained in the CSV files. The + elements support the "type" attribute that defines the XML simple + data type of the field element. The 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 element. The + 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 + field SHOULD set the "parent" attribute to + "true" to identify it as the parent domain name of the domain + status. + + A list of one or more CSV files using the + child element. The 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 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 + element for domain name records where the is set + as required with isRequired="true". + + + ... + + + + + + + + + + + + + + + + + + + domain-YYYYMMDD.csv + + + + ... + + + The following is an example of the domain-YYYYMMDD.csv file with one + record matching the definition. + + domain1.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX, + clientY,2009-04-03T22:00:00.0Z,registrarX,clientY, + 2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z + + The following is an example of the + element for domain name records. + + + ... + + + + + + + domain-delete-YYYYMMDD.csv + + + + ... + + + The following is example of the domain-delete-YYYYMMDD.csv file with + three records that matches the single field. + + domain1.example + domain2.example + domainN.example + +4.6.2.2. CSV Common Field Elements + + The element defined in the ' Element' + (Section 4.6.2.1) has child elements that substitute for the abstract + element. By convention, 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:ietf:params:xml:ns:rdeCsv-1.0" namespace and using the + "rdeCsv" sample namespace prefix. The CSV common field elements + include: + + UTF-8 encoded name field with + type="eppcom:labelType". + + Repository Object IDentifier (ROID) field with + type="eppcom:roidType" and isRequired="true". + + Registrant contact identifier with + type="eppcom:clIDType". + + The object status description, which is + free-form text describing the rationale for the status, with + type="normalizedString". + + Identifier of the client (registrar) that sponsors + the object with type="eppcom:clIDType" and isRequired="true". + + Identifier of the registrar, defined in Section 5.4, + of the client that created the object with type="eppcom:clIDType". + + Identifier of the client that created the object with + type="eppcom:clIDType". + + Identifier of the registrar, defined in Section 5.4, + of the client that last updated the object with + type="eppcom:clIDType". + + Identifier of the client that last updated the object + with type="eppcom:clIDType". + + Identifier of the registrar, defined in Section 5.4, + of the client that requested the transfer with + type="eppcom:clIDType" and isRequired="true". + + Identifier of the client that requested the transfer + with type="eppcom:clIDType". + + Identifier of the registrar, defined in Section 5.4, + of the client that should take or took action with + type="eppcom:clIDType" and isRequired="true". + + Identifier of the client that should take or took + action for transfer with type="eppcom:clIDType". + + Created date of object with type="dateTime". + + Updated date of object with type="dateTime". + + Expiration date of object with type="dateTime". + + Date that transfer was requested with + type="dateTime" and isRequired="true". + + Date that transfer action should be taken or has + been taken with type="dateTime" and isRequired="true". + + Date of last transfer with type="dateTime". + + State of the most recent transfer request with + type="eppcom:trStatusType" and isRequired="true". + + General token field with type="token". + + General language field with type="language". + + IDN table identifier used for IDN domain names + with type="token". + + General positive integer field with + type="positiveInteger". + + Contains the URL of an object like a registrar object + with type="anyURI". + + 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 internationalized form + ("int") or localized form ("loc"). Those elements use a field value + or "isLoc" attribute to specify the form used. If an "isLoc" + attribute is used, a value of "true" indicates the use of the + localized form, and a value of "false" indicates the use of the + internationalized form. This MAY override the form specified for a + parent element. A value of "int" is used to indicate the + internationalized form, and a value of "loc" is used to indicate the + localized form. When the internalized form ("int") is provided, the + field value MUST be represented in a subset of UTF-8 that can be + represented in the 7-bit US-ASCII character set. When the localized + form ("loc") is provided, the field value MAY be represented in + unrestricted UTF-8. + + The field elements below of the "registrar" + element specify the internationalized form with the + isLoc="false" attribute. + + ... + + ... + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + registrar-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of using the + field value to define the internationalized or localized form of the + remainder of the "contactPostal" field values. + + ... + + ... + + + + + + + + + + + + + + + + + contactPostal-YYYYMMDD.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 element, + under the element, and the element, + under the element. + +5.1.1.1. Object + + The domain element is based on the EPP domain response for an + authorized client (see Section 3.1.2 of [RFC5731]) with additional + data from an EPP query response, see Section 3.1.3 of + [RFC5731], Registry Grace Period (RGP) status from [RFC3915], and + data from the EPP command, see Section 5.2.1 of + [RFC5910]. + + A element substitutes for the abstract + element to create a concrete definition of a domain. The + element can be replaced by other domain definitions + using the XML schema substitution groups feature. + + The element contains the following child elements: + + * A element that contains the fully qualified name of the + domain name object. For IDNs, the A-label is used (see [RFC5891], + Section 4.4). + + * A element that contains the ROID assigned to the domain + name object when it was created. + + * An OPTIONAL element that contains the FQDN in the Unicode + character set. It MUST be provided if available. + + * An OPTIONAL element that references the IDN table + used for the IDN. This corresponds to the "id" attribute of the + element. This element MUST be present if the domain + name is an IDN. + + * An OPTIONAL 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. + + * One or more elements that contain the current status + descriptors associated with the domain name. + + * Zero or more OPTIONAL elements 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]. + + * An OPTIONAL element that contains the identifier for + the human or the organizational social information object + associated with the holder of the domain name object. + + * Zero or more OPTIONAL elements that contain identifiers + for the human or organizational social information objects + associated with the domain name object. + + * An OPTIONAL 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 + [RFC5731] for a description of the elements used to specify host + objects or host attributes. + + * A element that contains the identifier of the sponsoring + registrar. + + * An OPTIONAL 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. + + * An OPTIONAL 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. + + * An OPTIONAL 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. + + * An OPTIONAL 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. + + * An OPTIONAL element that contains the date and time of + the most recent modification of the domain name object. This + element MUST NOT be present if the domain name object has never + been modified. + + * An OPTIONAL element that contains the public key + information associated with Domain Name System security (DNSSEC) + extensions for the domain name as specified in [RFC5910]. + + * An OPTIONAL element that contains the date and time of + the most recent successful transfer of a domain name object. This + element MUST NOT be present if the domain name object has never + been transferred. + + * An OPTIONAL 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 element that contains the state of the most recent + transfer request. + + - A 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 element that contains the date and time that the + transfer was requested. + + - An 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 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 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. + + The following is an example of a domain name object: + + ... + + xn--exampl-gva.example + Dexample1-TEST + pt-BR + example.example + + jd1234 + sh8013 + sh8013 + + ns1.example.com + ns1.example1.example + + RegistrarX + RegistrarX + 1999-04-03T22:00:00.0Z + 2025-04-03T22:00:00.0Z + + ... + +5.1.1.2. Object + + The element contains the FQDN that was deleted and + purged. + + The following is an example of an object: + + ... + + ... + + foo.example + bar.example + + ... + + ... + +5.1.2. CSV Model + + For the CSV model of the domain name object, the + child element of the element is used to hold the new + or updated domain name objects for the deposit. The + child element of the element is + used to hold the deleted or purged domain name objects for the + deposit. Both the and + elements contain one or more elements with a set of + named CSV file definitions using the "name" attribute. + + Differential and Incremental Deposits are based on changes to the + domain name objects. The updated domain name object data under the + element is a cascade replace down all of the + domain name CSV files starting with the parent '"domain" CSV File + Definition' (Section 5.1.2.1.1). The child CSV file definitions + include a field. All the child CSV + file definition data for the domain name objects in the parent + '"domain" CSV File Definition' (Section 5.1.2.1.1) MUST first be + deleted and then set using the data in the child CSV files. The + deleted domain name object data under the element + is a cascade delete starting from the '"domain" Deletes CSV File + Definition' (Section 5.1.2.2.1). + +5.1.2.1. + + The is used to hold the new or updated domain + name object information for the deposit. The is + split into separate CSV file definitions using named + elements with the "name" attribute. The following sections include + the supported domain name CSV file definitions. + +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 field. + + The following "csvDomain" field elements MUST be used in the "domain" + element: + + Domain name field with type="eppcom:labelType" and + isRequired="true". + + The following "csvDomain" field elements MAY be used in the "domain" + element: + + Fully qualified name of the original IDN + domain name object related to the variant domain name object with + type="eppcom:labelType". + + The following "rdeCsv" and "csvRegistrar" fields, MUST be used in the + "domain" element: + + ROID for the domain name object with + isRequired="true". + + or A choice of the following: + + Identifier of the sponsoring client with + isRequired="true". + + Contains the Globally Unique Registrar + Identifier (GURID) assigned by ICANN with + type="positiveInteger" and isRequired="true". + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MAY be used in the "domain" + element: + + Identifier of the registrar, defined in Section 5.4, + of the client that created the domain name object. + + Identifier of the client that created the domain name + object. + + Identifier of the registrar, defined in Section 5.4, + of the client that last updated the domain name object. + + Identifier of the client that last updated the domain + name object. + + UTF-8 encoded domain name for the + field element. + + IDN table identifier used for the IDN domain + name object that MUST match an field element + in the "idnLanguage" CSV files, as defined in Section 5.5.2. + + Registrant contact identifier for the domain + name object. + + Date and time of the domain name object creation. + + 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. + + Expiration date and time for the domain name + object. + + 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" + element. + + ... + + ... + + + + + + + + + + + + + + + + + + + domain-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding domain-YYYYMMDD.csv + file. The file contains four records (two active ASCII domains, + original IDN with LANG-1 language rules, and variant IDN with LANG-1 + language rules). + + domain1.example,Ddomain1-TEST,,,registrantid,registrarX,registrarX, + clientY,2009-04-03T22:00:00.0Z,registrarX,clientY, + 2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z + domain2.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX, + clientY,1999-04-03T22:00:00.0Z,registrarX,clientY, + 2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z + xn--bc123-3ve.example,Dxnabc123-TEST,LANG-1,,registrantid,registrarX, + registrarX,clientY,2009-04-03T22:00:00.0Z,registrarX,clientY, + 2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z + xn--bc321-3ve.example,Dxnabc321-TEST,LANG-1,xn--bc123-3ve.example, + registrantid,registrarX,registrarX,clientY,2009-04-03T22:00:00.0Z, + registrarX,clientY,2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z + +5.1.2.1.2. "domainContacts" CSV File Definition + + The "domainContacts" CSV File Definition defines the fields and CSV + file references used for the domain name object link records to + contact objects, as described in 'Contact Object' (Section 5.3). + + The following "csvDomain" field elements, defined for the '"domain" + CSV File Definition' (Section 5.1.2.1.1), MUST be used in the + "domainContacts" element: + + The name of the domain object that is linked to + the contact object with isRequired="true". + + The contact type for the contact object + link with type="domain:contactAttrType" and isRequired="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 + "domainContacts" element: + + The server-unique contact identifier with + isRequired="true". + + The following is an example of a "domainContacts" + element: + + ... + + ... + + + + + + + + + domainContacts-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding domainContacts- + YYYYMMDD.csv file. The file contains an admin, tech, and billing + contact for the four domain names domain1.example, domain2.example, + xn--bc123-3ve.example, and xn--bc321-3ve.example: + + domain1.example,domain1admin,admin + domain1.example,domain1tech,tech + domain1.example,domain1billing,billing + domain2.example,domain2admin,admin + domain2.example,domain2tech,tech + domain2.example,domain2billing,billing + xn--bc123-3ve.example,xnabc123admin,admin + xn--bc123-3ve.example,xnabc123tech,tech + xn--bc123-3ve.example,xnabc123billing,billing + xn--bc321-3ve.example,xnabc123admin,admin + xn--bc321-3ve.example,xnabc123tech,tech + xn--bc321-3ve.example,xnabc123billing,billing + +5.1.2.1.3. "domainStatuses" CSV File Definition + + The "domainStatuses" CSV File Definition defines the fields and CSV + file references used for the domain name object statuses. + + The following "csvDomain" fields, defined for the '"domain" CSV File + Definition' (Section 5.1.2.1.1), MUST be used in the "domainStatuses" + element: + + Domain name of status with isRequired="true". + + The status of the domain name with + type="domain:statusValueType" and isRequired="true". + + The RGP status, as a sub-status of the + "pendingDelete" status value, with + type="rgp:statusValueType" as defined in [RFC3915]. + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MAY be used in the "domainStatuses" + element: + + Domain name object status description, + which is free-form text describing the rationale for the status. + + Language of the field. + + The following is an example of a "domainStatuses" + element: + + ... + + ... + + + + + + + + + + + domainStatuses-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding domainStatuses- + YYYYMMDD.csv file. The file contains the statuses for the four + domain names domain1.example, domain2.example, xn--bc123-3ve.example, + and xn--bc321-3ve.example: + + domain1.example,clientUpdateProhibited,"Disallow update", + en, + domain1.example,clientDeleteProhibited,"Disallow delete", + en, + domain2.example,ok,,, + xn--bc123-3ve.example,ok,,, + xn--bc321-3ve.example,ok,,, + +5.1.2.1.4. "domainNameServers" CSV File Definition + + The "domainNameServers" CSV File Definition defines the fields and + CSV file references used for the domain name delegated hosts (name + servers). The "domainNameServers" CSV files define the relationship + between a domain name object and a delegated host. The + "domainNameServers" CSV File is used to support the + model, defined in [RFC5731]. + + The following "csvDomain" fields, defined for the '"domain" CSV File + Definition' (Section 5.1.2.1.1), MUST be used in the + "domainNameServers" element: + + Domain name using the delegated host with + isRequired="true". + + The following "csvHost" and "rdeCsv" field elements MUST be used in + the "domainNameServers" element: + + or A choice of the following: + + Host name field with type="eppcom:labelType" and + isRequired="true". + + Host object ROID assigned to the host object with + isRequired="true". + + The following is an example of a "domainNameServers" + element: + + ... + + ... + + + + + + + + domainNameServers-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding domainNameServers- + YYYYMMDD.csv file. The file contains the delegated hosts (name + servers) for the four domain names domain1.example, domain2.example, + xn--bc123-3ve.example, and xn--bc321-3ve.example referenced via the + field element: + + domain1.example,Hns1_domain1_test-TEST + domain1.example,Hns2_domain1_test-TEST + domain2.example,Hns1_domain2_test-TEST + domain2.example,Hns2_domain2_test-TEST + xn--bc123-3ve.example,Hns1_example_test-TEST + xn--bc123-3ve.example,Hns2_example_test-TEST + xn--bc321-3ve.example,Hns1_example_test-TEST + xn--bc321-3ve.example,Hns2_example_test-TEST + +5.1.2.1.5. "domainNameServersAddresses" CSV File Definition + + The "domainNameServersAddresses" CSV File Definition defines the + fields and CSV file references used for supporting the domain host + attributes model. + + The following "csvDomain" fields, defined for the '"domain" CSV File + Definition' (Section 5.1.2.1.1), MUST be used in the + "domainNameServersAddresses" element: + + Domain name using the delegated host with host + and isRequired="true". + + The following "rdeCsv" fields, defined in 'CSV Model' + (Section 5.2.2), MUST be used in the "domainNameServersAddresses" + element: + + Host name field with type="eppcom:labelType" and + isRequired="true". + + The following "csvHost" fields, defined in 'CSV Model' + (Section 5.2.2), MAY be used in the "domainNameServersAddresses" + element: + + IP addresses associated with the host object with + type="host:addrStringType". + + IP addresses version associated with the host + object with type="host:ipType". "host:ipType" has the enumerated + values of "v4" or "v6". + + The following is an example of a "domainNameServersAddresses" + element: + + ... + + ... + + + + + + + + + + domainNameServersAddresses-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding + domainNameServersAddresses-YYYYMMDD.csv file. The file contains the + delegated hosts (name servers) for the four domain names + domain1.example, domain2.example, xn--bc123-3ve.example, and xn-- + bc321-3ve.example: + + domain1.example,ns1.domain1.example,192.0.2.1,v4 + domain1.example,ns2.domain1.example,2001:DB8::1,v6 + domain2.example,ns1.example.net,, + domain2.example,ns2.example.net,, + xn--bc123-3ve.example,ns1.example.net,, + xn--bc123-3ve.example,ns2.example.net,, + xn--bc321-3ve.example,ns1.example.net,, + xn--bc321-3ve.example,ns2.example.net,, + +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" + element when the DS Data Interface per + [RFC5910] is used: + + Contains the DS key tag value per [RFC5910] with + type="unsignedShort" and isRequired="true". + + Contains the DS algorithm value per [RFC5910] + with type="unsignedByte" and isRequired="true". + + Contains the DS digest type value per + [RFC5910] with type="unsignedByte" and isRequired="true". + + Contains the DS digest value per [RFC5910] with + type="hexBinary" and isRequired="true". + + The following "csvDomain" field elements MUST be used in the "dnssec" + element when the Key Data Interface per + [RFC5910] is used and MAY be used in the "dnssec" + element when the DS Data Interface per [RFC5910] is + used: + + Contains the flags field value per [RFC5910] with + type="unsignedShort" and isRequired="true". + + Contains the key protocol value per [RFC5910] + with type="unsignedByte" and isRequired="true". + + Contains the key algorithm value per [RFC5910] + with type="unsignedByte" and isRequired="true". + + Contains the public key value per [RFC5910] with + type="secDNS:keyType" and isRequired="true". + + The following "csvDomain" field elements MAY be used in the "dnssec" + element: + + Indicates a child's preference for the + number of seconds after signature generation when the parent's + signature on the DS information provided by the child will expire + with type="secDNS:maxSigLifeType" defined in [RFC5910]. + + The following "domain" fields, defined for the '"domain" CSV File + Definition' (Section 5.1.2.1.1), MUST be used in the "dnssec" + element: + + Domain name of the domain name object associated + with the DNSSEC record and isRequired="true". + + The following is an example of a "dnssec" + element with the DS Data Interface of [RFC5910]: + + + ... + + + + + + + + + + + + dnssec-ds-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding dnssec-ds- + YYYYMMDD.csv file. The file contains two DS records for + domain1.example: + + domain1.example,604800,30730,8,2,91C9B176EB////F1C46F6A55 + domain1.example,604800,61882,8,2,9F8FEAC94B////1272AF09F3 + + The following is an example of a "dnssec" + element with the Key Data Interface of [RFC5910]: + + + ... + + + + + + + + + + + + dnssec-key-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding dnssec-key- + YYYYMMDD.csv file. The file contains two key records for + domain1.example: + + domain1.example,604800,257,3,8,AwEAAZD1+z////G1jqviK8c= + domain1.example,604800,257,3,8,AwEAAbntWP////vwDitt940= + +5.1.2.1.7. "domainTransfer" CSV File Definition + + The "domainTransfer" CSV File Definition defines the fields and CSV + file references used for the domain name object pending and completed + transfer records. No additional field elements were added for use in + the "domainTransfer" element. + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MUST be used in the "domainTransfer" + element: + + State of the most recent transfer request with + isRequired="true". + + Identifier of the registrar, defined in Section 5.4, + of the client that requested the transfer with isRequired="true". + + Date and time that the transfer was requested with + isRequired="true". + + Identifier of the registrar, defined in Section 5.4, + of the client that should take or took action with + isRequired="true". + + Date and time that the transfer action should be + taken or has been taken with isRequired="true". + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MAY be used in the "domainTransfer" + element: + + Expiration date if the transfer command caused or + causes a change in the validity period. + + Identifier of the client that requested the transfer. + + 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 "domainTransfer" + element: + + Domain name of the domain name object involved in + the transfer with isRequired="true". + + The following is an example of a "domainTransfer" + element: + + ... + + ... + + + + + + + + + + + + + + + domainTransfer-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding domainTransfer- + YYYYMMDD.csv file. The file contains one domain transfer record with + a pending status: + + domain1.example,pending,registrarX,clientY, + 2011-03-08T19:38:00.0Z,registrarY,,2011-03-13T23:59:59.0Z, + 2025-04-03T22:00:00.0Z + +5.1.2.2. + + The is used to hold the deleted domain name + objects in a Differential or Incremental Deposit. All the domain + name object data is deleted as part of a cascade delete. The + is split into separate CSV file definitions using + named elements with the "name" attribute. The following + section defines the supported domain name deletes CSV file + definition. + +5.1.2.2.1. "domain" Deletes CSV File Definition + + The following "csvDomain" field elements MUST be used in the deletes + "domain" element: + + Domain name field with type="eppcom:labelType" and + isRequired="true". + + The following is an example of a "domain" + element: + + ... + + ... + + + + + + + domain-delete-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding domain-delete- + YYYYMMDD.csv file. The file contains two domain name records: + + domain1.example + domain2.example + +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 + and elements contain one or more + elements with a set of named CSV file definitions using the + "name" attribute. + +5.2.1. XML Model + + There are two elements used in the data escrow of the host objects + for the XML model including the element, under the + element, and the element, under + the element. + + An element substitutes for the + abstract element to create a concrete definition of a host. The + element can be replaced by other host + definitions using the XML schema substitution groups feature. + +5.2.1.1. Element + + The RDE host object is based on the EPP host response for an + authorized client (Section 3.1.2 of [RFC5732]). + + The OPTIONAL element contains the following child elements: + + * A element that contains the fully qualified name of the + host object. + + * A element that contains the ROID assigned to the host + object when the object was created. + + * One or more elements that describe the status of the host + object. + + * Zero or more elements that contain the IP addresses + associated with the host object. + + * A element that contains the identifier of the sponsoring + registrar. + + * An OPTIONAL 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. + + * An OPTIONAL element that contains the date and time of + host object creation. + + * An OPTIONAL 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. + + * An OPTIONAL 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. + + * An OPTIONAL 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 + transferred. + + The following is an example of a object: + + ... + + ns1.example1.example + Hns1_example_test-TEST + + + 192.0.2.2 + 192.0.2.29 + 2001:DB8:1::1 + RegistrarX + RegistrarX + 1999-05-08T12:10:00.0Z + RegistrarX + 2009-10-03T09:34:00.0Z + + ... + +5.2.1.2. Object + + The element contains the FQDN of a host that was + deleted. The element also supports host removal + based on ROID to support SRS systems in which different hosts with + the same FQDN are active at the same time. + + The following is an example of an object: + + ... + + ... + + ns1.example.example + + ... + + ... + +5.2.2. CSV Model + + For the CSV model of the host object, the child + element of the element is used to hold the new or + updated host objects for the deposit. The child + element of the element is used to hold the deleted or + purged host objects for the deposit. + + Differential and Incremental Deposits are based on changes to the + host objects. The updated host object data under the + element is a cascade replace down all of the host + CSV files starting with the parent '"host" CSV File Definition' + (Section 5.2.2.1.1). The child CSV file definitions include an + field. All the child CSV file + definition data for the host objects in the parent '"host" CSV File + Definition' (Section 5.2.2.1.1) MUST first be deleted and then set + using the data in the child CSV files. The deleted host object data + under the element is a cascade delete starting from + the '"host" Deletes CSV File Definition' (Section 5.2.2.2.1). + +5.2.2.1. + + The is used to hold the new or updated host object + information for the deposit. The is split into + separate CSV file definitions using named elements with + the "name" attribute. The following sections include the supported + host CSV file definitions. + +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" + element: + + Host name field with type="eppcom:labelType" and + isRequired="true". + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MUST be used in the "host" + element: + + ROID assigned to the host object with + isRequired="true". + + The following "rdeCsv" and "csvRegistrar" fields MAY be used in the + "host" element: + + or A choice of the following: + + Identifier of the sponsoring client with + isRequired="true". + + Contains the GURID assigned by ICANN with + type="positiveInteger" and isRequired="true". + + Identifier of the registrar, defined in Section 5.4, + of the client that created the host object. + + Identifier of the client that created the host + object. + + Identifier of the registrar, defined in Section 5.4, + of the client that last updated the host object. + + Identifier of the client that last updated the host + object. + + Date and time that the host object was created. + + 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. + + 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" + element: + + ... + + ... + + + + + + + + + + + + + + + + host-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding host-YYYYMMDD.csv + file. The file contains six host records with four being internal + hosts and two being external hosts: + + ns1.domain1.example,Hns1_example_test-TEST,registrarX,registrarX, + clientY,1999-05-08T12:10:00.0Z,registrarX, + clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z + ns2.domain1.example,Hns2_domain1_test-TEST,registrarX,registrarX, + clientY,1999-05-08T12:10:00.0Z,registrarX, + clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z + ns1.domain2.example,Hns1_domain2_test-TEST,registrarX,registrarX, + clientY,1999-05-08T12:10:00.0Z,registrarX, + clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z + ns2.domain2.example,Hns2_domain2_test-TEST,registrarX,registrarX, + clientY,1999-05-08T12:10:00.0Z,registrarX, + clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z + ns1.example.net,Hns1_example_test-TEST,registrarX,registrarX, + clientY,1999-05-08T12:10:00.0Z,registrarX, + clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z + ns2.example.net,Hns2_example_test-TEST,registrarX,registrarX, + clientY,1999-05-08T12:10:00.0Z,registrarX, + clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z + +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" + element: + + The status of the host with + type="host:statusValueType" and isRequired="true". + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MUST be used in the "hostStatuses" + element: + + Host object ROID assigned to the host object with + isRequired="true". + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MAY be used in the "hostStatuses" + element: + + Host object status description, which is + free-form text describing the rationale for the status. + + Language of the field. + + The following is an example of a "hostStatuses" + element: + + ... + + ... + + + + + + + + + + hostStatuses-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding hostStatuses- + YYYYMMDD.csv file. The file contains the statuses for the six host + names ns1.domain1.example, ns2.domain1.example, ns1.domain2.example, + ns2.domain2.example, ns1.example.net, and ns2.example.net: + + Hns1_domain1_test-TEST,ok,, + Hns2_domain1_test-TEST,ok,, + Hns1_domain2_test-TEST,ok,, + Hns2_domain2_test-TEST,ok,, + Hns1_example_test-TEST,ok,, + Hns2_example_test-TEST,ok,, + +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" element: + + IP addresses associated with the host object with + type="host:addrStringType". The attribute "isRequired" MUST equal + "true". + + IP addresses version associated with the host + object with type="host:ipType". "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" + element: + + Host object ROID assigned to the host object with + isRequired="true". + + The following is an example of a "hostAddresses" + element: + + ... + + ... + + + + + + + + + hostAddresses-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding hostAddresses- + YYYYMMDD.csv file. The file contains the IP addresses for the host + names ns1.domain1.example, ns2.domain1.example, ns1.domain2.example, + and ns2.domain2.example: + + Hns1_domain1_test-TEST,192.0.2.1,v4 + Hns2_domain1_test-TEST,2001:DB8::1,v6 + Hns1_domain2_test-TEST,192.0.2.2,v4 + Hns2_domain2_test-TEST,2001:DB8::2,v6 + +5.2.2.2. + + The is used to hold the deleted host objects in a + Differential or Incremental Deposit. All the host object data is + deleted as part of a cascade delete. The is split + into separate CSV file definitions using named elements + with the "name" attribute. The following section defines the + supported host deletes CSV file definition. + +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" + element: + + ROID assigned to the host object with + isRequired="true". + + The following is an example of a "host" + element: + + ... + + ... + + + + + + + host-delete-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the host-delete-YYYYMMDD.csv file. + The file contains four host records: + + Hns1_domain1_test-TEST + Hns2_domain1_test-TEST + Hns1_domain2_test-TEST + Hns2_domain2_test-TEST + +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 element, under + the element, and the + element, under the element. + + A element substitutes for the abstract + element to create a concrete definition of a contact. The + element can be replaced by other contact + definitions using the XML schema substitution groups feature. + +5.3.1.1. Object + + The contact object is based on the EPP contact response for an + authorized client (Section 3.1.2 of [RFC5733]) with some additions + including the data from an EPP query response, see + Section 3.1.3 of [RFC5733]. + + The OPTIONAL element contains the following child elements: + + * A element that contains the server-unique identifier of the + contact object. + + * A element that contains the ROID assigned to the contact + object when the object was created. + + * One or more elements that describe the status of the + contact object. + + * One or two 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 element + contains the following child elements: + + - A element that contains the name of the individual or + role represented by the contact. + + - An OPTIONAL element that contains the name of the + organization with which the contact is affiliated. + + - An element that contains address information associated + with the contact. An element contains the following + child elements: + + o One, two, or three OPTIONAL elements that contain + the contact's street address. + + o A element that contains the contact's city. + + o An OPTIONAL element that contains the contact's state + or province. + + o An OPTIONAL element that contains the contact's postal + code. + + o A element that contains the contact's two-letter + country code. + + * An OPTIONAL element that contains the contact's voice + telephone number. + + * An OPTIONAL element that contains the contact's facsimile + telephone number. + + * An element that contains the contact's email address. + + * A element that contains the identifier of the sponsoring + registrar. + + * An OPTIONAL element that contains the identifier of the + registrar that created the contact object. An OPTIONAL "client" + attribute is used to specify the client that performed the + operation. + + * An OPTIONAL element that contains the date and time of + contact object creation. + + * An OPTIONAL 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. + + * An OPTIONAL 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. + + * An OPTIONAL 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. + + * An OPTIONAL element that contains the following child + elements related to the last transfer request of the contact + object: + + - A element that contains the state of the most recent + transfer request. + + - An 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 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 element that contains the date and time that the + transfer was requested. + + - An 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 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 element. + + The following is an example of a object: + + ... + + sh8013 + Csh8013-TEST + + + + John Doe + Example Inc. + + 123 Example Dr. + Suite 100 + Dulles + VA + 20166-6503 + US + + + +1.7035555555 + +1.7035555556 + jdoe@example.example + RegistrarX + RegistrarX + 2009-09-13T08:01:00.0Z + RegistrarX + 2009-11-26T09:10:00.0Z + 2009-12-03T09:05:00.0Z + + pending + clientW + 2011-03-08T19:38:00.0Z + RegistrarX + 2011-03-13T23:59:59.0Z + + + + + + + ... + +5.3.1.2. Object + + The element contains the id of a contact that was + deleted. + + The following is an example of an object: + + ... + + ... + + sh8013-TEST + co8013-TEST + + ... + + ... + +5.3.2. CSV Model + + For the CSV model of the contact object, the + child element of the element is used to hold the new + or updated contacts objects for the deposit. The + child element of the element is + used to hold the deleted or purged contact objects for the deposit. + Both the and elements + contain one or more elements with a set of named CSV + file definitions using the "name" attribute. + + Differential and Incremental Deposits are based on changes to the + contact objects. The updated contact object data under the + element is a cascade replace down all of the + contact CSV files starting with the parent '"contact" CSV File + Definition' (Section 5.3.2.1.1). The child CSV file definitions + include a field. All the child CSV + file definition data for the contact objects in the parent '"contact" + CSV File Definition' (Section 5.3.2.1.1) MUST first be deleted and + then set using the data in the child CSV files. The deleted contact + object data under the element is a cascade + delete starting from the '"contact" Deletes CSV File Definition' + (Section 5.3.2.2.1). + +5.3.2.1. + + The is used to hold the new or updated contact + object information for the deposit. The is + split into separate CSV file definitions using named + elements with the "name" attribute. The following sections include + the supported contact CSV file definitions. + +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" element: + + Contains the server-unique contact identifier with + type="eppcom:clIDType" and isRequired="true". + + Contains the contact's email address with + type="eppcom:minTokenType" and isRequired="true". + + The following field elements MAY be used in the "contact" + element: + + Contains the contact's voice telephone number + with type="contact:e164StringType". + + Contains the contact's voice telephone number + extension with type="token". + + Contains the contact's facsimile telephone number + with type="contact:e164StringType". + + Contains the contact's facsimile telephone + number extension with type="token". + + The following "rdeCsv" and "csvRegistrar" fields MUST be used in the + "contact" element: + + The ROID for the contact object with + isRequired="true". + + or A choice of the following: + + Identifier of the sponsoring client with + isRequired="true". + + Contains the GURID assigned by ICANN with + type="positiveInteger" and isRequired="true". + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MAY be used in the "contact" + element: + + Identifier of the registrar, defined in Section 5.4, + of the client that created the contact object. + + Identifier of the client that created the contact + object. + + Identifier of the registrar, defined in Section 5.4, + of the client that last updated the contact object. + + Identifier of the client that last updated the + contact object. + + Date and time of the contact object creation. + + 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. + + 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" + element: + + ... + + ... + + + + + + + + + + + + + + + + + + + + contact-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the contact-YYYYMMDD.csv file. The + file contains nine object contact records: + + domain1admin,Cdomain1admin-TEST,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,registrarX,registrarX, + clientY,2009-09-13T08:01:00.0Z,registrarX,clientY, + 2009-11-26T09:10:00.0Z + domain1tech,Cdomain1tech-TEST,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,registrarX,registrarX, + clientY,2009-09-13T08:01:00.0Z,registrarX,clientY, + 2009-11-26T09:10:00.0Z + domain1billing,Cdomain1billing-TEST,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,registrarX,registrarX, + clientY,2009-09-13T08:01:00.0Z,registrarX,clientY, + 2009-11-26T09:10:00.0Z + domain2admin,Cdomain2admin-TEST,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,registrarX,registrarX, + clientY,2009-09-13T08:01:00.0Z,registrarX,clientY, + 2009-11-26T09:10:00.0Z + domain2tech,Cdomain2tech-TEST,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,registrarX,registrarX, + clientY,2009-09-13T08:01:00.0Z,registrarX,clientY, + 2009-11-26T09:10:00.0Z + domain2billing,Cdomain2billing-TEST,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,registrarX,registrarX, + clientY,2009-09-13T08:01:00.0Z,registrarX,clientY, + 2009-11-26T09:10:00.0Z + xnabc123admin,Cxnabc123admin-TEST,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,registrarX,registrarX, + clientY,2009-09-13T08:01:00.0Z,registrarX,clientY, + 2009-11-26T09:10:00.0Z + xnabc123tech,Cxnabc123tech-TEST,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,registrarX,registrarX, + clientY,2009-09-13T08:01:00.0Z,registrarX,clientY, + 2009-11-26T09:10:00.0Z + xnabc123billing,Cxnabc123billing-TEST,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,registrarX,registrarX, + clientY,2009-09-13T08:01:00.0Z,registrarX,clientY, + 2009-11-26T09:10:00.0Z + +5.3.2.1.2. "contactStatuses" CSV File Definition + + The "contactStatuses" CSV File Definition defines the fields and CSV + file references used for the contact object statuses. + + The following "csvContact" field elements, defined in the '"contact" + CSV File Definition' (Section 5.3.2.1.1), MUST be used in the + "contactStatuses" element: + + Server-unique contact identifier of status with + isRequired="true" and parent="true". + + The status of the contact with + type="contact:statusValueType" and isRequired="true". + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MAY be used in the "contactStatuses" + element: + + The contact object status description, + which is free-form text describing the rationale for the status. + + Language of the field. + + The following is an example of a "contactStatuses" + element: + + ... + + ... + + + + + + + + + + contactStatuses-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding contactStatuses- + YYYYMMDD.csv file. The file contains the statuses for the nine + contact identifiers: + + domain1admin,ok,, + domain1tech,ok,, + domain1billing,ok,, + domain2admin,ok,, + domain2tech,ok,, + domain2billing,ok,, + xnabc123admin,ok,, + xnabc123tech,ok,, + xnabc123billing,ok,, + +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" element: + + Contains the form of the postal address + information with type="contact:postalLineType" and + isRequired="true". This field specifies the form ("int" or + "loc"), as defined in Section 4.6.3, of the , + , , , + , , and fields. + + Contains the contact's name of the individual or + role represented by the contact with type="contact:postalLineType" + and isRequired="true". An OPTIONAL "isLoc" attribute is used to + indicate the localized or internationalized form as defined in + Section 4.6.3. + + Contains the contact's street address line with + type="contact:fPostalLineType". An "index" attribute is required + to indicate which street address line the field represents with + index="0" for the first line and incrementing for each line up to + index="2" for the third line. An OPTIONAL "isLoc" attribute is + used to indicate the localized or internationalized form as + defined in Section 4.6.3. + + Contains the contact's city with + type="contact:postalLineType" and isRequired="true". An OPTIONAL + "isLoc" attribute is used to indicate the localized or + internationalized form as defined in Section 4.6.3. + + Contains the contact's country code with + type="contact:ccType" and isRequired="true". An OPTIONAL "isLoc" + attribute is used to indicate the localized or internationalized + form as defined in Section 4.6.3. + + The following "csvContact" field elements MAY be used in the + "contactPostal" element: + + Contains the name of the organization with which + the contact is affiliated with type="contact:optPostalLineType". + An OPTIONAL "isLoc" attribute is used to indicate the localized or + internationalized form as defined in Section 4.6.3. + + Contains the contact's state or province with + type="contact:optPostalLineType". An OPTIONAL "isLoc" attribute + is used to indicate the localized or internationalized form as + defined in Section 4.6.3. + + Contains the contact's postal code with + type="contact:pcType". An OPTIONAL "isLoc" attribute is used to + indicate the localized or internationalized 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" + element: + + Server-unique contact identifier for the contact + object with isRequired="true" and parent="true". + + The following is an example of a "contactPostal" + element: + + ... + + ... + + + + + + + + + + + + + + + + + contactPostal-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the contactPostal-YYYYMMDD.csv file. + The file contains nine contact postal records: + + domain1admin,int,"John Doe","Example Inc.", + "123 Example Dr.","Suite 100",,Reston,VA,20190,US + domain1tech,int,"John Doe","Example Inc.", + "123 Example Dr.","Suite 100",,Reston,VA,20190,US + domain1billing,int,"John Doe","Example Inc.", + "123 Example Dr.","Suite 100",,Reston,VA,20190,US + domain2admin,int,"John Doe","Example Inc.", + "123 Example Dr.","Suite 100",,Reston,VA,20190,US + domain2tech,int,"John Doe","Example Inc.", + "123 Example Dr.","Suite 100",,Reston,VA,20190,US + domain2billing,int,"John Doe","Example Inc.", + "123 Example Dr.","Suite 100",,Reston,VA,20190,US + xnabc123admin,int,"John Doe","Example Inc.", + "123 Example Dr.","Suite 100",,Reston,VA,20190,US + xnabc123tech,int,"John Doe","Example Inc.", + "123 Example Dr.","Suite 100",,Reston,VA,20190,US + xnabc123billing,int,"John Doe","Example Inc.", + "123 Example Dr.","Suite 100",,Reston,VA,20190,US + +5.3.2.1.4. "contactTransfer" CSV File Definition + + The "contactTransfer" CSV File Definition defines the fields and CSV + file references used for the contact object pending and completed + transfer records. No additional field elements were added for use in + the "contactTransfer" element. The + following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MUST be used in the "contactTransfer" + element: + + State of the most recent transfer request with + isRequired="true". + + Identifier of the registrar, defined in Section 5.4, + of the client that requested the transfer with isRequired="true". + + Date and time that the transfer was requested with + isRequired="true". + + Identifier of the registrar, defined in Section 5.4, + of the client that should take or took action with + isRequired="true". + + Date and time that the transfer action should be + taken or has been taken with isRequired="true". + + The following "rdeCsv" fields, defined in 'CSV Common Field Elements' + (Section 4.6.2.2), MAY be used in the "contactTransfer" + element: + + Identifier of the client that requested the transfer. + + 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 + "contactTransfer" element: + + Server-unique contact identifier for the contact + object with isRequired="true". + + The following is an example of a "contactTransfer" + element: + + ... + + ... + + + + + + + + + + + + + + contactTransfer-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the contactTransfer-YYYYMMDD.csv file. + The file contains one contact transfer record in pending status: + + xnabc123admin,clientApproved,registrarX,clientX, + 2011-04-08T19:38:00.0Z,registrarY,clientY,2011-04-09T20:38:00.0Z + +5.3.2.1.5. "contactDisclose" CSV File Definition + + The "contactDisclose" CSV File Definition defines the fields and CSV + file references used for the contact disclose object records. + + The following "csvContact" field elements MAY be used in the + "contactDisclose" element: + + 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 + field. + + Exceptional disclosure preference flag + for the localized form of the contact name with type="boolean". + + Exceptional disclosure preference flag + for the internationalized form of the contact name with + type="boolean". + + Exceptional disclosure preference flag + for the localized form of the contact organization with + type="boolean". + + Exceptional disclosure preference flag + for the internationalized form of the contact organization with + type="boolean". + + Exceptional disclosure preference flag + for the localized form of the contact address with type="boolean". + + Exceptional disclosure preference flag + for the internationalized form of the contact address with + type="boolean". + + Exceptional disclosure preference flag + of the contact voice telephone number with type="boolean". + + Exceptional disclosure preference flag of + the contact facsimile telephone number with type="boolean". + + 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 + "contactDisclose" element: + + Server-unique contact identifier for the contact + object with isRequired="true". + + The following is an example of a "contactDisclose" + element: + + ... + + ... + + + + + + + + + + + + + + + + + contactDisclose-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the contactDisclose-YYYYMMDD.csv file. + The file contains one disclosure records, disabling disclosure of + voice, fax, and email: + + xnabc123admin,0,0,0,0,0,0,0,1,1,1 + +5.3.2.2. + + The is used to hold the deleted contact objects + in a Differential or Incremental Deposit. All the contact object + data is deleted as part of a cascade delete. The + is split into separate CSV file definitions + using named elements with the "name" attribute. The + following section defines the supported contact deletes CSV file + definition. + +5.3.2.2.1. "contact" Deletes CSV File Definition + + The following "csvContact" field elements MUST be used in the deletes + "contact" element: + + Contains the server-unique contact identifier with + type="eppcom:clIDType" and isRequired="true". + + The following is an example of a "contact" + element: + + ... + + ... + + + + + + + contact-delete-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the contact-delete-YYYYMMDD.csv file. + The file contains six contact records: + + domain1admin + domain1tech + domain1billing + domain2admin + domain2tech + domain2billing + +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 + element, under the element, and the + element, under the element. + + An element substitutes for the + abstract element to create a + concrete definition of a registrar. The + element can be replaced by other + domain definitions using the XML schema substitution groups feature. + +5.4.1.1. Element + + The element contains the following child elements: + + * An element that contains the registry-unique identifier of + the registrar object. This has a superordinate relationship + to a subordinate , , or of domain, contact, and + host objects. + + * An element that contains the name of the registrar. + + * An OPTIONAL element that contains the GURID assigned by + ICANN. + + * An OPTIONAL element that contains the operational status + of the registrar. Possible values are: ok, readonly, and + terminated. + + * One or two OPTIONAL 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 element + contains the following child elements: + + - A element that contains address information associated + with the registrar. The element contains the following + child elements: + + o One, two, or three OPTIONAL elements that contain + the registrar's street address. + + o A element that contains the registrar's city. + + o An OPTIONAL element that contains the registrar's state + or province. + + o An OPTIONAL element that contains the registrar's + postal code. + + o A element that contains the registrar's country code. + + * An OPTIONAL element that contains the registrar's voice + telephone number. + + * An OPTIONAL element that contains the registrar's facsimile + telephone number. + + * An OPTIONAL element that contains the registrar's email + address. + + * An OPTIONAL element that contains the registrar's URL. + + * An OPTIONAL element that contains WHOIS information. + The element contains the following child elements: + + - An OPTIONAL element that contains the name of the + registrar WHOIS server listening on TCP port 43 as specified in + [RFC3912]. + + - An OPTIONAL element that contains the name of the + registrar WHOIS server listening on TCP port 80/443. + + * An OPTIONAL element that contains the creation date and + time of the registrar object. + + * An OPTIONAL element that contains the date and time of + the most recent modification of the registrar object. This + element MUST NOT be present if the registrar object has never been + modified. + + The following is an example of a object: + + ... + + RegistrarX + Registrar X + 8 + ok + + + 123 Example Dr. + Suite 100 + Dulles + VA + 20166-6503 + US + + + +1.7035555555 + +1.7035555556 + jdoe@example.example + http://www.example.example + + whois.example.example + http://whois.example.example + + 2005-04-23T11:49:00.0Z + 2009-02-17T17:51:00.0Z + + ... + +5.4.1.2. Object + + The element contains the id of a registrar that + was deleted. + + The following is an example of object: + + ... + + ... + + agnt0001-TEST + + ... + + ... + +5.4.2. CSV Model + + For the CSV model of the registrar object, the + child element of the element + is used to hold the new or updated registrar objects for the deposit. + The child element of the element + is used to hold the deleted or purged registrar objects for the + deposit. Both the and + elements contain one or more elements with a set of + named CSV file definitions using the "name" attribute. + + Differential and Incremental Deposits are based on changes to the + registrar objects. The updated registrar object data under the + element is a cascade replace down all of the + registrar CSV files starting with the parent '"registrar" CSV File + Definition' (Section 5.4.2.1.1). The child CSV file definitions + include a field. All the child CSV + file definition data for the registrar objects in the parent + '"registrar" CSV File Definition' (Section 5.4.2.1.1) MUST first be + deleted and then set using the data in the child CSV files. The + deleted registrar object data under the + element is a cascade delete starting from the '"registrar" Deletes + CSV File Definition' (Section 5.4.2.2.1). + +5.4.2.1. + + The is used to hold the new or updated + registrar object information for the deposit. The + is split into separate CSV file definitions + using named elements with the "name" attribute. The + following sections include the supported registrar CSV file + definitions. + +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" element: + + or A choice of the + following: + + Contains the server-unique registrar + identifier with type="eppcom:clIDType" and isRequired="true". + + Contains the GURID assigned by ICANN with + type="positiveInteger" and isRequired="true". + + Contains the name of the registrar with + type="normalizedString" and isRequired="true". + + The following field elements MAY be used in the "registrar" + element: + + Contains the status of the registrar with + type="csvRegistrar:statusValueType". + + Contains the ID assigned by ICANN with + type="positiveInteger". This field is included in this section in + addition to the section above to support optionally providing the + field when the field is + used. + + 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" + element: + + Date and time of the registrar object creation. + + 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. + + URL for the registrar web home page. + + The following "csvContact" fields, defined in 'Contact Object' + (Section 5.3), MAY be used in the "registrar" + element: + + 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 internationalized form, as defined in + Section 4.6.3. + + Registrar city with an OPTIONAL "isLoc" attribute + that is used to indicate the localized or internationalized form, + as defined in Section 4.6.3. + + Registrar country code with an OPTIONAL "isLoc" + attribute that is used to indicate the localized or + internationalized form, as defined in Section 4.6.3. + + Registrar email address. The attribute + "isRequired" MUST equal "false". + + Registrar state or province with an OPTIONAL + "isLoc" attribute that is used to indicate the localized or + internationalized form, as defined in Section 4.6.3. + + Registrar postal code with an OPTIONAL "isLoc" + attribute that is used to indicate the localized or + internationalized form, as defined in Section 4.6.3. + + Registrar voice telephone number. + + Registrar voice telephone number extension. + + Registrar facsimile telephone number. + + Registrar facsimile telephone number extension. + + The following is an example of a "registrar" + element: + + ... + + ... + + + + + + + + + + + + + + + + + + + + + + + + + + registrar-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the registrar-YYYYMMDD.csv file. The + file contains one registrar record: + + registrarX,"Example Inc.",8,ok,"123 Example Dr.", + "Suite 100",,Dulles,VA,20166-6503,US,+1.7035555555,1234, + +1.7035555556,,jdoe@example.example,http://www.example.example, + http://whois.example.example,2005-04-23T11:49:00.0Z, + 2009-02-17T17:51:00.0Z + +5.4.2.2. + + The is used to hold the deleted registrar + objects in a Differential or Incremental Deposit. All the registrar + object data is deleted as part of a cascade delete. The + is split into separate CSV file definitions + using named elements with the "name" attribute. The + following section defines the supported registrar deletes CSV file + definition. + +5.4.2.2.1. "registrar" Deletes CSV File Definition + + The following "csvRegistrar" field elements MUST be used in the + deletes "registrar" element: + + or A choice of the + following: + + Contains the server-unique registrar + identifier with type="eppcom:clIDType" and isRequired="true". + + Contains the GURID assigned by ICANN with + type="positiveInteger". The attribute "isRequired" MUST equal + "true". + + The following is an example of a "registrar" + element: + + ... + + ... + + + + + + + registrar-delete-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the registrar-delete-YYYYMMDD.csv + file. The file contains one registrar record: + + registrarZ + +5.5. IDN Table Reference Object + + The Internationalized Domain Names (IDN) table reference object is a + pseudo-object that is used to provide a short reference to the IDN + table and policy used in IDN registrations. The IDN reference 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.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 + , under the element. + +5.5.1.1. Object + + The contains the following elements. An "id" + attribute is used to specify an identifier for the IDN table. + + * A element that contains the URL of the IDN table that is + being referenced. + + * A 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 + implicitly generated IDN variants. For a list of suggested states + for implicit IDN variants, please see [variantTLDsReport]. + + The following is an example of object: + + ... + + + http://www.iana.org/domains/idn-tables/tables/br_pt-br_1.0.html + + + http://registro.br/dominio/regras.html + + + ... + +5.5.2. CSV Model + + The IDN domain names, defined in Section 5.1, MAY have references to + the IDN language identifier using the field + element. The IDN table reference object defines the mapping of a + language identifier to a language table URL. The language table URL + defines the character code points that can be used for the language + identifier. The elements used for the IDN table reference object are + defined in this section. The child element of the + element is used to hold the new or updated IDN table + reference objects for the deposit. The child + element of the element is used to hold the deleted or + purged IDN table reference objects for the deposit. Both the + and elements contain one or more + elements with a set of named CSV file definitions using + the "name" attribute. + +5.5.2.1. + + The is used to hold the new or updated IDN table + reference object information for the deposit. The + is split into separate CSV file definitions using named + elements with the "name" attribute. The following sections include + the supported IDN table reference CSV file definitions. + +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" element: + + The language identifier that matches the values + for the field element in the '"domain" CSV + File Definition' (Section 5.1.2.1.1) files. The attribute + "isRequired" MUST equal "true". + + URL that defines the character code points that can be + used for 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" + element: + + ... + + ... + + + + + + + + idnLanguage-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding idnLanguage- + YYYYMMDD.csv file. The file contains two IDN language records: + + LANG-1, + http://www.iana.org/domains/idn-tables/tables/test_tab1_1.1.txt + LANG-2, + http://www.iana.org/domains/idn-tables/tables/test_tab2_1.1.txt + +5.5.2.2. + + The is used to hold the deleted IDN table reference + objects in a Differential or Incremental Deposit. The + is split into separate CSV file definitions using + named elements with the "name" attribute. The following + section defines the supported IDN table reference deletes CSV file + definition. + +5.5.2.2.1. "idnLanguage" Deletes CSV File Definition + + The following "idnLanguage" field elements MUST be used in the + deletes "idnLanguage" element: + + The language identifier that matches the values + for the 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" + element: + + ... + + ... + + + + + + + idnLanguage-delete-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the idnLanguage-delete-YYYYMMDD.csv + file. The file contains one IDN language record: + + LANG-2 + +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 element, under the + element, and the element, under the + element. + + An element substitutes for the + abstract element to create a concrete definition of an NNDN. The + element can be replaced by other NNDN + definitions using the XML schema substitution groups feature. + +5.6.1.1. Object + + The element contains the following child elements: + + * An element that contains the fully qualified name of the + NNDN. For IDNs, the A-label is used (see [RFC5891], Section 4.4). + + * An OPTIONAL element that contains the fully qualified name + of the NNDN in the Unicode character set. It MUST be provided if + available. + + * An OPTIONAL element that references the IDN table + used for the NNDN. This corresponds to the "id" attribute of the + element. This element MUST be present if the NNDN + is an IDN. + + * An OPTIONAL element is used to indicate that the + NNDN is used for an IDN variant. This element contains the domain + name used to generate the IDN variant. + + * A element that indicates the state of the NNDN: + blocked, withheld, or mirrored. + + - If an NNDN is considered undesirable for registration (i.e., + unavailable for allocation to anyone), then the NNDN will be + tagged as "blocked". + + - If an NNDN is considered a potential registration of a domain + name object for a registrant, then the NNDN will be tagged as + "withheld". This status is only used when the NNDN is used for + an IDN variant. + + - If an NNDN is considered a mirrored IDN variant of a domain + name object, then the NNDN will be tagged as "mirrored". A + "mirroringNS" attribute is used to specify if the mirrored IDN + variant uses the NS mirror mechanism, meaning that the + activated variant domain name (i.e., NNDN) is delegated in the + DNS using the same NS records as in the . The + default value of "mirroringNS" is true. If another mechanism + such as DNAME [RFC6672] is used, the value of the "mirroringNS" + attribute MUST be false. + + * An OPTIONAL element that contains the date and time of + the NNDN object creation. + + The following is an example of an object: + + ... + + xn--exampl-gva.example + pt-BR + example.example + withheld + 2005-04-23T11:49:00.0Z + + ... + +5.6.1.2. Object + + The element contains the NNDN that was deleted, + i.e., the . + + The following is an example of an object: + + ... + + ... + + xn--pingino-q2a.example + + ... + + ... + +5.6.2. CSV Model + + For the CSV model of the NNDN object, the child + element of the element is used to hold the new or + updated NNDN objects for the deposit. The child + element of the element is used to hold the deleted or + purged NNDN objects for the deposit. Both the and + elements contain one or more elements + with a set of named CSV file definitions using the + "name" attribute. + +5.6.2.1. + + The is used to hold the new or updated NNDN object + information for the deposit. The is split into + separate CSV file definitions using named elements with + the "name" attribute. The following sections include the supported + NNDN CSV file definitions. + +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" + element: + + Fully qualified name of the NNDN with + type="eppcom:labelType" and isRequired="true". For IDNs, the + A-label is used (see [RFC5891], Section 4.4). + + State of the NNDN: blocked or withheld with + type="rdeNNDN:nameState" and isRequired="true". See + Section 5.6.1.1 for a description of the possible values for the + element. + + The following field elements MAY be used in the "NNDN" + element: + + Domain name used to generate the IDN variant + with type="eppcom:labelType". + + Defines whether the "mirroring" + uses the NS mirror mechanism, as described + for the "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" + element: + + Date and time of the NNDN object creation. + + Name of the NNDN in the Unicode character set for + the field element. + + 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" + element: + + ... + + ... + + + + + + + + + + + + NNDN-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding NNDN-YYYYMMDD.csv + file. The file contains two NNDN records for an IDN with one blocked + variant and one mirrored variant: + + xn--bc456-3ve.example,LANG-1,xn--bc123-3ve.example, + blocked,,2005-04-23T11:49:00.0Z + xn--bc789-3ve.example,LANG-1,xn--bc123-3ve.example, + mirrored,1,2005-04-23T11:49:00.0Z + +5.6.2.2. + + The is used to hold the deleted NNDN objects in a + Differential or Incremental Deposit. The is split + into separate CSV file definitions using named elements + with the "name" attribute. The following section defines the + supported NNDN deletes CSV file definition. + +5.6.2.2.1. "NNDN" Deletes CSV File Definition + + The following "NNDN" field elements MUST be used in the deletes + "NNDN" element: + + Fully qualified name of the NNDN with + type="eppcom:labelType" and isRequired="true". + + The following is an example of an "NNDN" + element: + + ... + + ... + + + + + + + NNDN-delete-YYYYMMDD.csv + + + + ... + + ... + + The following is an example of the corresponding NNDN-delete- + YYYYMMDD.csv file. The file contains one NNDN records: + + xn--bc456-3ve.example + +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 + element. The EPP parameters object SHOULD be included if the + registry supports EPP. A maximum of one EPP parameters object MUST + exist at a certain point in time (Time Watermark). + + The syntax and content of the children + elements is as explained in Section 2.4 of [RFC5730]. The children + of the are as follows: + + * One or more elements that indicate the EPP versions + supported by the registry. + + * One or more elements that indicate the identifiers of the + text response languages supported by the registry's EPP server. + + * One or more elements that contain namespace URIs + representing the objects that the registry's EPP server is capable + of managing. + + * An OPTIONAL element that contains one or more + elements that contain namespace URIs representing object + extensions supported by the registry's EPP server. + + * A 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. + + The following is an example of element object: + + ... + + 1.0 + en + urn:ietf:params:xml:ns:domain-1.0 + + urn:ietf:params:xml:ns:contact-1.0 + + urn:ietf:params:xml:ns:host-1.0 + + + urn:ietf:params:xml:ns:rgp-1.0 + urn:ietf:params:xml:ns:secDNS-1.1 + + + + + + + + + + + + + + + + + + + ... + +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 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. Object + + The OPTIONAL contains the following attributes: + + * An that defines that the referenced is + REQUIRED. + + * that defines the XPath (see [W3C.REC-xpath-31-20170321]) + of the element referenced by . + + The following is an example of object: + + ... + + ... + +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 + element. + +5.9.1. Object + + The contains the following elements: + + * A choice of one of the elements defined in the + "repositoryTypeGroup" group element that indicates the unique + identifier for the repository being escrowed. Possible elements + are: + + - An element that defines TLD or the RCDN being + escrowed in the case of a registry data escrow deposit. For + IDNs, the A-label is used (see [RFC5891], Section 4.4). + + - An element that defines the Registrar ID + corresponding to a registrar data escrow deposit. In the case + of an ICANN-accredited registrar, the + element MUST be the IANA Registrar ID assigned by ICANN. + + - An element that defines the provider ID + corresponding to a Privacy and Proxy Services Provider (PPSP) + data escrow deposit. In the case of an ICANN-accredited PPSP, + the element MUST be the unique ID assigned by + ICANN. + + - An element that defines the provider ID + corresponding to a reseller data escrow deposit. + + * A element that contains the number of objects in the SRS + at a specific point in time (Timeline Watermark) regardless of the + type of deposit: Differential, Full, or Incremental. The + element supports the following attributes: + + - A "uri" attribute reflects the XML namespace URI of the primary + objects for the XML model and CSV model. For example, the + "uri" is set to "urn:ietf:params:xml:ns:rdeDomain-1.0" for + domain name objects using the XML model, and the "uri" is set + to "urn:ietf:params:xml:ns:csvDomain-1.0" for domain name + objects using the CSV model. + + - An OPTIONAL "rcdn" attribute indicates the RCDN of the objects + included in the element. For IDNs, the A-label is used + [RFC5891], Section 4.4. If the "rcdn" attribute is present, + the value of the element must include only objects + related to registrations in the same and lower levels. For + example in a data escrow deposit for the .EXAMPLE TLD, a value + of "example" in the "rcdn" attribute within the element + indicates the number of objects in the TLD including objects in + other RCDNs within the TLD, whereas a value of "com.example" + indicates the number of elements for objects under + "com.example" and lower levels. Omitting the "rcdn" attribute + indicates that the total includes all objects of the specified + "uri" in the repository (e.g., the TLD, Registrar, or PPSP). + + - An OPTIONAL "registrarId" attribute indicates the identifier of + the sponsoring registrar of the objects included in the + element. In the case of an ICANN-accredited registrar, the + value MUST be the IANA Registrar ID assigned by ICANN. + + * An OPTIONAL element that contains a tag that defines + the expected content in the deposit. The producer and consumer of + the deposits will coordinate the set of possible + element values. + + The following is an example of object referencing + only the XML model objects: + + ... + + test + 2 + 1 + 1 + 1 + + 1 + 1 + 1 + + + ... + + The following is an example of an object + referencing the CSV and XML model objects: + + ... + + test + 2 + 1 + 1 + 1 + + 1 + 1 + 1 + + + ... + +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 [variantTLDsReport] + for further details on IDN variants. + + 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: + + 1. Extending base objects with the mechanisms defined for XML and + CSV models. + + * In the case of the XML model, abstract elements could be used + to extend the following objects: , , , + , and using the XML schema substitution + groups feature. + + 2. Defining a object to specify which OPTIONAL elements of + this base specification are required based on the business model + of the registry. An example is the element that is + usually REQUIRED, but it is specified as OPTIONAL in this + specification to support some existing business models. + + 3. Adding new escrowed objects using the and + elements. + + 4. Providing the XML schemas to third parties that require them to + validate the escrow deposits. + +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: + + * 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. + + * Count the objects and validate that the number of objects is equal + to the number objects reported in the
element of the + escrow deposit of that point in time (Timeline Watermark). + + * All contact objects linked to domain names MUST be present. + + * All registrar objects linked to other objects MUST be present. + + * No domain name exists as both a domain name and an NNDN. + + * The elements listed as required in the element MUST be + present. + + * All idnTableRef definitions linked from other objects MUST be + present. + + * If an EPP parameters object was escrowed in the past, one and only + one EPP parameters object MUST be present. + + * The Timeline Watermark is not in the future. + +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 and tags are not part of the schema; + they are used to note the beginning and ending of the schema for URI + registration purposes. + +9.1. RDE CSV Schema + + + + + + + + + + Registry Data Escrow Comma-Separated Values (CSV) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.2. RDE Domain Object + + + + + + + + + + + + + + Registry Data Escrow Domain provisioning schema + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.3. CSV Domain Object + + + + + + + + + + + + + + Domain Name Comma-Separated Values (CSV) Object + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.4. RDE Host Object + + + + + + + + + + + Registry Data Escrow Host provisioning schema + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.5. CSV Host Object + + + + + + + + + + + + Host Comma-Separated Values (CSV) Object + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.6. RDE Contact Object + + + + + + + + + + + + Registry Data Escrow contact provisioning schema + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.7. CSV Contact Object + + + + + + + + + + + + Contact Comma-Separated Values (CSV) Object + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.8. RDE Registrar Object + + + + + + + + + + + + Registry Data Escrow registrar provisioning schema + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.9. CSV Registrar Object + + + + + + + + + + + + + Registrar Comma-Separated Values (CSV) Object + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.10. RDE IDN Table Reference Objects + + + + + + + + Registry Data Escrow IDN provisioning schema + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.11. CSV IDN Language Object + + + + + + + + + + IDN Language Comma-Separated Values (CSV) Object + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.12. EPP Parameters Object + + + + + + + + + + Registry Data Escrow EPP Parameters schema + + + + + + + + + + + + + + + + + + + + + + +9.13. NNDN Object + + + + + + + + + + Registry Data Escrow NNDN provisioning schema + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.14. CSV NNDN Object + + + + + + + + + + + NNDN (NNDN's not domain name) (CSV) Object + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.15. Policy Object + + + + + + + Registry Data Escrow Policy schema + + + + + + + + + + + + + + + +9.16. Header Object + + + + + + + + + Data Escrow Deposit Header schema + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +9.17. DNRD Common Objects + + + + + + + + Data Escrow Deposit Common Objects schema + + + + + + + + + + + + +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 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:rdeCsv-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE CSV XML schema: + + URI: urn:ietf:params:xml:schema:rdeCsv-1.0 + Registrant Contact: IESG + + See Section 9.1 of this document. + + RDE domain namespace: + + URI: urn:ietf:params:xml:ns:rdeDomain-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE domain XML schema: + + URI: urn:ietf:params:xml:schema:rdeDomain-1.0 + Registrant Contact: IESG + + See Section 9.2 of this document. + + CSV domain namespace: + + URI: urn:ietf:params:xml:ns:csvDomain-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + CSV domain XML schema: + + URI: urn:ietf:params:xml:schema:csvDomain-1.0 + Registrant Contact: IESG + + See Section 9.3 of this document. + + RDE host namespace: + + URI: urn:ietf:params:xml:ns:rdeHost-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE host XML schema: + + URI: urn:ietf:params:xml:schema:rdeHost-1.0 + Registrant Contact: IESG + + See Section 9.4 of this document. + + CSV host namespace: + + URI: urn:ietf:params:xml:ns:csvHost-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + CSV host XML schema: + + URI: urn:ietf:params:xml:schema:csvHost-1.0 + Registrant Contact: IESG + + See Section 9.5 of this document. + + RDE contact namespace: + + URI: urn:ietf:params:xml:ns:rdeContact-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE contact XML schema: + + URI: urn:ietf:params:xml:schema:rdeContact-1.0 + Registrant Contact: IESG + + See Section 9.6 of this document. + + CSV contact namespace: + + URI: urn:ietf:params:xml:ns:csvContact-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + CSV contact XML schema: + + URI: urn:ietf:params:xml:schema:csvContact-1.0 + Registrant Contact: IESG + + See Section 9.7 of this document. + + RDE registrar namespace: + + URI: urn:ietf:params:xml:ns:rdeRegistrar-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE registrar XML schema: + + URI: urn:ietf:params:xml:schema:rdeRegistrar-1.0 + Registrant Contact: IESG + + See Section 9.8 of this document. + + CSV registrar namespace: + + URI: urn:ietf:params:xml:ns:csvRegistrar-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + CSV registrar XML schema: + + URI: urn:ietf:params:xml:schema:csvRegistrar-1.0 + Registrant Contact: IESG + + See Section 9.9 of this document. + + RDE IDN namespace: + + URI: urn:ietf:params:xml:ns:rdeIDN-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE IDN XML schema: + + URI: urn:ietf:params:xml:schema:rdeIDN-1.0 + Registrant Contact: IESG + + See Section 9.10 of this document. + + CSV IDN namespace: + + URI: urn:ietf:params:xml:ns:csvIDN-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + CSV IDN XML schema: + + URI: urn:ietf:params:xml:schema:csvIDN-1.0 + Registrant Contact: IESG + + See Section 9.11 of this document. + + RDE EPP parameters namespace: + + URI: urn:ietf:params:xml:ns:rdeEppParams-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE EPP parameters XML schema: + + URI: urn:ietf:params:xml:schema:rdeEppParams-1.0 + Registrant Contact: IESG + + See Section 9.12 of this document. + + RDE NNDN namespace: + + URI: urn:ietf:params:xml:ns:rdeNNDN-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE NNDN XML schema: + + URI: urn:ietf:params:xml:schema:rdeNNDN-1.0 + Registrant Contact: IESG + + See Section 9.13 of this document. + + CSV NNDN namespace: + + URI: urn:ietf:params:xml:ns:csvNNDN-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + CSV NNDN XML schema: + + URI: urn:ietf:params:xml:schema:csvNNDN-1.0 + Registrant Contact: IESG + + See Section 9.14 of this document. + + RDE Policy namespace: + + URI: urn:ietf:params:xml:ns:rdePolicy-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE Policy XML schema: + + URI: urn:ietf:params:xml:schema:rdePolicy-1.0 + Registrant Contact: IESG + + See Section 9.15 of this document. + + RDE Header namespace: + + URI: urn:ietf:params:xml:ns:rdeHeader-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE Header XML schema: + + URI: urn:ietf:params:xml:schema:rdeHeader-1.0 + Registrant Contact: IESG + + See Section 9.16 of this document. + + RDE Common Objects namespace: + + URI: urn:ietf:params:xml:ns:rdeDnrdCommon-1.0 + Registrant Contact: IESG + XML: None. Namespace URIs do not represent an XML specification. + + RDE Common Objects XML schema: + + URI: urn:ietf:params:xml:schema:rdeDnrdCommon-1.0 + Registrant Contact: IESG + + 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. + + | Note: if TLS is used when providing an escrow service, the + | recommendations in [BCP195] MUST be implemented. + +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-sensitive and/or personal data receives the + required protection. + +14. Example of a Full Deposit Using the XML Model + + The following is an example of a Full Deposit using the XML model: + + + + + 2019-10-17T00:00:00Z + + 1.0 + urn:ietf:params:xml:ns:rdeHeader-1.0 + + urn:ietf:params:xml:ns:rdeContact-1.0 + + urn:ietf:params:xml:ns:rdeHost-1.0 + + urn:ietf:params:xml:ns:rdeDomain-1.0 + + urn:ietf:params:xml:ns:rdeRegistrar-1.0 + + urn:ietf:params:xml:ns:rdeIDN-1.0 + + urn:ietf:params:xml:ns:rdeNNDN-1.0 + + urn:ietf:params:xml:ns:rdeEppParams-1.0 + + + + + + + + test + 2 + + 1 + + 1 + + 1 + + 1 + + 1 + + 1 + + + + + + example1.example + Dexample1-TEST + + jd1234 + sh8013 + sh8013 + + ns1.example.com + ns1.example1.example + + RegistrarX + RegistrarX + 1999-04-03T22:00:00.0Z + 2025-04-03T22:00:00.0Z + + + + + example2.example + Dexample2-TEST + + + jd1234 + sh8013 + sh8013 + RegistrarX + RegistrarX + 1999-04-03T22:00:00.0Z + 2025-04-03T22:00:00.0Z + + + + + ns1.example1.example + Hns1_example_test-TEST + + + 192.0.2.2 + 192.0.2.29 + 2001:DB8:1::1 + RegistrarX + RegistrarX + 1999-05-08T12:10:00.0Z + RegistrarX + 2009-10-03T09:34:00.0Z + + + + + sh8013 + Csh8013-TEST + + + + John Doe + Example Inc. + + 123 Example Dr. + Suite 100 + Dulles + VA + 20166-6503 + US + + + +1.7035555555 + + +1.7035555556 + + jdoe@example.example + + RegistrarX + RegistrarX + + 2009-09-13T08:01:00.0Z + + RegistrarX + + 2009-11-26T09:10:00.0Z + + 2009-12-03T09:05:00.0Z + + + + + + + + + + RegistrarX + Registrar X + 8 + ok + + + 123 Example Dr. + + Suite 100 + + Dulles + VA + 20166-6503 + US + + + +1.7035555555 + + +1.7035555556 + + jdoe@example.example + + http://www.example.example + + + whois.example.example + + http://whois.example.example + + + 2005-04-23T11:49:00.0Z + + 2009-02-17T17:51:00.0Z + + + + + + + http://www.iana.org/domains/idn-tables/tables/br_pt-br_1.0.html + + + http://registro.br/dominio/regras.html + + + + + + xn--exampl-gva.example + pt-BR + example1.example + withheld + 2005-04-23T11:49:00.0Z + + + + + 1.0 + en + + urn:ietf:params:xml:ns:domain-1.0 + + + urn:ietf:params:xml:ns:contact-1.0 + + + urn:ietf:params:xml:ns:host-1.0 + + + urn:ietf:params:xml:ns:rgp-1.0 + + urn:ietf:params:xml:ns:secDNS-1.1 + + + + + + + + + + + + + + + + + + + + + + + +15. Example of a Differential Deposit Using the XML Model + + The following is an example of a Differential Deposit using the XML + model: + + + + + 2019-10-17T00:00:00Z + + 1.0 + urn:ietf:params:xml:ns:rdeHeader-1.0 + + urn:ietf:params:xml:ns:rdeContact-1.0 + + urn:ietf:params:xml:ns:rdeHost-1.0 + + urn:ietf:params:xml:ns:rdeDomain-1.0 + + urn:ietf:params:xml:ns:rdeRegistrar-1.0 + + urn:ietf:params:xml:ns:rdeIDN-1.0 + + urn:ietf:params:xml:ns:rdeNNDN-1.0 + + urn:ietf:params:xml:ns:rdeEppParams-1.0 + + + + + + + example2.example + + + + + + + + test + 1 + + 1 + + 1 + + 1 + + 1 + + 1 + + 1 + + + + + +16. Example of a Full Deposit Using the CSV Model + + The following is an example of a Full Deposit using the CSV model: + + + + 2019-10-18T00:00:00Z + + 1.0 + urn:ietf:params:xml:ns:csvDomain-1.0 + urn:ietf:params:xml:ns:csvHost-1.0 + urn:ietf:params:xml:ns:csvContact-1.0 + urn:ietf:params:xml:ns:csvRegistrar-1.0 + urn:ietf:params:xml:ns:csvIDN-1.0 + urn:ietf:params:xml:ns:csvNNDN-1.0 + urn:ietf:params:xml:ns:rdeEppParams-1.0 + + + + test + + 4 + + + 6 + + + 9 + + + 3 + + + 2 + + + 2 + + + 1 + + + + + + + + + + + + + + + + + + + + + + domain-YYYYMMDD.csv + + + + + + + + + + + + domainContacts-YYYYMMDD.csv + + + + + + + + + + + + + + domainStatuses-YYYYMMDD.csv + + + + + + + + + + + domainNameServers-name-YYYYMMDD.csv + + + + + + + + + + + domainNameServers-roid-YYYYMMDD.csv + + + + + + + + + + + + + + + dnssec-ds-YYYYMMDD.csv + + + + + + + + + + + + + + + dnssec-key-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + domainTransfer-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + + host-YYYYMMDD.csv + + + + + + + + + + + + + hostStatuses-YYYYMMDD.csv + + + + + + + + + + + + hostAddresses-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + + + + + + contact-YYYYMMDD.csv + + + + + + + + + + + + + contactStatuses-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + contactPostal-YYYYMMDD.csv + + + + + + + + + + + + + + + + + contactTransfer-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + contactDisclose-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + registrar-YYYYMMDD.csv + + + + + + + + + + + + + idnLanguage-YYYYMMDD.csv + + + + + + + + + + + + + + + + + NNDN-YYYYMMDD.csv + + + + + + 1.0 + en + urn:ietf:params:xml:ns:domain-1.0 + + urn:ietf:params:xml:ns:host-1.0 + + urn:ietf:params:xml:ns:contact-1.0 + + + urn:ietf:params:xml:ns:secDNS-1.1 + + urn:ietf:params:xml:ns:rgp-1.0 + + + + + + + + + + + + + + + + + + + + + + + + + + +17. Example of a Differential Deposit Using the CSV Model + + The following is an example of a Differential Deposit using the CSV + model: + + + + 2019-10-18T00:00:00Z + + 1.0 + urn:ietf:params:xml:ns:csvDomain-1.0 + urn:ietf:params:xml:ns:csvHost-1.0 + urn:ietf:params:xml:ns:csvContact-1.0 + urn:ietf:params:xml:ns:csvRegistrar-1.0 + urn:ietf:params:xml:ns:csvIDN-1.0 + + + + + + + + + + domain-delete-YYYYMMDD.csv + + + + + + + + + + + + host-delete-YYYYMMDD.csv + + + + + + + + + + + + contact-delete-YYYYMMDD.csv + + + + + + + + + + + + registrar-delete-YYYYMMDD.csv + + + + + + + + + + + + idnLanguage-delete-YYYYMMDD.csv + + + + + + + + + + + + NNDN-delete-YYYYMMDD.csv + + + + + + + + test + + 2 + + + 2 + + + 3 + + + 1 + + + 1 + + + 1 + + + 1 + + + + + + + + + + + + + + + + + + + + + + domain-YYYYMMDD.csv + + + + + + + + + + + + domainContacts-YYYYMMDD.csv + + + + + + + + + + + + + + domainStatuses-YYYYMMDD.csv + + + + + + + + + + + domainNameServers-name-YYYYMMDD.csv + + + + + + + + + + + domainNameServers-roid-YYYYMMDD.csv + + + + + + + + + + + + + + + dnssec-ds-YYYYMMDD.csv + + + + + + + + + + + + + + + dnssec-key-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + domainTransfer-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + + host-YYYYMMDD.csv + + + + + + + + + + + + + hostStatuses-YYYYMMDD.csv + + + + + + + + + + + + hostAddresses-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + + + + + + contact-YYYYMMDD.csv + + + + + + + + + + + + + contactStatuses-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + contactPostal-YYYYMMDD.csv + + + + + + + + + + + + + + + + + contactTransfer-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + contactDisclose-YYYYMMDD.csv + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + registrar-YYYYMMDD.csv + + + + + + + + + + + + + idnLanguage-YYYYMMDD.csv + + + + + + + + + + + + + + + + + NNDN-YYYYMMDD.csv + + + + + + 1.0 + en + urn:ietf:params:xml:ns:domain-1.0 + + urn:ietf:params:xml:ns:host-1.0 + + urn:ietf:params:xml:ns:contact-1.0 + + + urn:ietf:params:xml:ns:secDNS-1.1 + + urn:ietf:params:xml:ns:rgp-1.0 + + + + + + + + + + + + + + + + + + + + + + + + + + +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, May 2015. + + + + [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, + August 2020. + + [ITU-E164] International Telecommunication Union, "The international + public telecommunication numbering plan", ITU-T + Recommendation E.164, February 2005. + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + DOI 10.17487/RFC0791, September 1981, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, + . + + [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for + the Extensible Provisioning Protocol (EPP)", RFC 3915, + DOI 10.17487/RFC3915, September 2004, + . + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + . + + [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Domain Name Mapping", STD 69, RFC 5731, + DOI 10.17487/RFC5731, August 2009, + . + + [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, + August 2009, . + + [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, + August 2009, . + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + . + + [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) + Security Extensions Mapping for the Extensible + Provisioning Protocol (EPP)", RFC 5910, + DOI 10.17487/RFC5910, May 2010, + . + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, + . + + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, + DOI 10.17487/RFC6234, May 2011, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, + January 2019, . + + [RFC8909] Lozano, G., "Registry Data Escrow Specification", + RFC 8909, DOI 10.17487/RFC8909, November 2020, + . + + [V42] International Telecommunication Union, "V.42 : Error- + correcting procedures for DCEs using asynchronous-to- + synchronous conversion", ITU-T Recommendation V.42, March + 2002, . + + [W3C.REC-xml-20081126] + Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., + and F. Yergeau, "Extensible Markup Language (XML) 1.0 + (Fifth Edition) REC-xml-20081126", W3C Recommendation, + November 2008, + . + + [W3C.REC-xmlschema-1-20041028] + Thompson, H. S., Beech, D., Maloney, M., and N. + Mendelsohn, "XML Schema Part 1: Structures Second Edition + REC-xmlschema-1-20041028", W3C Recommendation, October + 2004, + . + + [W3C.REC-xmlschema-2-20041028] + Biron, P. V. and A. Malhotra, "XML Schema Part 2: + Datatypes Second Edition REC-xmlschema-2-20041028", + W3C Recommendation, October 2004, + . + + [W3C.REC-xpath-31-20170321] + Robie, J., Dyck, M., and J. Spiegel, "XML Path Language + (XPath) 3.1", W3C Recommendation, March 2017, + . + +18.2. Informative References + + [ICANN-GTLD-AGB-20120604] + ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 4 + June 2012, . + + [ICANN-GTLD-RA-20170731] + ICANN, "Base Registry Agreement 2017-07-31", 31 July 2017, + . + + [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", + RFC 1952, DOI 10.17487/RFC1952, May 1996, + . + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + . + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, + DOI 10.17487/RFC3912, September 2004, + . + + [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- + Separated Values (CSV) Files", RFC 4180, + DOI 10.17487/RFC4180, October 2005, + . + + [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the + DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, + . + + [variantTLDsReport] + Internet Corporation for Assigned Names and Numbers + (ICANN), "A Study of Issues Related to the Management of + IDN Variant TLDs", 20 February 2012, + . + +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. + +Authors' Addresses + + Gustavo Lozano + Internet Corporation for Assigned Names and Numbers + Suite 300 + 12025 Waterfront Drive + Los Angeles, CA 90292 + United States of America + + Phone: +1.310.823.9358 + Email: gustavo.lozano@icann.org + + + James Gould + VeriSign, Inc. + 12061 Bluemont Way + Reston, VA 20190 + United States of America + + Email: jgould@verisign.com + + + Chethan Thippeswamy + VeriSign, Inc. + 12061 Bluemont Way + Reston, VA 20190 + United States of America + + Email: cthippeswamy@verisign.com -- cgit v1.2.3