--- 1/draft-ietf-regext-dnrd-objects-mapping-05.txt 2020-02-21 18:13:16.583482933 -0800 +++ 2/draft-ietf-regext-dnrd-objects-mapping-06.txt 2020-02-21 18:13:16.931491749 -0800 @@ -1,20 +1,20 @@ Network Working Group G. Lozano Internet-Draft ICANN Intended status: Standards Track J. Gould -Expires: July 12, 2020 C. Thippeswamy +Expires: August 23, 2020 C. Thippeswamy VeriSign - Jan 09, 2020 + Feb 20, 2020 Domain Name Registration Data (DNRD) Objects Mapping - draft-ietf-regext-dnrd-objects-mapping-05 + draft-ietf-regext-dnrd-objects-mapping-06 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 Internet-Draft is submitted in full conformance with the @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 12, 2020. + This Internet-Draft will expire on August 23, 2020. Copyright Notice Copyright (c) 2020 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 @@ -69,70 +69,71 @@ 5.5. IDN Table Reference Object . . . . . . . . . . . . . . . 70 5.6. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 74 5.7. EPP Parameters Object . . . . . . . . . . . . . . . . . . 79 5.8. Policy Object . . . . . . . . . . . . . . . . . . . . . . 81 5.9. Header Object . . . . . . . . . . . . . . . . . . . . . . 81 6. RDE IDN Variants handling . . . . . . . . . . . . . . . . . . 84 7. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8. Data escrow agent extended verification process . . . . . . . 85 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 86 9.1. RDE CSV Schema . . . . . . . . . . . . . . . . . . . . . 86 - 9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 96 - 9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 99 - 9.4. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 104 - 9.5. CSV Host Object . . . . . . . . . . . . . . . . . . . . . 106 - 9.6. RDE Contact Object . . . . . . . . . . . . . . . . . . . 109 - 9.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 112 - 9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 118 - 9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 122 - 9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 126 - 9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 128 - 9.12. EPP Parameters Object . . . . . . . . . . . . . . . . . . 130 - 9.13. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 132 - 9.14. CSV NNDN Object . . . . . . . . . . . . . . . . . . . . . 134 - 9.15. Policy Object . . . . . . . . . . . . . . . . . . . . . . 137 - 9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 138 - 10. Internationalization Considerations . . . . . . . . . . . . . 140 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140 - 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 146 - 12.1. Implementation in the gTLD space . . . . . . . . . . . . 146 + 9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 95 + 9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 98 + 9.4. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 102 + 9.5. CSV Host Object . . . . . . . . . . . . . . . . . . . . . 103 + 9.6. RDE Contact Object . . . . . . . . . . . . . . . . . . . 106 + 9.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 108 + 9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 114 + 9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 117 + 9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 120 + 9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 121 + 9.12. EPP Parameters Object . . . . . . . . . . . . . . . . . . 123 + 9.13. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 124 + 9.14. CSV NNDN Object . . . . . . . . . . . . . . . . . . . . . 125 + 9.15. Policy Object . . . . . . . . . . . . . . . . . . . . . . 128 + 9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 128 + 10. Internationalization Considerations . . . . . . . . . . . . . 130 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 + 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 135 + 12.1. Implementation in the gTLD space . . . . . . . . . . . . 135 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 147 - 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 147 - 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 147 - 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 148 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 136 + 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 136 + 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 136 + 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 137 16.1. Changes from draft-arias-noguchi-registry-data-escrow-02 - to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 148 - 16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 148 - 16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 149 - 16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 149 - 16.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 149 - 16.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 151 - 16.7. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 151 - 16.8. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 152 - 16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 152 - 16.10. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 152 - 16.11. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 152 - 16.12. Changes from 10 to REGEXT 00 . . . . . . . . . . . . . . 152 - 16.13. Changes REGEXT 00 to REGEXT 01 . . . . . . . . . . . . . 152 - 16.14. Changes REGEXT 01 to REGEXT 02 . . . . . . . . . . . . . 152 - 16.15. Changes REGEXT 02 to REGEXT 03 . . . . . . . . . . . . . 154 - 16.16. Changes REGEXT 03 to REGEXT 04 . . . . . . . . . . . . . 154 - 16.17. Changes REGEXT 04 to REGEXT 05 . . . . . . . . . . . . . 155 - 17. Example of a full deposit using the XML model . . . . . . . . 155 - 18. Example of differential deposit using the XML model . . . . . 161 - 19. Example of a full deposit using the CSV model . . . . . . . . 162 - 20. Example of differential deposit using the CSV model . . . . . 171 - 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 182 - 21.1. Normative References . . . . . . . . . . . . . . . . . . 182 - 21.2. Informative References . . . . . . . . . . . . . . . . . 183 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 184 + to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 137 + 16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 137 + 16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 138 + 16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 138 + 16.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 138 + 16.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 139 + 16.7. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 140 + 16.8. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 140 + 16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 141 + 16.10. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 141 + 16.11. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 141 + 16.12. Changes from 10 to REGEXT 00 . . . . . . . . . . . . . . 141 + 16.13. Changes REGEXT 00 to REGEXT 01 . . . . . . . . . . . . . 141 + 16.14. Changes REGEXT 01 to REGEXT 02 . . . . . . . . . . . . . 141 + 16.15. Changes REGEXT 02 to REGEXT 03 . . . . . . . . . . . . . 143 + 16.16. Changes REGEXT 03 to REGEXT 04 . . . . . . . . . . . . . 143 + 16.17. Changes REGEXT 04 to REGEXT 05 . . . . . . . . . . . . . 144 + 16.18. Changes REGEXT 05 to REGEXT 06 . . . . . . . . . . . . . 144 + 17. Example of a Full Deposit using the XML model . . . . . . . . 144 + 18. Example of Differential Deposit using the XML model . . . . . 150 + 19. Example of a Full Deposit using the CSV model . . . . . . . . 151 + 20. Example of Differential Deposit using the CSV model . . . . . 160 + 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 171 + 21.1. Normative References . . . . . . . . . . . . . . . . . . 171 + 21.2. Informative References . . . . . . . . . . . . . . . . . 173 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 173 1. Introduction 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. 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., @@ -165,22 +166,22 @@ o Contact: Individual or organization social information provisioned in a Domain Name Registry using the EPP contact mapping [RFC5733]. The attributes defined in the EPP contact mapping [RFC5733] are fully supported by this document. o Registrar: The organization that sponsors objects like domains, hosts, and contacts in a Domain Name Registry. o NNDN (NNDN's not domain name): Domain Name Registries may maintain - domain names without them being persisted as domain objects in the - registry system, for example, a list of reserved names not + 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. This document defines the following pseudo-objects: o 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. @@ -238,39 +239,39 @@ 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. REGISTRY. In the context of this draft the definition will be overloaded (from the definition in the base protocol) to indicate an organization providing Registry Services for a REGISTRY-CLASS DOMAIN NAME. REGISTRY-CLASS DOMAIN NAME (RCDN): Refers to a top-level domain (TLD) or any other domain name at any level in the DNS tree for which a - Registry (either directly or through and affiliate company) provides + Registry (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 SERVICES. Services offered by the Registry critical to the following tasks: the provisioning of domain names on receipt of requests and data from registrars; responding to registrar queries for status information relating to the DNS servers for the RCDN; dissemination of RCDN zone files; operation of the Registry DNS - servers; and responding to queries for contact and other information - concerning DNS registrations in the RCDN. Any other products or + 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. + Services are DNS resolution for the RCDN, WHOIS and EPP. ALLOCATED. A status of some label with respect to a zone, whereby the label is associated administratively to some entity that has requested the label. This term (and its cognates "allocation" and - "to allocate") may represents the first step on the way to delegation + "to allocate") may represent the first step on the way to delegation in the DNS. 4. General Conventions 4.1. Date and Time Numerous fields indicate "dates", such as the creation and expiry dates for domain names. These fields SHALL contain timestamps indicating the date and time in UTC as specified in [RFC3339], with no offset from the zero meridian. @@ -285,54 +286,54 @@ 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 0x002B), followed by a country code defined in [ITU-E164], followed by a dot (".", ASCII value 0x002E), followed by a sequence of digits representing the telephone number. 4.4. Checksum - Checksum of the CSV data escrow files MUST use CRC32, that is the - algorithm used in the ISO 3309 standard and in section 8.1.1.6.2 of - ITU-T recommendation V.42. + The checksum of the CSV data escrow files MUST use CRC32, which is + the algorithm used in the ISO 3309 standard and in section 8.1.1.6.2 + of ITU-T recommendation V.42. 4.5. IP addresses - IP addresses syntax MUST conform to the text representation of either - Internet Protocol Version 4 [RFC0791] or Internet Protocol Version 6 - [RFC4291]. + The syntax of IP addresses MUST conform to the text representation of + either Internet Protocol Version 4 [RFC0791] or Internet Protocol + Version 6 [RFC4291]. 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 1-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. + starting from the parent record in Differential and Incremental + Deposits (see [I-D.ietf-regext-data-escrow]). The following is an example of the CSV file definitions 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 + 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. ... @@ -377,21 +378,21 @@ 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 is one or more child elements that substitute for the + 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, with a default value of "false", when set to "true" indicates that the field must be non- empty in the CSV files and when set to "false" 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 @@ -411,25 +412,25 @@ compression If the CSV file is compressed, the "compression" attribute defines the compression format like "gzip" or "zip". encoding Defines the encoding of the CSV file with the default encoding of "UTF-8". cksum Defines the checksum of the CSV file using CRC32, as defined in Section 4.4. This attribute is used to validate that the full CSV file exists and has not been tampered with. - The elements 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 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 following is an example of the element for domain name records where the is set as required with isRequired="true". ... @@ -571,23 +572,23 @@ 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 provided in localized form ("loc"). Those elements use a - field value or "isLoc" attribute to specify the form used. If an - "isLoc" attribute is used, a value of "true" indicates the use of the + ("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. @@ -698,49 +699,49 @@ command, see Section 5.2.1. of [RFC5910]. A element substitutes for the abstract element to define 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: o A element that contains the fully qualified name of the - domain name object. If the domain name is an IDN, the ASCII - Compatible Encoding (ACE) MUST be used. + domain name object. For IDNs the A-Label is used (see [RFC5891], + Section 4.4). o A element that contains the repository object identifier assigned to the domain name object when it was created. - o An OPTIONAL element that contains the fully qualified name - of the domain name in Unicode character set. It MUST be provided - if available. + o An OPTIONAL element that contains the fully qualified + domain name in Unicode character set. It MUST be provided if + available. o 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. o 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. o One or more elements that contain the current status descriptors associated with the domain name. - o Zero or more OPTIONAL element to represent + o 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]. - o An OPTIONAL element that contain the identifier for + o An OPTIONAL element that contains the identifier for the human or organizational social information object associated as the holder of the domain name object. o Zero or more OPTIONAL elements that contain identifiers for the human or organizational social information objects associated with the domain name object. o 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 @@ -794,42 +795,44 @@ * 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 + 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. Example of a domain object: ... - example1.example + xn--exampl-gva.example Dexample1-TEST + pt-BR + example.example jd1234 sh8013 sh8013 ns1.example.com ns1.example1.example RegistrarX RegistrarX @@ -860,21 +863,21 @@ 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 + 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 @@ -995,24 +998,24 @@ 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,2015-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,2015-04-03T22:00:00.0Z - xn--abc123.example,Dxnabc123-TEST,LANG-1,,registrantid,registrarX, + 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,2015-04-03T22:00:00.0Z - xn--abc321.example,Dxnabc321-TEST,LANG-1,xn--abc123.example, + 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,2015-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" @@ -1053,35 +1056,35 @@ domainContacts-YYYYMMDD.csv ... ... 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--abc123.example and xn-- - abc321.example. + 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--abc123.example,xnabc123admin,admin - xn--abc123.example,xnabc123tech,tech - xn--abc123.example,xnabc123billing,billing - xn--abc321.example,xnabc123admin,admin - xn--abc321.example,xnabc123tech,tech - xn--abc321.example,xnabc123billing,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: @@ -1123,29 +1126,29 @@ domainStatuses-YYYYMMDD.csv ... ... Example of the corresponding domainStatuses-YYYYMMDD.csv file. The file contains the statuses for the four domain names domain1.example, - domain2.example, xn--abc123.example and xn--abc321.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--abc123.example,ok,,, - xn--abc321.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]. @@ -1184,31 +1187,32 @@ domainNameServers-YYYYMMDD.csv ... ... 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--abc123.example and - xn--abc321.example referenced via the field element. + 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--abc123.example,Hns1_example_test-TEST - xn--abc123.example,Hns2_example_test-TEST - xn--abc321.example,Hns1_example_test-TEST - xn--abc321.example,Hns2_example_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 host as domain 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: @@ -1254,30 +1258,30 @@ ... ... 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-- - abc123.example and xn--abc321.example. + 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--abc123.example,ns1.example.net,, - xn--abc123.example,ns2.example.net,, - xn--abc321.example,ns1.example.net,, - xn--abc321.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 (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: @@ -1466,21 +1470,21 @@ 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, 2016-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 + 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: @@ -1621,21 +1625,21 @@ ... 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 + 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 a 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). @@ -1865,21 +1869,21 @@ 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 + 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 section CSV common field elements (Section 4.6.2.2), MUST be used in the "host" element: @@ -2027,21 +2031,21 @@ * 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. * An element that contains the identifier of the registrar - that SHOULD act upon a PENDING transfer request. For all other + that should act upon a PENDING transfer request. For all other status types, the value identifies the registrar that took the indicated action. An OPTIONAL client attribute is used to specify the client that performed the operation. * A 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 @@ -2120,21 +2124,21 @@ 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 + 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 @@ -2364,27 +2368,26 @@ "loc"), as defined in Section 4.6.3, of the , , , , , , 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 to used to indicate the localized or internationalized form as defined in section Section 4.6.3. - Contains the contact's contact's street address - line with type="contact:fPostalLineType". An index attribute is - required to indicate which street address line the field - represents with index "0" for the first line and index "2" for the - last line. An OPTIONAL "isLoc" attribute to used to indicate the - localized or internationalized form as defined in section - 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 index "2" for the last line. An + OPTIONAL "isLoc" attribute to used to indicate the localized or + internationalized form as defined in section Section 4.6.3. Contains the contact's city with type="contact:postalLineType" and isRequired="true". An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form as defined in section Section 4.6.3. Contains the contact's country code with type="contact:ccType" and isRequired="true". An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form as defined in section Section 4.6.3. @@ -2632,21 +2635,21 @@ 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 + 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: @@ -2680,22 +2683,22 @@ domain1admin domain1tech domain1billing domain2admin domain2tech domain2billing 5.4. Registrar Object The registrar object represents the sponsoring client for other - objects, for operational purposes MAY be the registry operator. The - registrar object supports both the XML Model and the CSV Model, + 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 , under the element, and the element, under the element. @@ -2716,21 +2719,21 @@ o An element that contains the name of the registrar. o An OPTIONAL element that contains the ID assigned by ICANN. o An OPTIONAL element that contains the operational status of the registrar. Possible values are: ok, readonly and terminated. - o Zero or two OPTIONAL elements that contain postal- + o 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: @@ -2832,21 +2835,21 @@ 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 + 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 @@ -2999,21 +3002,21 @@ 2009-02-17T17:51:00.0Z registrarZ,"Example2 Inc.",1234,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 + 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: @@ -3161,21 +3164,21 @@ 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 + 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: @@ -3204,109 +3207,108 @@ ... Example of the idnLanguage-delete-YYYYMMDD.csv file. The file contains one IDN language record. LANG-2 5.6. NNDN Object - A NNDN (NNDN's not domain name) can be used to store registry + 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 them being + 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 NNDN object, - but not both. + 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 the Models (Section 2) section. 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 , under the element, and the element, under the element. A element substitutes for the - abstract element to define a concrete definition of a NNDN. The + abstract element to define 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: o An element that contains the fully qualified name of the - NNDN. If the NNDN is an IDN, the ASCII Compatible Encoding (ACE) - MUST be used. + NNDN. For IDNs the A-Label is used (see [RFC5891], Section 4.4). o An OPTIONAL element that contains the fully qualified name of the NNDN in Unicode character set. It MUST be provided if available. o 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. o 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. o A element that indicates the state of the NNDN: blocked, withheld or mirrored. - * If a NNDN is considered undesirable for registration (i.e., + * If an NNDN is considered undesirable for registration (i.e., unavailable for allocation to anyone), then the NNDN will be tagged as "blocked". - * If a NNDN is considered a potential registration of a domain + * If an NNDN is considered a potential registration of a domain 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 a NNDN is considered a mirrored IDN variant of a domain + * If an NNDN is considered a mirrored IDN variant of a domain object, then the NNDN will be tagged as "mirrored". A mirroringNS attribute is used to specify if the mirrored IDN variant use the NS mirror mechanism. The default value of mirroringNS is true. If another mechanism such as DNAME is used, the value of mirroringNS attribute MUST be false. o An OPTIONAL element that contains the date and time of the NNDN object creation. - Example of object: + Example of an object: ... xn--exampl-gva.example pt-BR - example1.example + example.example withheld 2005-04-23T11:49:00.0Z ... 5.6.1.2. object - The element contains the ACE of a NNDN that was - deleted, i.e., the . + The element contains the NNDN that was deleted, + i.e., the . - Example of object: + Example of an object: ... ... xn--pingino-q2a.example ... ... @@ -3331,22 +3333,23 @@ 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: - ASCII Compatible Encoding (ACE) field of the NNDN - with type="eppcom:labelType" and isRequired="true". + 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 @@ -3363,21 +3366,21 @@ element: Created date and time of the NNDN object. Name of the NNDN in 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. - Example of a "NNDN" element: + Example of an "NNDN" element: ... ... @@ -3392,42 +3395,42 @@ ... ... 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--abc456.example,LANG-1,xn--abc123.example, + xn--bc456-3ve.example,LANG-1,xn--bc123-3ve.example, blocked,,2005-04-23T11:49:00.0Z - xn--abc789.example,LANG-1,xn--abc123.example, + 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 + 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: - ASCII Compatible Encoding (ACE) field of the NNDN - with type="eppcom:labelType" and isRequired="true". + Fully qualified name of the NNDN with + type="eppcom:labelType" and isRequired="true". - Example of a "NNDN" element. + Example of an "NNDN" element. ... ... ... ... Example of the corresponding NNDN-delete-YYYYMMDD.csv file. The file contains one NNDN records. - xn--abc456.example + 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 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. Only one EPP Parameters Object MUST exist at @@ -3536,82 +3539,82 @@ ... ... 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 - (watermark) regardless of the type of deposit: differential, full or - incremental. The Header Object may also be used to provide + (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 XML Model or CSV Model. The Header Object is defined using the element. 5.9.1. object The contains the following elements: o 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: * A element that defines TLD or the REGISTRY- CLASS DOMAIN NAME (RCDN) being escrowed in the case of a Registry data escrow deposit. For IDNs the A-Label is used - [RFC5891]. + (see [RFC5891], Section 4.4). * A 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. * A element that defines the provider ID corresponding to a Privacy and Proxy Services Provider data escrow deposit. In the case of an ICANN-accredited Privacy and Proxy Services Provider, the element MUST be the unique ID assigned by ICANN. * A element that defines the provider ID corresponding to a Reseller data escrow deposit. o A element that contains the number of objects in the SRS at a specific point in time (watermark) regardless of the type of - deposit: differential, full or incremental. The element + 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 REGISTRY-CLASS DOMAIN NAME (RCDN) of the objects included in the - element. For IDNs the A-Label is used [RFC5891]. 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). + 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. o 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. @@ -3661,152 +3664,121 @@ 1 1 ... 6. RDE IDN Variants handling - Depending on the Registration Policy of the Registry; for a domain + Depending on the Registration Policy of the Registry, for a domain name there may be multiple variant names. See [variantTLDsReport] for further detail on IDN variants. A registry could choose to escrow IDN variants as domains or NNDN objects. A specific IDN variant can be represented in the escrow - deposit, as a domain or as a NNDN object, but not both. + 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 a 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. + 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. - A NNDN or a domain name are explicit representations of an IDN + An NNDN or a domain name are explicit representations of an IDN variant while an IDN variant computed based on an algorithm is an implicit representation. Explicit representation of an IDN variant takes precedence over an implicit representation. 7. Profile Different business models of registries exist, therefore the registry - is responsible to define a profile that matches its particular + 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: 1. Extending base objects with the mechanisms defined for XML and CSV models. * In the case of the XML model, abstract elements could be use to extend the following objects: , , , and using XML schema substitution groups feature. 2. Defining a object to specify which OPTIONAL elements of this base specification is 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 existing business models. + 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. - o If a full deposit is to be tested, the full deposit is the + o If a Full Deposit is to be tested, the Full Deposit is the dataset. - o If an incremental deposit is to be tested, the dataset is created - by using the incremental plus the last previous full deposit. + o If an Incremental Deposit is to be tested, the dataset is created + by using the Incremental Deposit plus the last previous Full + Deposit. - o If a differential deposit is to be tested, the dataset is created - by using the differential deposit plus all the required deposits - leading to the last previous full deposit. + o If a Differential Deposit is to be tested, the dataset is created + by using the Differential Deposit plus all the required deposits + leading to the last previous Full Deposit. The following are the minimum suggested tests on the dataset: o Validate the escrow deposits using the definition agreed with the registry. * In the case of the XML model, the contents of the escrow deposits MUST be validated using the XML schemas of the profile. o Count the objects and validate that the number of objects is equal to the number objects reported in the
element of the escrow deposit of that point in time (watermark). o All contact objects linked to domain names MUST be present. o All registrars objects linked to other objects MUST be present. - o A domain name exists as a domain name or NNDN, but not both. + o No domain name exists as both a domain name and an NNDN. o The elements listed as required in the element MUST be present. o All idnTableRef definitions linked from other objects MUST be present. o If an EPP Parameters Object was escrowed in the past, one and only one EPP Parameters Object MUST be present. o The watermark is not in the future. 9. Formal Syntax Schemas are presented here. 9.1. RDE CSV Schema - Copyright (c) 2012 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -4218,52 +4194,20 @@ END 9.2. RDE Domain Object - Copyright (c) 2019 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN + END 9.3. CSV Domain Object - Copyright (c) 2012 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN - END 9.4. RDE Host Object - Copyright (c) 2019 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -4698,54 +4579,23 @@ type="eppcom:roidType"/> END 9.5. CSV Host Object - Copyright (c) 2012 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN + END 9.6. RDE Contact Object - Copyright (c) 2019 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -4964,60 +4784,29 @@ + END 9.7. CSV Contact Object - Copyright (c) 2012 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN END 9.8. RDE Registrar Object - Copyright (c) 2019 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -5488,52 +5247,20 @@ maxOccurs="unbounded"/> END 9.9. CSV Registrar Object - Copyright (c) 2012 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN END 9.10. RDE IDN Table Reference Objects - Copyright (c) 2019 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -5745,52 +5442,20 @@ END 9.11. CSV IDN Language Object - Copyright (c) 2012 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -5835,58 +5500,27 @@ END 9.12. EPP Parameters Object - Copyright (c) 2019 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -5925,52 +5559,20 @@ type="epp:dcpType"/> END 9.13. NNDN Object - Copyright (c) 2019 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -6039,52 +5641,20 @@ maxOccurs="unbounded"/> END 9.14. CSV NNDN Object - Copyright (c) 2013 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -6160,60 +5731,29 @@ + END 9.15. Policy Object - Copyright (c) 2019 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -6231,52 +5771,20 @@ END 9.16. Header Object - Copyright (c) 2019 IETF Trust and the persons identified as authors - of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - o Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - o Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - o Neither the name of Internet Society, IETF or IETF Trust, nor the - names of specific contributors, may be used to endorse or promote - products derived from this software without specific prior written - permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - BEGIN @@ -6343,265 +5851,239 @@ 11. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Fourteen URI assignments have been registered by the IANA. Registration request for the RDE CSV namespace: URI: urn:ietf:params:xml:ns:rdeCsv-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE CSV XML schema: URI: urn:ietf:params:xml:schema:rdeCsv-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.1 of this document. Registration request for the RDE domain namespace: URI: urn:ietf:params:xml:ns:rdeDomain-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE domain XML schema: URI: urn:ietf:params:xml:schema:rdeDomain-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.2 of this document. Registration request for the CSV domain namespace: URI: urn:ietf:params:xml:ns:csvDomain-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the CSV domain XML schema: URI: urn:ietf:params:xml:schema:csvDomain-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.3 of this document. Registration request for the RDE host namespace: URI: urn:ietf:params:xml:ns:rdeHost-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE host XML schema: URI: urn:ietf:params:xml:schema:rdeHost-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.4 of this document. Registration request for the CSV host namespace: URI: urn:ietf:params:xml:ns:csvHost-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the CSV host XML schema: URI: urn:ietf:params:xml:schema:csvHost-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.5 of this document. Registration request for the RDE contact namespace: URI: urn:ietf:params:xml:ns:rdeContact-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE contact XML schema: URI: urn:ietf:params:xml:schema:rdeContact-1.0 - Registrant Contact: See the "Author's Address" section of this - document. - See the "Formal Syntax" section of this document. + Registrant Contact: IETF + + See section Section 9.6 of this document. Registration request for the CSV contact namespace: URI: urn:ietf:params:xml:ns:csvContact-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the CSV contact XML schema: URI: urn:ietf:params:xml:schema:csvContact-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.7 of this document. Registration request for the RDE registrar namespace: URI: urn:ietf:params:xml:ns:rdeRegistrar-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE registrar XML schema: URI: urn:ietf:params:xml:schema:rdeRegistrar-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.8 of this document. Registration request for the CSV registrar namespace: URI: urn:ietf:params:xml:ns:csvRegistrar-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the CSV registrar XML schema: URI: urn:ietf:params:xml:schema:csvRegistrar-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.9 of this document. Registration request for the RDE IDN namespace: URI: urn:ietf:params:xml:ns:rdeIDN-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE IDN XML schema: URI: urn:ietf:params:xml:schema:rdeIDN-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.10 of this document. Registration request for the CSV IDN namespace: URI: urn:ietf:params:xml:ns:csvIDN-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the CSV IDN XML schema: URI: urn:ietf:params:xml:schema:csvIDN-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.11 of this document. Registration request for the RDE NNDN namespace: URI: urn:ietf:params:xml:ns:rdeNNDN-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE NNDN XML schema: URI: urn:ietf:params:xml:schema:rdeNNDN-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.13 of this document. Registration request for the CSV NNDN namespace: URI: urn:ietf:params:xml:ns:csvNNDN-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the CSV NNDN XML schema: URI: urn:ietf:params:xml:schema:csvNNDN-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF - See the "Formal Syntax" section of this document. + See section Section 9.14 of this document. Registration request for the RDE EPP parameters namespace: URI: urn:ietf:params:xml:ns:rdeEppParams-1.0 - Registrant Contact: See the "Author's Address" section of this - document. + Registrant Contact: IETF XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE EPP parameters XML schema: URI: urn:ietf:params:xml:schema:rdeEppParams-1.0 - Registrant Contact: See the "Author's Address" section of this - document. - See the "Formal Syntax" section of this document. + Registrant Contact: IETF + + See section Section 9.12 of this document. 12. Implementation Status Note to RFC Editor: Please remove this section and the reference to RFC 7942 [RFC7942] before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942 [RFC7942]. The description of implementations in this section is @@ -6649,38 +6130,39 @@ agreements-en 13. Security Considerations This specification does not define the security mechanisms to be used in the transmission of the data escrow deposits, since it only specifies the minimum necessary to enable the rebuilding of a Registry from deposits without intervention from the original Registry. - Depending on local policies, some elements or most likely, the whole - deposit will be considered confidential. As such the Registry - transmitting the data to the Escrow Agent SHOULD take all the - necessary precautions like encrypting the data itself and/or the + Depending on local policies, some elements or, most likely, the whole + deposit will be considered confidential. As such, the Registry + transmitting the data to the Escrow Agent should take all the + necessary precautions such as encrypting the data itself and/or the transport channel to avoid inadvertent disclosure of private data. - It is also of the utmost importance the authentication of the parties - passing data escrow deposit files. The Escrow Agent SHOULD properly + Authentication of the parties passing data escrow deposit files is + also of the utmost importance. The Escrow Agent SHOULD properly authenticate the identity of the Registry before accepting data escrow deposits. In a similar manner, the Registry SHOULD authenticate the identity of the Escrow Agent before submitting any data. Additionally, the Registry and the Escrow Agent SHOULD use integrity checking mechanisms to ensure the data transmitted is what the source intended. Validation of the contents by the Escrow Agent is - RECOMMENDED to ensure not only the file was transmitted correctly - from the Registry, but also the contents are also "meaningful". + RECOMMENDED to ensure not only that the file was transmitted + correctly from the Registry, but also that the contents are + "meaningful". 14. 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 agreed by the parties, and such legal document must regulate the particularities regarding the protection of personal data. 15. Acknowledgments @@ -7044,23 +6526,29 @@ 2. The example in idnLanguage CSV file definition updated to use the sep attribute. 3. The reference in the example in hostAddresses CSV file definition was updated. 4. Moved [RFC0791] and [RFC4291] to the Normative References section. -17. Example of a full deposit using the XML model +16.18. Changes REGEXT 05 to REGEXT 06 - Example of a full deposit using the XML model: + 1. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/ + nA8eTYIrXJ44_6ullQlRLW6T74s + +17. Example of a Full Deposit using the XML model + + Example of a Full Deposit using the XML model: -18. Example of differential deposit using the XML model +18. Example of Differential Deposit using the XML model - Example of a differential deposit using the XML model: + Example of a Differential Deposit using the XML model: 1 1 -19. Example of a full deposit using the CSV model +19. Example of a Full Deposit using the CSV model - Example of a full deposit using the CSV model: + Example of a Full Deposit using the CSV model: -20. Example of differential deposit using the CSV model +20. Example of Differential Deposit using the CSV model - Example of a differential deposit using the CSV model: + Example of a Differential Deposit using the CSV model: . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 21.2. Informative References [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, . - [RFC5891] Klensin, J., "Internationalized Domain Names in - Applications (IDNA): Protocol", RFC 5891, - DOI 10.17487/RFC5891, August 2010, - . - [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [variantTLDsReport] Internet Corporation for Assigned Names and Numbers (ICANN), "A Study of Issues Related to the Management of IDN Variant TLDs", February 2012,