This section describes the base objects supported by this specification:
The domain name object is based on the EPP domain name mapping specified in [
RFC 5731]. The domain name 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.
There are two elements used in the data escrow of the domain name objects for the XML model, including the <rdeDomain:domain> element, under the <rde:contents> element, and the <rdeDomain:delete> element, under the <rde:deletes> element.
The domain element is based on the EPP domain <info> response for an authorized client (see
Section 3.1.2 of
RFC 5731) with additional data from an EPP <transfer> query response, see
Section 3.1.3 of
RFC 5731, Registry Grace Period (RGP) status from [
RFC 3915], and data from the EPP <secDNS:create> command, see
Section 5.2.1 of
RFC 5910.
A <domain> element substitutes for the <abstractDomain> abstract element to create a concrete definition of a domain. The <abstractDomain> element can be replaced by other domain definitions using the XML schema substitution groups feature.
The <domain> element contains the following child elements:
-
A <name> element that contains the fully qualified name of the domain name object. For IDNs, the A-label is used (see RFC 5891, Section 4.4).
-
A <roid> element that contains the ROID assigned to the domain name object when it was created.
-
An OPTIONAL <uName> element that contains the FQDN in the Unicode character set. It MUST be provided if available.
-
An OPTIONAL <idnTableId> element that references the IDN table used for the IDN. This corresponds to the "id" attribute of the <idnTableRef> element. This element MUST be present if the domain name is an IDN.
-
An OPTIONAL <originalName> element is used to indicate that the domain name is an IDN variant. This element contains the domain name used to generate the IDN variant.
-
One or more <status> elements that contain the current status descriptors associated with the domain name.
-
Zero or more OPTIONAL <rgpStatus> 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 [RFC 3915].
-
An OPTIONAL <registrant> element that contains the identifier for the human or the organizational social information object associated with the holder of the domain name object.
-
Zero or more OPTIONAL <contact> elements that contain identifiers for the human or organizational social information objects associated with the domain name object.
-
An OPTIONAL <ns> element that contains the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain name object. See Section 1.1 of RFC 5731 for a description of the elements used to specify host objects or host attributes.
-
A <clID> element that contains the identifier of the sponsoring registrar.
-
An OPTIONAL <crRr> element that contains the identifier of the registrar that created the domain name object. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
An OPTIONAL <crDate> element that contains the date and time of the domain name object creation. This element MUST be present if the domain name has been allocated.
-
An OPTIONAL <exDate> element that contains the date and time identifying the end (expiration) of the domain name object's registration period. This element MUST be present if the domain name has been allocated.
-
An OPTIONAL <upRr> element that contains the identifier of the registrar that last updated the domain name object. This element MUST NOT be present if the domain has never been modified. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
An OPTIONAL <upDate> element that contains the date and time of the most recent modification of the domain name object. This element MUST NOT be present if the domain name object has never been modified.
-
An OPTIONAL <secDNS> element that contains the public key information associated with Domain Name System security (DNSSEC) extensions for the domain name as specified in [RFC 5910].
-
An OPTIONAL <trDate> element that contains the date and time of the most recent successful transfer of a domain name object. This element MUST NOT be present if the domain name object has never been transferred.
-
An OPTIONAL <trnData> element that contains the following child elements related to the last transfer request of the domain name object. This element MUST NOT be present if a transfer request for the domain name has never been created.
-
A <trStatus> element that contains the state of the most recent transfer request.
-
A <reRr> element that contains the identifier of the registrar that requested the domain name object transfer. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
A <reDate> element that contains the date and time that the transfer was requested.
-
An <acRr> element that contains the identifier of the registrar that should act upon a pending transfer request. For all other status types, the value identifies the registrar that took the indicated action. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
An <acDate> element that contains the date and time of a required or completed response. For a pending request, the value identifies the date and time by which a response is required before an automated response action will be taken by the registry. For all other status types, the value identifies the date and time when the request was completed.
-
An OPTIONAL <exDate> element that contains the end of the domain name object's validity period (expiry date) if the transfer caused or causes a change in the validity period.
The following is an example of a domain name object:
...
<rdeDomain:domain>
<rdeDomain:name>xn--exampl-gva.example</rdeDomain:name>
<rdeDomain:roid>Dexample1-TEST</rdeDomain:roid>
<rdeDomain:idnTableId>pt-BR</rdeDomain:idnTableId>
<rdeDomain:originalName>example.example</rdeDomain:originalName>
<rdeDomain:status s="ok"/>
<rdeDomain:registrant>jd1234</rdeDomain:registrant>
<rdeDomain:contact type="admin">sh8013</rdeDomain:contact>
<rdeDomain:contact type="tech">sh8013</rdeDomain:contact>
<rdeDomain:ns>
<domain:hostObj>ns1.example.com</domain:hostObj>
<domain:hostObj>ns1.example1.example</domain:hostObj>
</rdeDomain:ns>
<rdeDomain:clID>RegistrarX</rdeDomain:clID>
<rdeDomain:crRr client="jdoe">RegistrarX</rdeDomain:crRr>
<rdeDomain:crDate>1999-04-03T22:00:00.0Z</rdeDomain:crDate>
<rdeDomain:exDate>2025-04-03T22:00:00.0Z</rdeDomain:exDate>
</rdeDomain:domain>
...
The <rdeDomain:delete> element contains the FQDN that was deleted and purged.
The following is an example of an <rdeDomain:delete> object:
...
<rde:deletes>
...
<rdeDomain:delete>
<rdeDomain:name>foo.example</rdeDomain:name>
<rdeDomain:name>bar.example</rdeDomain:name>
</rdeDomain:delete>
...
</rde:deletes>
...
For the CSV model of the domain name object, the <csvDomain:contents> child element of the <rde:contents> element is used to hold the new or updated domain name objects for the deposit. The <csvDomain:deletes> child element of the <rde:deletes> element is used to hold the deleted or purged domain name objects for the deposit. Both the <csvDomain:contents> and <csvDomain:deletes> elements contain one or more <rdeCsv:csv> elements with a set of named CSV file definitions using the <rdeCsv:csv> "name" attribute.
Differential and Incremental Deposits are based on changes to the domain name objects. The updated domain name object data under the <csvDomain:contents> element is a cascade replace down all of the domain name CSV files starting with the parent
Section 5.1.2.1.1. The child CSV file definitions include a <csvDomain:fName parent="true"> field. All the child CSV file definition data for the domain name objects in the parent
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 <csvDomain:deletes> element is a cascade delete starting from the
Section 5.1.2.2.1.
The <csvDomain:contents> is used to hold the new or updated domain name object information for the deposit. The <csvDomain:contents> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following sections include the supported domain name CSV file definitions.
The "domain" CSV File Definition defines the fields and CSV file references used for the parent domain name object records. All the other domain name CSV file definitions are child CSV files based on the inclusion of the <csvDomain:fName parent="true"> field.
The following "csvDomain" field elements
MUST be used in the "domain" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fName>
-
Domain name field with type="eppcom:labelType" and isRequired="true".
The following "csvDomain" field elements
MAY be used in the "domain" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fOriginalName>
-
Fully qualified name of the original IDN domain name object related to the variant domain name object with type="eppcom:labelType".
The following "rdeCsv" and "csvRegistrar" fields,
MUST be used in the "domain" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fRoid>
-
ROID for the domain name object with isRequired="true".
-
<rdeCsv:fClID> or <csvRegistrar:fGurid>
-
A choice of the following:
-
<rdeCsv:fClID>
-
Identifier of the sponsoring client with isRequired="true".
-
<csvRegistrar:fGurid>
-
Contains the Globally Unique Registrar Identifier (GURID) assigned by ICANN with type="positiveInteger" and isRequired="true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MAY be used in the "domain" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fCrRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that created the domain name object.
-
<rdeCsv:fCrID>
-
Identifier of the client that created the domain name object.
-
<rdeCsv:fUpRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that last updated the domain name object.
-
<rdeCsv:fUpID>
-
Identifier of the client that last updated the domain name object.
-
<rdeCsv:fUName>
-
UTF-8 encoded domain name for the <csvDomain:fName> field element.
-
<rdeCsv:fIdnTableId>
-
IDN table identifier used for the IDN domain name object that MUST match an <rdeCsv:fIdnTableId> field element in the "idnLanguage" CSV files, as defined in Section 5.5.2.
-
<rdeCsv:fRegistrant>
-
Registrant contact identifier for the domain name object.
-
<rdeCsv:fCrDate>
-
Date and time of the domain name object creation.
-
<rdeCsv:fUpDate>
-
Date and time of the last update to the domain name object. This field MUST NOT be set if the domain name object has never been modified.
-
<rdeCsv:fExDate>
-
Expiration date and time for the domain name object.
-
<rdeCsv:fTrDate>
-
Date and time of the last transfer for the domain name object. This field MUST NOT be set if the domain name object has never been transferred.
The following is an example of a "domain" <csvDomain:contents> <rdeCsv:csv> element.
...
<csvDomain:contents>
...
<rdeCsv:csv name="domain">
<rdeCsv:fields>
<csvDomain:fName/>
<rdeCsv:fRoid/>
<rdeCsv:fIdnTableId/>
<csvDomain:fOriginalName/>
<rdeCsv:fRegistrant/>
<rdeCsv:fClID/>
<rdeCsv:fCrRr/>
<rdeCsv:fCrID/>
<rdeCsv:fCrDate/>
<rdeCsv:fUpRr/>
<rdeCsv:fUpID/>
<rdeCsv:fUpDate/>
<rdeCsv:fExDate isRequired="true"/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="5E403BD6">
domain-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvDomain:contents>
...
The following is an example of the corresponding domain-YYYYMMDD.csv file. The file contains four records (two active ASCII domains, original IDN with LANG-1 language rules, and variant IDN with LANG-1 language rules).
domain1.example,Ddomain1-TEST,,,registrantid,registrarX,registrarX,
clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,
2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z
domain2.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX,
clientY,1999-04-03T22:00:00.0Z,registrarX,clientY,
2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z
xn--bc123-3ve.example,Dxnabc123-TEST,LANG-1,,registrantid,registrarX,
registrarX,clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,
2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z
xn--bc321-3ve.example,Dxnabc321-TEST,LANG-1,xn--bc123-3ve.example,
registrantid,registrarX,registrarX,clientY,2009-04-03T22:00:00.0Z,
registrarX,clientY,2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z
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
Section 5.3.
The following "csvDomain" field elements, defined for the
Section 5.1.2.1.1,
MUST be used in the "domainContacts" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fName>
-
The name of the domain object that is linked to the contact object with isRequired="true".
-
<csvDomain:fContactType>
-
The contact type for the contact object link with type="domain:contactAttrType" and isRequired="true". The supported contact type values include "admin" for the administration contact, "billing" for the billing contact, and "tech" for the technical contact.
The following "csvContact" fields, defined for the
Section 5.3.2.1.1,
MUST be used in the "domainContacts" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fId>
-
The server-unique contact identifier with isRequired="true".
The following is an example of a "domainContacts" <csvDomain:contents> <rdeCsv:csv> element:
...
<csvDomain:contents>
...
<rdeCsv:csv name="domainContacts">
<rdeCsv:fields>
<csvDomain:fName parent="true"/>
<csvContact:fId/>
<csvDomain:fContactType/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="6B976A6C">
domainContacts-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvDomain:contents>
...
The following is an example of the corresponding domainContacts-YYYYMMDD.csv file. The file contains an admin, tech, and billing contact for the four domain names domain1.example, domain2.example, xn--bc123-3ve.example, and xn--bc321-3ve.example:
domain1.example,domain1admin,admin
domain1.example,domain1tech,tech
domain1.example,domain1billing,billing
domain2.example,domain2admin,admin
domain2.example,domain2tech,tech
domain2.example,domain2billing,billing
xn--bc123-3ve.example,xnabc123admin,admin
xn--bc123-3ve.example,xnabc123tech,tech
xn--bc123-3ve.example,xnabc123billing,billing
xn--bc321-3ve.example,xnabc123admin,admin
xn--bc321-3ve.example,xnabc123tech,tech
xn--bc321-3ve.example,xnabc123billing,billing
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
Section 5.1.2.1.1,
MUST be used in the "domainStatuses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fName>
-
Domain name of status with isRequired="true".
-
<csvDomain:fStatus>
-
The status of the domain name with type="domain:statusValueType" and isRequired="true".
-
<csvDomain:fRgpStatus>
-
The RGP status, as a sub-status of the <csvDomain:fStatus> "pendingDelete" status value, with type="rgp:statusValueType" as defined in [RFC 3915].
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MAY be used in the "domainStatuses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fStatusDescription>
-
Domain name object status description, which is free-form text describing the rationale for the status.
-
<rdeCsv:fLang>
-
Language of the <rdeCsv:fStatusDescription> field.
The following is an example of a "domainStatuses" <csvDomain:contents> <rdeCsv:csv> element:
...
<csvDomain:contents>
...
<rdeCsv:csv name="domainStatuses">
<rdeCsv:fields>
<csvDomain:fName parent="true"/>
<csvDomain:fStatus/>
<rdeCsv:fStatusDescription/>
<rdeCsv:fLang/>
<csvDomain:fRgpStatus/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="98D139A3">
domainStatuses-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvDomain:contents>
...
The following is an example of the corresponding domainStatuses-YYYYMMDD.csv file. The file contains the statuses for the four domain names domain1.example, domain2.example, xn--bc123-3ve.example, and xn--bc321-3ve.example:
domain1.example,clientUpdateProhibited,"Disallow update",
en,
domain1.example,clientDeleteProhibited,"Disallow delete",
en,
domain2.example,ok,,,
xn--bc123-3ve.example,ok,,,
xn--bc321-3ve.example,ok,,,
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 <domain:hostObj> model, defined in [
RFC 5731].
The following "csvDomain" fields, defined for the
Section 5.1.2.1.1,
MUST be used in the "domainNameServers" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fName>
-
Domain name using the delegated host with isRequired="true".
The following "csvHost" and "rdeCsv" field elements
MUST be used in the "domainNameServers" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvHost:fName> or <rdeCsv:fRoid>
-
A choice of the following:
-
<csvHost:fName>
-
Host name field with type="eppcom:labelType" and isRequired="true".
-
<rdeCsv:fRoid>
-
Host object ROID assigned to the host object with isRequired="true".
The following is an example of a "domainNameServers" <csvDomain:contents> <rdeCsv:csv> element:
...
<csvDomain:contents>
...
<rdeCsv:csv name="domainNameServers">
<rdeCsv:fields>
<csvDomain:fName parent="true"/>
<rdeCsv:fRoid/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="8FE6E9E1">
domainNameServers-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvDomain:contents>
...
The following is an example of the corresponding domainNameServers-YYYYMMDD.csv file. The file contains the delegated hosts (name servers) for the four domain names domain1.example, domain2.example, xn--bc123-3ve.example, and xn--bc321-3ve.example referenced via the <rdeCsv:fRoid> field element:
domain1.example,Hns1_domain1_test-TEST
domain1.example,Hns2_domain1_test-TEST
domain2.example,Hns1_domain2_test-TEST
domain2.example,Hns2_domain2_test-TEST
xn--bc123-3ve.example,Hns1_example_test-TEST
xn--bc123-3ve.example,Hns2_example_test-TEST
xn--bc321-3ve.example,Hns1_example_test-TEST
xn--bc321-3ve.example,Hns2_example_test-TEST
The "domainNameServersAddresses" CSV File Definition defines the fields and CSV file references used for supporting the domain host attributes model.
The following "csvDomain" fields, defined for the
Section 5.1.2.1.1,
MUST be used in the "domainNameServersAddresses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fName>
-
Domain name using the delegated host with host <csvHost:fName> and isRequired="true".
The following "rdeCsv" fields, defined in
Section 5.2.2,
MUST be used in the "domainNameServersAddresses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvHost:fName>
-
Host name field with type="eppcom:labelType" and isRequired="true".
The following "csvHost" fields, defined in
Section 5.2.2,
MAY be used in the "domainNameServersAddresses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvHost:fAddr>
-
IP addresses associated with the host object with type="host:addrStringType".
-
<csvHost:fAddrVersion>
-
IP addresses version associated with the host object with type="host:ipType". "host:ipType" has the enumerated values of "v4" or "v6".
The following is an example of a "domainNameServersAddresses" <csvDomain:contents> <rdeCsv:csv> element:
...
<csvDomain:contents>
...
<rdeCsv:csv name="domainNameServersAddresses">
<rdeCsv:fields>
<csvDomain:fName parent="true"/>
<csvHost:fName/>
<csvHost:fAddr/>
<csvHost:fAddrVersion/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="D3B77438">
domainNameServersAddresses-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvDomain:contents>
...
The following is an example of the corresponding domainNameServersAddresses-YYYYMMDD.csv file. The file contains the delegated hosts (name servers) for the four domain names domain1.example, domain2.example, xn--bc123-3ve.example, and xn--bc321-3ve.example:
domain1.example,ns1.domain1.example,192.0.2.1,v4
domain1.example,ns2.domain1.example,2001:DB8::1,v6
domain2.example,ns1.example.net,,
domain2.example,ns2.example.net,,
xn--bc123-3ve.example,ns1.example.net,,
xn--bc123-3ve.example,ns2.example.net,,
xn--bc321-3ve.example,ns1.example.net,,
xn--bc321-3ve.example,ns2.example.net,,
The "dnssec" CSV File Definition defines the fields and CSV file references used for the domain name object DNSSEC records (Delegation Signer (DS) or key data).
The following "csvDomain" field elements
MUST be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element when the DS Data Interface per [
RFC 5910] is used:
-
<csvDomain:fKeyTag>
-
Contains the DS key tag value per [RFC 5910] with type="unsignedShort" and isRequired="true".
-
<csvDomain:fDsAlg>
-
Contains the DS algorithm value per [RFC 5910] with type="unsignedByte" and isRequired="true".
-
<csvDomain:fDigestType>
-
Contains the DS digest type value per [RFC 5910] with type="unsignedByte" and isRequired="true".
-
<csvDomain:fDigest>
-
Contains the DS digest value per [RFC 5910] with type="hexBinary" and isRequired="true".
The following "csvDomain" field elements
MUST be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element when the Key Data Interface per [
RFC 5910] is used and
MAY be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element when the DS Data Interface per [
RFC 5910] is used:
-
<csvDomain:fFlags>
-
Contains the flags field value per [RFC 5910] with type="unsignedShort" and isRequired="true".
-
<csvDomain:fProtocol>
-
Contains the key protocol value per [RFC 5910] with type="unsignedByte" and isRequired="true".
-
<csvDomain:fKeyAlg>
-
Contains the key algorithm value per [RFC 5910] with type="unsignedByte" and isRequired="true".
-
<csvDomain:fPubKey>
-
Contains the public key value per [RFC 5910] with type="secDNS:keyType" and isRequired="true".
The following "csvDomain" field elements
MAY be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fMaxSigLife>
-
Indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire with type="secDNS:maxSigLifeType" defined in [RFC 5910].
The following "domain" fields, defined for the
Section 5.1.2.1.1,
MUST be used in the "dnssec" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fName>
-
Domain name of the domain name object associated with the DNSSEC record and isRequired="true".
The following is an example of a "dnssec" <csvDomain:contents> <rdeCsv:csv> element with the DS Data Interface of [
RFC 5910]:
<csvDomain:contents>
...
<rdeCsv:csv name="dnssec">
<rdeCsv:fields>
<csvDomain:fName parent="true"/>
<csvDomain:fMaxSigLife/>
<csvDomain:fKeyTag/>
<csvDomain:fDsAlg/>
<csvDomain:fDigestType/>
<csvDomain:fDigest/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="10ED6C42">
dnssec-ds-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvDomain:contents>
...
The following is an example of the corresponding dnssec-ds-YYYYMMDD.csv file. The file contains two DS records for domain1.example:
domain1.example,604800,30730,8,2,91C9B176EB////F1C46F6A55
domain1.example,604800,61882,8,2,9F8FEAC94B////1272AF09F3
The following is an example of a "dnssec" <csvDomain:contents> <rdeCsv:csv> element with the Key Data Interface of [
RFC 5910]:
<csvDomain:contents>
...
<rdeCsv:csv name="dnssec">
<rdeCsv:fields>
<csvDomain:fName parent="true"/>
<csvDomain:fMaxSigLife/>
<csvDomain:fFlags/>
<csvDomain:fProtocol/>
<csvDomain:fKeyAlg/>
<csvDomain:fPubKey/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="183C3F79">
dnssec-key-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvDomain:contents>
...
The following is an example of the corresponding dnssec-key-YYYYMMDD.csv file. The file contains two key records for domain1.example:
domain1.example,604800,257,3,8,AwEAAZD1+z////G1jqviK8c=
domain1.example,604800,257,3,8,AwEAAbntWP////vwDitt940=
The "domainTransfer" CSV File Definition defines the fields and CSV file references used for the domain name object pending and completed transfer records. No additional field elements were added for use in the "domainTransfer" <rdeCsv:csv> <rdeCsv:fields> element.
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MUST be used in the "domainTransfer" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fTrStatus>
-
State of the most recent transfer request with isRequired="true".
-
<rdeCsv:fReRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that requested the transfer with isRequired="true".
-
<rdeCsv:fReDate>
-
Date and time that the transfer was requested with isRequired="true".
-
<rdeCsv:fAcRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that should take or took action with isRequired="true".
-
<rdeCsv:fAcDate>
-
Date and time that the transfer action should be taken or has been taken with isRequired="true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MAY be used in the "domainTransfer" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fExDate>
-
Expiration date if the transfer command caused or causes a change in the validity period.
-
<rdeCsv:fReID>
-
Identifier of the client that requested the transfer.
-
<rdeCsv:fAcID>
-
Identifier of the client that should take or took action for transfer.
The following "csvDomain" fields, defined for the
Section 5.1.2.1.1,
MUST be used in the "domainTransfer" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fName>
-
Domain name of the domain name object involved in the transfer with isRequired="true".
The following is an example of a "domainTransfer" <csvDomain:contents> <rdeCsv:csv> element:
...
<csvDomain:contents>
...
<rdeCsv:csv name="domainTransfer">
<rdeCsv:fields>
<csvDomain:fName parent="true"/>
<rdeCsv:fTrStatus/>
<rdeCsv:fReRr/>
<rdeCsv:fReID/>
<rdeCsv:fReDate/>
<rdeCsv:fAcRr/>
<rdeCsv:fAcID/>
<rdeCsv:fAcDate/>
<rdeCsv:fExDate/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="2E5A9ACD">
domainTransfer-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvDomain:contents>
...
The following is an example of the corresponding domainTransfer-YYYYMMDD.csv file. The file contains one domain transfer record with a pending status:
domain1.example,pending,registrarX,clientY,
2011-03-08T19:38:00.0Z,registrarY,,2011-03-13T23:59:59.0Z,
2025-04-03T22:00:00.0Z
The <csvDomain:deletes> is used to hold the deleted domain name objects in a Differential or Incremental Deposit. All the domain name object data is deleted as part of a cascade delete. The <csvDomain:deletes> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following section defines the supported domain name deletes CSV file definition.
The following "csvDomain" field elements
MUST be used in the deletes "domain" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvDomain:fName>
-
Domain name field with type="eppcom:labelType" and isRequired="true".
The following is an example of a "domain" <csvDomain:deletes> <rdeCsv:csv> element:
...
<csvDomain:deletes>
...
<rdeCsv:csv name="domain">
<rdeCsv:fields>
<csvDomain:fName/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="A06D8194">
domain-delete-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvDomain:deletes>
...
The following is an example of the corresponding domain-delete-YYYYMMDD.csv file. The file contains two domain name records:
domain1.example
domain2.example
The host object is based on the EPP host name mapping in [
RFC 5732]. The host 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. Both the <csvHost:contents> and <csvHost:deletes> elements contain one or more <rdeCsv:csv> elements with a set of named CSV file definitions using the <rdeCsv:csv> "name" attribute.
There are two elements used in the data escrow of the host objects for the XML model including the <rdeHost:host> element, under the <rdeHost:contents> element, and the <rdeHost:delete> element, under the <rde:deletes> element.
An <rdeHost:host> element substitutes for the <rdeHost:abstractHost> abstract element to create a concrete definition of a host. The <rdeHost:abstractHost> element can be replaced by other host definitions using the XML schema substitution groups feature.
The RDE host object is based on the EPP host <info> response for an authorized client (
Section 3.1.2 of
RFC 5732).
The
OPTIONAL <host> element contains the following child elements:
-
A <name> element that contains the fully qualified name of the host object.
-
A <roid> element that contains the ROID assigned to the host object when the object was created.
-
One or more <status> elements that describe the status of the host object.
-
Zero or more <addr> elements that contain the IP addresses associated with the host object.
-
A <clID> element that contains the identifier of the sponsoring registrar.
-
An OPTIONAL <crRr> element that contains the identifier of the registrar that created the host object. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
An OPTIONAL <crDate> element that contains the date and time of host object creation.
-
An OPTIONAL <upRr> element that contains the identifier of the registrar that last updated the host object. This element MUST NOT be present if the host object has never been modified. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
An OPTIONAL <upDate> element that contains the date and time of the most recent host object modification. This element MUST NOT be present if the host object has never been modified.
-
An OPTIONAL <trDate> element that contains the date and time of the most recent host object successful transfer. This element MUST NOT be present if the domain name object has never been transferred.
The following is an example of a <host> object:
...
<rdeHost:host>
<rdeHost:name>ns1.example1.example</rdeHost:name>
<rdeHost:roid>Hns1_example_test-TEST</rdeHost:roid>
<rdeHost:status s="ok"/>
<rdeHost:status s="linked"/>
<rdeHost:addr ip="v4">192.0.2.2</rdeHost:addr>
<rdeHost:addr ip="v4">192.0.2.29</rdeHost:addr>
<rdeHost:addr ip="v6">2001:DB8:1::1</rdeHost:addr>
<rdeHost:clID>RegistrarX</rdeHost:clID>
<rdeHost:crRr>RegistrarX</rdeHost:crRr>
<rdeHost:crDate>1999-05-08T12:10:00.0Z</rdeHost:crDate>
<rdeHost:upRr>RegistrarX</rdeHost:upRr>
<rdeHost:upDate>2009-10-03T09:34:00.0Z</rdeHost:upDate>
</rdeHost:host>
...
The <rdeHost:delete> element contains the FQDN of a host that was deleted. The <rdeHost:delete> element also supports host removal based on ROID to support SRS systems in which different hosts with the same FQDN are active at the same time.
The following is an example of an <rdeHost:delete> object:
...
<rde:deletes>
...
<rdeHost:delete>
<rdeHost:name>ns1.example.example</rdeHost:name>
</rdeHost:delete>
...
</rde:deletes>
...
For the CSV model of the host object, the <csvHost:contents> child element of the <rde:contents> element is used to hold the new or updated host objects for the deposit. The <csvHost:deletes> child element of the <rde:deletes> element is used to hold the deleted or purged host objects for the deposit.
Differential and Incremental Deposits are based on changes to the host objects. The updated host object data under the <csvHost:contents> element is a cascade replace down all of the host CSV files starting with the parent
Section 5.2.2.1.1. The child CSV file definitions include an <rdeCsv:fRoid parent="true"> field. All the child CSV file definition data for the host objects in the parent
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 <csvHost:deletes> element is a cascade delete starting from the
Section 5.2.2.2.1.
The <csvHost:contents> is used to hold the new or updated host object information for the deposit. The <csvHost:contents> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following sections include the supported host CSV file definitions.
The "host" CSV File Definition defines the fields and CSV file references used for the host object records.
The following "csvHost" field elements
MUST be used in the "host" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvHost:fName>
-
Host name field with type="eppcom:labelType" and isRequired="true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MUST be used in the "host" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fRoid>
-
ROID assigned to the host object with isRequired="true".
The following "rdeCsv" and "csvRegistrar" fields
MAY be used in the "host" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fClID> or <csvRegistrar:fGurid>
-
A choice of the following:
-
<rdeCsv:fClID>
-
Identifier of the sponsoring client with isRequired="true".
-
<csvRegistrar:fGurid>
-
Contains the GURID assigned by ICANN with type="positiveInteger" and isRequired="true".
-
<rdeCsv:fCrRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that created the host object.
-
<rdeCsv:fCrID>
-
Identifier of the client that created the host object.
-
<rdeCsv:fUpRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that last updated the host object.
-
<rdeCsv:fUpID>
-
Identifier of the client that last updated the host object.
-
<rdeCsv:fCrDate>
-
Date and time that the host object was created.
-
<rdeCsv:fUpDate>
-
Date and time that the host object was last updated. This field MUST NOT be set if the domain name object has never been modified.
-
<rdeCsv:fTrDate>
-
Date and time that the host object was last transferred. This field MUST NOT be set if the domain name object has never been transferred.
The following is an example of a "host" <csvHost:contents> <rdeCsv:csv> element:
...
<csvHost:contents>
...
<rdeCsv:csv name="host">
<rdeCsv:fields>
<csvHost:fName/>
<rdeCsv:fRoid/>
<rdeCsv:fClID/>
<rdeCsv:fCrRr/>
<rdeCsv:fCrID/>
<rdeCsv:fCrDate/>
<rdeCsv:fUpRr/>
<rdeCsv:fUpID/>
<rdeCsv:fUpDate/>
<rdeCsv:fTrDate/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="6F1E58E5">
host-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvHost:contents>
...
The following is an example of the corresponding host-YYYYMMDD.csv file. The file contains six host records with four being internal hosts and two being external hosts:
ns1.domain1.example,Hns1_example_test-TEST,registrarX,registrarX,
clientY,1999-05-08T12:10:00.0Z,registrarX,
clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
ns2.domain1.example,Hns2_domain1_test-TEST,registrarX,registrarX,
clientY,1999-05-08T12:10:00.0Z,registrarX,
clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
ns1.domain2.example,Hns1_domain2_test-TEST,registrarX,registrarX,
clientY,1999-05-08T12:10:00.0Z,registrarX,
clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
ns2.domain2.example,Hns2_domain2_test-TEST,registrarX,registrarX,
clientY,1999-05-08T12:10:00.0Z,registrarX,
clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
ns1.example.net,Hns1_example_test-TEST,registrarX,registrarX,
clientY,1999-05-08T12:10:00.0Z,registrarX,
clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
ns2.example.net,Hns2_example_test-TEST,registrarX,registrarX,
clientY,1999-05-08T12:10:00.0Z,registrarX,
clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
The "hostStatuses" CSV File Definition defines the fields and CSV file references used for the host object statuses.
The following "csvHost" fields, defined for the
Section 5.2.2.1.1,
MUST be used in the "hostStatuses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvHost:fStatus>
-
The status of the host with type="host:statusValueType" and isRequired="true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MUST be used in the "hostStatuses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fRoid>
-
Host object ROID assigned to the host object with isRequired="true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MAY be used in the "hostStatuses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fStatusDescription>
-
Host object status description, which is free-form text describing the rationale for the status.
-
<rdeCsv:fLang>
-
Language of the <rdeCsv:fStatusDescription> field.
The following is an example of a "hostStatuses" <csvHost:contents> <rdeCsv:csv> element:
...
<csvHost:contents>
...
<rdeCsv:csv name="hostStatuses">
<rdeCsv:fields>
<rdeCsv:fRoid parent="true"/>
<csvHost:fStatus/>
<rdeCsv:fStatusDescription/>
<rdeCsv:fLang/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="0DAE0583">
hostStatuses-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvHost:contents>
...
The following is an example of the corresponding hostStatuses-YYYYMMDD.csv file. The file contains the statuses for the six host names ns1.domain1.example, ns2.domain1.example, ns1.domain2.example, ns2.domain2.example, ns1.example.net, and ns2.example.net:
Hns1_domain1_test-TEST,ok,,
Hns2_domain1_test-TEST,ok,,
Hns1_domain2_test-TEST,ok,,
Hns2_domain2_test-TEST,ok,,
Hns1_example_test-TEST,ok,,
Hns2_example_test-TEST,ok,,
The "hostAddresses" CSV File Definition defines the fields and CSV file references used for the host object IP addresses.
The following "csvHost" field elements
MUST be used in the "hostAddresses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvHost:fAddr>
-
IP addresses associated with the host object with type="host:addrStringType". The attribute "isRequired" MUST equal "true".
-
<csvHost:fAddrVersion>
-
IP addresses version associated with the host object with type="host:ipType". "host:ipType" has the enumerated values of "v4" or "v6". The attribute "isRequired" MUST equal "true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MUST be used in the "hostAddresses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fRoid>
-
Host object ROID assigned to the host object with isRequired="true".
The following is an example of a "hostAddresses" <csvHost:contents> <rdeCsv:csv> element:
...
<csvHost:contents>
...
<rdeCsv:csv name="hostAddresses">
<rdeCsv:fields>
<rdeCsv:fRoid parent="true"/>
<csvHost:fAddr isRequired="true"/>
<csvHost:fAddrVersion isRequired="true"/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="28B194B0">
hostAddresses-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvHost:contents>
...
The following is an example of the corresponding hostAddresses-YYYYMMDD.csv file. The file contains the IP addresses for the host names ns1.domain1.example, ns2.domain1.example, ns1.domain2.example, and ns2.domain2.example:
Hns1_domain1_test-TEST,192.0.2.1,v4
Hns2_domain1_test-TEST,2001:DB8::1,v6
Hns1_domain2_test-TEST,192.0.2.2,v4
Hns2_domain2_test-TEST,2001:DB8::2,v6
The <csvHost:deletes> is used to hold the deleted host objects in a Differential or Incremental Deposit. All the host object data is deleted as part of a cascade delete. The <csvHost:deletes> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following section defines the supported host deletes CSV file definition.
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MUST be used in the "host" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fRoid>
-
ROID assigned to the host object with isRequired="true".
The following is an example of a "host" <csvHost:deletes> <rdeCsv:csv> element:
...
<csvHost:deletes>
...
<rdeCsv:csv name="host">
<rdeCsv:fields>
<rdeCsv:fRoid/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="777F5F0E">
host-delete-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvHost:deletes>
...
The following is an example of the host-delete-YYYYMMDD.csv file. The file contains four host records:
Hns1_domain1_test-TEST
Hns2_domain1_test-TEST
Hns1_domain2_test-TEST
Hns2_domain2_test-TEST
The contact object is based on the EPP contact name mapping in [
RFC 5733]. The contact 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.
There are two elements used in the data escrow of the contact objects for the XML model including the <rdeContact:contact> element, under the <rdeContact:contents> element, and the <rdeContact:delete> element, under the <rde:deletes> element.
A <contact> element substitutes for the <abstractContact> abstract element to create a concrete definition of a contact. The <abstractContact> element can be replaced by other contact definitions using the XML schema substitution groups feature.
The contact object is based on the EPP contact <info> response for an authorized client (
Section 3.1.2 of
RFC 5733) with some additions including the data from an EPP <transfer> query response, see
Section 3.1.3 of
RFC 5733.
The
OPTIONAL <contact> element contains the following child elements:
-
A <id> element that contains the server-unique identifier of the contact object.
-
A <roid> element that contains the ROID assigned to the contact object when the object was created.
-
One or more <status> elements that describe the status of the contact object.
-
One or two <postalInfo> elements that contain postal-address information. Two elements are provided so that address information can be provided in both internationalized and localized forms; a "type" attribute is used to identify the two forms. If an internationalized form (type="int") is provided, element content MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. If a localized form (type="loc") is provided, element content MAY be represented in unrestricted UTF-8. The <postalInfo> element contains the following child elements:
-
A <name> element that contains the name of the individual or role represented by the contact.
-
An OPTIONAL <org> element that contains the name of the organization with which the contact is affiliated.
-
An <addr> element that contains address information associated with the contact. An <addr> element contains the following child elements:
-
One, two, or three OPTIONAL <street> elements that contain the contact's street address.
-
A <city> element that contains the contact's city.
-
An OPTIONAL <sp> element that contains the contact's state or province.
-
An OPTIONAL <pc> element that contains the contact's postal code.
-
A <cc> element that contains the contact's two-letter country code.
-
An OPTIONAL <voice> element that contains the contact's voice telephone number.
-
An OPTIONAL <fax> element that contains the contact's facsimile telephone number.
-
An <email> element that contains the contact's email address.
-
A <clID> element that contains the identifier of the sponsoring registrar.
-
An OPTIONAL <crRr> element that contains the identifier of the registrar that created the contact object. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
An OPTIONAL <crDate> element that contains the date and time of contact object creation.
-
An OPTIONAL <upRr> element that contains the identifier of the registrar that last updated the contact object. This element MUST NOT be present if the contact has never been modified. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
An OPTIONAL <upDate> element that contains the date and time of the most recent contact object modification. This element MUST NOT be present if the contact object has never been modified.
-
An OPTIONAL <trDate> element that contains the date and time of the most recent contact object successful transfer. This element MUST NOT be present if the contact object has never been transferred.
-
An OPTIONAL <trnData> element that contains the following child elements related to the last transfer request of the contact object:
-
A <trStatus> element that contains the state of the most recent transfer request.
-
An <reRr> element that contains the identifier of the registrar that requested the domain name object transfer. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
An <acRr> element that contains the identifier of the registrar that should act upon a pending transfer request. For all other status types, the value identifies the registrar that took the indicated action. An OPTIONAL "client" attribute is used to specify the client that performed the operation.
-
An <reDate> element that contains the date and time that the transfer was requested.
-
An <acDate> element that contains the date and time of a required or completed response. For a pending request, the value identifies the date and time by which a response is required before an automated response action will be taken by the registry. For all other status types, the value identifies the date and time when the request was completed.
-
An OPTIONAL <disclose> element that identifies elements that requiring exceptional server-operator handling to allow or restrict disclosure to third parties. See Section 2.9 of RFC 5733 for a description of the child elements contained within the <disclose> element.
The following is an example of a <contact> object:
...
<rdeContact:contact>
<rdeContact:id>sh8013</rdeContact:id>
<rdeContact:roid>Csh8013-TEST</rdeContact:roid>
<rdeContact:status s="linked"/>
<rdeContact:status s="clientDeleteProhibited"/>
<rdeContact:postalInfo type="int">
<contact:name>John Doe</contact:name>
<contact:org>Example Inc.</contact:org>
<contact:addr>
<contact:street>123 Example Dr.</contact:street>
<contact:street>Suite 100</contact:street>
<contact:city>Dulles</contact:city>
<contact:sp>VA</contact:sp>
<contact:pc>20166-6503</contact:pc>
<contact:cc>US</contact:cc>
</contact:addr>
</rdeContact:postalInfo>
<rdeContact:voice x="1234">+1.7035555555</rdeContact:voice>
<rdeContact:fax>+1.7035555556</rdeContact:fax>
<rdeContact:email>jdoe@example.example</rdeContact:email>
<rdeContact:clID>RegistrarX</rdeContact:clID>
<rdeContact:crRr client="jdoe">RegistrarX</rdeContact:crRr>
<rdeContact:crDate>2009-09-13T08:01:00.0Z</rdeContact:crDate>
<rdeContact:upRr client="jdoe">RegistrarX</rdeContact:upRr>
<rdeContact:upDate>2009-11-26T09:10:00.0Z</rdeContact:upDate>
<rdeContact:trDate>2009-12-03T09:05:00.0Z</rdeContact:trDate>
<rdeContact:trnData>
<rdeContact:trStatus>pending</rdeContact:trStatus>
<rdeContact:reRr client="jstiles">clientW</rdeContact:reRr>
<rdeContact:reDate>2011-03-08T19:38:00.0Z</rdeContact:reDate>
<rdeContact:acRr client="rmiles">RegistrarX</rdeContact:acRr>
<rdeContact:acDate>2011-03-13T23:59:59.0Z</rdeContact:acDate>
</rdeContact:trnData>
<rdeContact:disclose flag="0">
<contact:voice/>
<contact:email/>
</rdeContact:disclose>
</rdeContact:contact>
...
The <rdeContact:delete> element contains the id of a contact that was deleted.
The following is an example of an <rdeContact:delete> object:
...
<rde:deletes>
...
<rdeContact:delete>
<rdeContact:id>sh8013-TEST</rdeContact:id>
<rdeContact:id>co8013-TEST</rdeContact:id>
</rdeContact:delete>
...
</rde:deletes>
...
For the CSV model of the contact object, the <csvContact:contents> child element of the <rde:contents> element is used to hold the new or updated contacts objects for the deposit. The <csvContact:deletes> child element of the <rde:deletes> element is used to hold the deleted or purged contact objects for the deposit. Both the <csvContact:contents> and <csvContact:deletes> elements contain one or more <rdeCsv:csv> elements with a set of named CSV file definitions using the <rdeCsv:csv> "name" attribute.
Differential and Incremental Deposits are based on changes to the contact objects. The updated contact object data under the <csvContact:contents> element is a cascade replace down all of the contact CSV files starting with the parent
Section 5.3.2.1.1. The child CSV file definitions include a <csvContact:fId parent="true"> field. All the child CSV file definition data for the contact objects in the parent
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 <csvContact:deletes> element is a cascade delete starting from the
Section 5.3.2.2.1.
The <csvContact:contents> is used to hold the new or updated contact object information for the deposit. The <csvContact:contents> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following sections include the supported contact CSV file definitions.
The "contact" CSV File Definition defines the fields and CSV file references used for the contact object records.
The following "csvContact" field elements
MUST be used in the "contact" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fId>
-
Contains the server-unique contact identifier with type="eppcom:clIDType" and isRequired="true".
-
<csvContact:fEmail>
-
Contains the contact's email address with type="eppcom:minTokenType" and isRequired="true".
The following field elements
MAY be used in the "contact" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fVoice>
-
Contains the contact's voice telephone number with type="contact:e164StringType".
-
<csvContact:fVoiceExt>
-
Contains the contact's voice telephone number extension with type="token".
-
<csvContact:fFax>
-
Contains the contact's facsimile telephone number with type="contact:e164StringType".
-
<csvContact:fFaxExt>
-
Contains the contact's facsimile telephone number extension with type="token".
The following "rdeCsv" and "csvRegistrar" fields
MUST be used in the "contact" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fRoid>
-
The ROID for the contact object with isRequired="true".
-
<rdeCsv:fClID> or <csvRegistrar:fGurid>
-
A choice of the following:
-
<rdeCsv:fClID>
-
Identifier of the sponsoring client with isRequired="true".
-
<csvRegistrar:fGurid>
-
Contains the GURID assigned by ICANN with type="positiveInteger" and isRequired="true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MAY be used in the "contact" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fCrRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that created the contact object.
-
<rdeCsv:fCrID>
-
Identifier of the client that created the contact object.
-
<rdeCsv:fUpRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that last updated the contact object.
-
<rdeCsv:fUpID>
-
Identifier of the client that last updated the contact object.
-
<rdeCsv:fCrDate>
-
Date and time of the contact object creation.
-
<rdeCsv:fUpDate>
-
Date and time of the last update to the contact object. This field MUST NOT be set if the domain name object has never been modified.
-
<rdeCsv:fTrDate>
-
Date and time of the last transfer for the contact object. This field MUST NOT be set if the domain name object has never been transferred.
The following is an example of a "contact" <csvContact:contacts> <rdeCsv:csv> element:
...
<csvContact:contents>
...
<rdeCsv:csv name="contact">
<rdeCsv:fields>
<csvContact:fId/>
<rdeCsv:fRoid/>
<csvContact:fVoice/>
<csvContact:fVoiceExt/>
<csvContact:fFax/>
<csvContact:fFaxExt/>
<csvContact:fEmail/>
<rdeCsv:fClID/>
<rdeCsv:fCrRr/>
<rdeCsv:fCrID/>
<rdeCsv:fCrDate/>
<rdeCsv:fUpRr/>
<rdeCsv:fUpID/>
<rdeCsv:fUpDate/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="8587AA49">
contact-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvContact:contents>
...
The following is an example of the contact-YYYYMMDD.csv file. The file contains nine object contact records:
domain1admin,Cdomain1admin-TEST,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,registrarX,registrarX,
clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
2009-11-26T09:10:00.0Z
domain1tech,Cdomain1tech-TEST,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,registrarX,registrarX,
clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
2009-11-26T09:10:00.0Z
domain1billing,Cdomain1billing-TEST,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,registrarX,registrarX,
clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
2009-11-26T09:10:00.0Z
domain2admin,Cdomain2admin-TEST,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,registrarX,registrarX,
clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
2009-11-26T09:10:00.0Z
domain2tech,Cdomain2tech-TEST,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,registrarX,registrarX,
clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
2009-11-26T09:10:00.0Z
domain2billing,Cdomain2billing-TEST,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,registrarX,registrarX,
clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
2009-11-26T09:10:00.0Z
xnabc123admin,Cxnabc123admin-TEST,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,registrarX,registrarX,
clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
2009-11-26T09:10:00.0Z
xnabc123tech,Cxnabc123tech-TEST,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,registrarX,registrarX,
clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
2009-11-26T09:10:00.0Z
xnabc123billing,Cxnabc123billing-TEST,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,registrarX,registrarX,
clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
2009-11-26T09:10:00.0Z
The "contactStatuses" CSV File Definition defines the fields and CSV file references used for the contact object statuses.
The following "csvContact" field elements, defined in the
Section 5.3.2.1.1,
MUST be used in the "contactStatuses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fId>
-
Server-unique contact identifier of status with isRequired="true" and parent="true".
-
<csvContact:fStatus>
-
The status of the contact with type="contact:statusValueType" and isRequired="true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MAY be used in the "contactStatuses" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fStatusDescription>
-
The contact object status description, which is free-form text describing the rationale for the status.
-
<rdeCsv:fLang>
-
Language of the <rdeCsv:fStatusDescription> field.
The following is an example of a "contactStatuses" <csvContact:contents> <rdeCsv:csv> element:
...
<csvContact:contents>
...
<rdeCsv:csv name="contactStatuses">
<rdeCsv:fields>
<csvContact:fId parent="true"/>
<csvContact:fStatus/>
<rdeCsv:fStatusDescription/>
<rdeCsv:fLang/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="137E13EC">
contactStatuses-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvContact:contents>
...
The following is an example of the corresponding contactStatuses-YYYYMMDD.csv file. The file contains the statuses for the nine contact identifiers:
domain1admin,ok,,
domain1tech,ok,,
domain1billing,ok,,
domain2admin,ok,,
domain2tech,ok,,
domain2billing,ok,,
xnabc123admin,ok,,
xnabc123tech,ok,,
xnabc123billing,ok,,
The "contactPostal" CSV File Definition defines the fields and CSV file references used for the contact postal info object records.
The following "csvContact" field elements
MUST be used in the "contactPostal" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fPostalType>
-
Contains the form of the postal address information with type="contact:postalLineType" and isRequired="true". This field specifies the form ("int" or "loc"), as defined in Section 4.6.3, of the <csvContact:fName>, <csvContact:fOrg>, <csvContact:fStreet>, <csvContact:fCity>, <csvContact:fSp>, <csvContact:fPc>, and <csvContact:fCc> fields.
-
<csvContact:fName>
-
Contains the contact's name of the individual or role represented by the contact with type="contact:postalLineType" and isRequired="true". An OPTIONAL "isLoc" attribute is used to indicate the localized or internationalized form as defined in Section 4.6.3.
-
<csvContact:fStreet>
-
Contains the contact's street address line with type="contact:fPostalLineType". An "index" attribute is required to indicate which street address line the field represents with index="0" for the first line and incrementing for each line up to index="2" for the third line. An OPTIONAL "isLoc" attribute is used to indicate the localized or internationalized form as defined in Section 4.6.3.
-
<csvContact:fCity>
-
Contains the contact's city with type="contact:postalLineType" and isRequired="true". An OPTIONAL "isLoc" attribute is used to indicate the localized or internationalized form as defined in Section 4.6.3.
-
<csvContact:fCc>
-
Contains the contact's country code with type="contact:ccType" and isRequired="true". An OPTIONAL "isLoc" attribute is used to indicate the localized or internationalized form as defined in Section 4.6.3.
The following "csvContact" field elements
MAY be used in the "contactPostal" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fOrg>
-
Contains the name of the organization with which the contact is affiliated with type="contact:optPostalLineType". An OPTIONAL "isLoc" attribute is used to indicate the localized or internationalized form as defined in Section 4.6.3.
-
<csvContact:fSp>
-
Contains the contact's state or province with type="contact:optPostalLineType". An OPTIONAL "isLoc" attribute is used to indicate the localized or internationalized form as defined in Section 4.6.3.
-
<csvContact:fPc>
-
Contains the contact's postal code with type="contact:pcType". An OPTIONAL "isLoc" attribute is used to indicate the localized or internationalized form as defined in Section 4.6.3.
The following "csvContact" fields, defined in the
Section 5.3.2.1.1,
MUST be used in the "contactPostal" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fId>
-
Server-unique contact identifier for the contact object with isRequired="true" and parent="true".
The following is an example of a "contactPostal" <csvContact:contents> <rdeCsv:csv> element:
...
<csvContact:contents>
...
<rdeCsv:csv name="contactPostal">
<rdeCsv:fields>
<csvContact:fId parent="true"/>
<csvContact:fPostalType/>
<csvContact:fName/>
<csvContact:fOrg/>
<csvContact:fStreet index="0"/>
<csvContact:fStreet index="1"/>
<csvContact:fStreet index="2"/>
<csvContact:fCity/>
<csvContact:fSp/>
<csvContact:fPc/>
<csvContact:fCc/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="1456A89C">
contactPostal-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvContact:contents>
...
The following is an example of the contactPostal-YYYYMMDD.csv file. The file contains nine contact postal records:
domain1admin,int,"John Doe","Example Inc.",
"123 Example Dr.","Suite 100",,Reston,VA,20190,US
domain1tech,int,"John Doe","Example Inc.",
"123 Example Dr.","Suite 100",,Reston,VA,20190,US
domain1billing,int,"John Doe","Example Inc.",
"123 Example Dr.","Suite 100",,Reston,VA,20190,US
domain2admin,int,"John Doe","Example Inc.",
"123 Example Dr.","Suite 100",,Reston,VA,20190,US
domain2tech,int,"John Doe","Example Inc.",
"123 Example Dr.","Suite 100",,Reston,VA,20190,US
domain2billing,int,"John Doe","Example Inc.",
"123 Example Dr.","Suite 100",,Reston,VA,20190,US
xnabc123admin,int,"John Doe","Example Inc.",
"123 Example Dr.","Suite 100",,Reston,VA,20190,US
xnabc123tech,int,"John Doe","Example Inc.",
"123 Example Dr.","Suite 100",,Reston,VA,20190,US
xnabc123billing,int,"John Doe","Example Inc.",
"123 Example Dr.","Suite 100",,Reston,VA,20190,US
The "contactTransfer" CSV File Definition defines the fields and CSV file references used for the contact object pending and completed transfer records. No additional field elements were added for use in the "contactTransfer" <rdeCsv:csv> <rdeCsv:fields> element. The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MUST be used in the "contactTransfer" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fTrStatus>
-
State of the most recent transfer request with isRequired="true".
-
<rdeCsv:fReRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that requested the transfer with isRequired="true".
-
<rdeCsv:fReDate>
-
Date and time that the transfer was requested with isRequired="true".
-
<rdeCsv:fAcRr>
-
Identifier of the registrar, defined in Section 5.4, of the client that should take or took action with isRequired="true".
-
<rdeCsv:fAcDate>
-
Date and time that the transfer action should be taken or has been taken with isRequired="true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MAY be used in the "contactTransfer" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fReID>
-
Identifier of the client that requested the transfer.
-
<rdeCsv:fAcID>
-
Identifier of the client that should take or took action for transfer.
The following "csvContact" fields, defined for the
Section 5.3.2.1.1,
MUST be used in the "contactTransfer" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fId>
-
Server-unique contact identifier for the contact object with isRequired="true".
The following is an example of a "contactTransfer" <csvContact:contents> <rdeCsv:csv> element:
...
<csvContact:contents>
...
<rdeCsv:csv name="contactTransfer">
<rdeCsv:fields>
<csvContact:fId parent="true"/>
<rdeCsv:fTrStatus/>
<rdeCsv:fReRr/>
<rdeCsv:fReID/>
<rdeCsv:fReDate/>
<rdeCsv:fAcRr/>
<rdeCsv:fAcID/>
<rdeCsv:fAcDate/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="788D308E">
contactTransfer-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvContact:contents>
...
The following is an example of the contactTransfer-YYYYMMDD.csv file. The file contains one contact transfer record in pending status:
xnabc123admin,clientApproved,registrarX,clientX,
2011-04-08T19:38:00.0Z,registrarY,clientY,2011-04-09T20:38:00.0Z
The "contactDisclose" CSV File Definition defines the fields and CSV file references used for the contact disclose object records.
The following "csvContact" field elements
MAY be used in the "contactDisclose" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fDiscloseFlag>
-
Contains flag with a value of "true" or "1" (one) notes the preference to allow disclosure of the specified elements as an exception to the stated data-collection policy. A value of "false" or "0" (zero) notes a client preference to not allow disclosure of the specified elements as an exception to the stated data-collection policy with type="boolean". The additional fields define specific exceptional disclosure preferences based on the <csvContact:fDiscloseFlag> field.
-
<csvContact:fDiscloseNameLoc>
-
Exceptional disclosure preference flag for the localized form of the contact name with type="boolean".
-
<csvContact:fDiscloseNameInt>
-
Exceptional disclosure preference flag for the internationalized form of the contact name with type="boolean".
-
<csvContact:fDiscloseOrgLoc>
-
Exceptional disclosure preference flag for the localized form of the contact organization with type="boolean".
-
<csvContact:fDiscloseOrgInt>
-
Exceptional disclosure preference flag for the internationalized form of the contact organization with type="boolean".
-
<csvContact:fDiscloseAddrLoc>
-
Exceptional disclosure preference flag for the localized form of the contact address with type="boolean".
-
<csvContact:fDiscloseAddrInt>
-
Exceptional disclosure preference flag for the internationalized form of the contact address with type="boolean".
-
<csvContact:fDiscloseVoice>
-
Exceptional disclosure preference flag of the contact voice telephone number with type="boolean".
-
<csvContact:fDiscloseFax>
-
Exceptional disclosure preference flag of the contact facsimile telephone number with type="boolean".
-
<csvContact:fDiscloseEmail>
-
Exceptional disclosure preference flag of the contact email address with type="boolean".
The following "csvContact" fields, defined for the
Section 5.3.2.1.1,
MUST be used in the "contactDisclose" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fId>
-
Server-unique contact identifier for the contact object with isRequired="true".
The following is an example of a "contactDisclose" <csvContact:contents> <rdeCsv:csv> element:
...
<csvContact:contents>
...
<rdeCsv:csv name="contactDisclose">
<rdeCsv:fields>
<csvContact:fId parent="true"/>
<csvContact:fDiscloseFlag/>
<csvContact:fDiscloseNameLoc/>
<csvContact:fDiscloseNameInt/>
<csvContact:fDiscloseOrgLoc/>
<csvContact:fDiscloseOrgInt/>
<csvContact:fDiscloseAddrLoc/>
<csvContact:fDiscloseAddrInt/>
<csvContact:fDiscloseVoice/>
<csvContact:fDiscloseFax/>
<csvContact:fDiscloseEmail/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="1141EFD4">
contactDisclose-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvContact:contents>
...
The following is an example of the contactDisclose-YYYYMMDD.csv file. The file contains one disclosure records, disabling disclosure of voice, fax, and email:
xnabc123admin,0,0,0,0,0,0,0,1,1,1
The <csvContact:deletes> is used to hold the deleted contact objects in a Differential or Incremental Deposit. All the contact object data is deleted as part of a cascade delete. The <csvContact:deletes> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following section defines the supported contact deletes CSV file definition.
The following "csvContact" field elements
MUST be used in the deletes "contact" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fId>
-
Contains the server-unique contact identifier with type="eppcom:clIDType" and isRequired="true".
The following is an example of a "contact" <csvContact:deletes> <rdeCsv:csv> element:
...
<csvContact:deletes>
...
<rdeCsv:csv name="contact">
<rdeCsv:fields>
<csvContact:fId/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="0C4B70DC">
contact-delete-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvContact:deletes>
...
The following is an example of the contact-delete-YYYYMMDD.csv file. The file contains six contact records:
domain1admin
domain1tech
domain1billing
domain2admin
domain2tech
domain2billing
The registrar object represents the sponsoring client for other objects and is typically referred to as the sponsoring registrar. The registrar object supports both the XML model and the CSV model, defined in
Section 2. The elements used for both models are defined in the following sections.
There are two elements used in the data escrow of the registrar objects for the XML model including the <rdeRegistrar:registrar> element, under the <rdeRegistrar:contents> element, and the <rdeRegistrar:delete> element, under the <rde:deletes> element.
An <rdeRegistrar:registrar> element substitutes for the <rdeRegistrar:abstractRegistrar> abstract element to create a concrete definition of a registrar. The <rdeRegistrar:abstractRegistrar> element can be replaced by other domain definitions using the XML schema substitution groups feature.
The <registrar> element contains the following child elements:
-
An <id> element that contains the registry-unique identifier of the registrar object. This <id> has a superordinate relationship to a subordinate <clID>, <crRr>, or <upRr> of domain, contact, and host objects.
-
An <name> element that contains the name of the registrar.
-
An OPTIONAL <gurid> element that contains the GURID assigned by ICANN.
-
An OPTIONAL <status> element that contains the operational status of the registrar. Possible values are: ok, readonly, and terminated.
-
One or two OPTIONAL <postalInfo> elements that contain postal address information. Two elements are provided so that address information can be provided in both internationalized and localized forms; a "type" attribute is used to identify the two forms. If an internationalized form (type="int") is provided, element content MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. If a localized form (type="loc") is provided, element content MAY be represented in unrestricted UTF-8. The <postalInfo> element contains the following child elements:
-
A <addr> element that contains address information associated with the registrar. The <addr> element contains the following child elements:
-
One, two, or three OPTIONAL <street> elements that contain the registrar's street address.
-
A <city> element that contains the registrar's city.
-
An OPTIONAL <sp> element that contains the registrar's state or province.
-
An OPTIONAL <pc> element that contains the registrar's postal code.
-
A <cc> element that contains the registrar's country code.
-
An OPTIONAL <voice> element that contains the registrar's voice telephone number.
-
An OPTIONAL <fax> element that contains the registrar's facsimile telephone number.
-
An OPTIONAL <email> element that contains the registrar's email address.
-
An OPTIONAL <url> element that contains the registrar's URL.
-
An OPTIONAL <whoisInfo> element that contains WHOIS information. The <whoisInfo> element contains the following child elements:
-
An OPTIONAL <name> element that contains the name of the registrar WHOIS server listening on TCP port 43 as specified in [RFC 3912].
-
An OPTIONAL <url> element that contains the name of the registrar WHOIS server listening on TCP port 80/443.
-
An OPTIONAL <crDate> element that contains the creation date and time of the registrar object.
-
An OPTIONAL <upDate> element that contains the date and time of the most recent modification of the registrar object. This element MUST NOT be present if the registrar object has never been modified.
The following is an example of a <registrar> object:
...
<rdeRegistrar:registrar>
<rdeRegistrar:id>RegistrarX</rdeRegistrar:id>
<rdeRegistrar:name>Registrar X</rdeRegistrar:name>
<rdeRegistrar:gurid>8</rdeRegistrar:gurid>
<rdeRegistrar:status>ok</rdeRegistrar:status>
<rdeRegistrar:postalInfo type="int">
<rdeRegistrar:addr>
<rdeRegistrar:street>123 Example Dr.</rdeRegistrar:street>
<rdeRegistrar:street>Suite 100</rdeRegistrar:street>
<rdeRegistrar:city>Dulles</rdeRegistrar:city>
<rdeRegistrar:sp>VA</rdeRegistrar:sp>
<rdeRegistrar:pc>20166-6503</rdeRegistrar:pc>
<rdeRegistrar:cc>US</rdeRegistrar:cc>
</rdeRegistrar:addr>
</rdeRegistrar:postalInfo>
<rdeRegistrar:voice x="1234">+1.7035555555</rdeRegistrar:voice>
<rdeRegistrar:fax>+1.7035555556</rdeRegistrar:fax>
<rdeRegistrar:email>jdoe@example.example</rdeRegistrar:email>
<rdeRegistrar:url>http://www.example.example</rdeRegistrar:url>
<rdeRegistrar:whoisInfo>
<rdeRegistrar:name>whois.example.example</rdeRegistrar:name>
<rdeRegistrar:url>http://whois.example.example</rdeRegistrar:url>
</rdeRegistrar:whoisInfo>
<rdeRegistrar:crDate>2005-04-23T11:49:00.0Z</rdeRegistrar:crDate>
<rdeRegistrar:upDate>2009-02-17T17:51:00.0Z</rdeRegistrar:upDate>
</rdeRegistrar:registrar>
...
The <rdeRegistrar:delete> element contains the id of a registrar that was deleted.
The following is an example of <rdeRegistrar:delete> object:
...
<rde:deletes>
...
<rdeRegistrar:delete>
<rdeRegistrar:id>agnt0001-TEST</rdeRegistrar:id>
</rdeRegistrar:delete>
...
</rde:deletes>
...
For the CSV model of the registrar object, the <csvRegistrar:contents> child element of the <rde:contents> element is used to hold the new or updated registrar objects for the deposit. The <csvRegistrar:deletes> child element of the <rde:deletes> element is used to hold the deleted or purged registrar objects for the deposit. Both the <csvRegistrar:contents> and <csvRegistrar:deletes> elements contain one or more <rdeCsv:csv> elements with a set of named CSV file definitions using the <rdeCsv:csv> "name" attribute.
Differential and Incremental Deposits are based on changes to the registrar objects. The updated registrar object data under the <csvContact:contents> element is a cascade replace down all of the registrar CSV files starting with the parent
Section 5.4.2.1.1. The child CSV file definitions include a <csvRegistrar:fId parent="true"> field. All the child CSV file definition data for the registrar objects in the parent
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 <csvRegistrar:deletes> element is a cascade delete starting from the
Section 5.4.2.2.1.
The <csvRegistrar:contents> is used to hold the new or updated registrar object information for the deposit. The <csvRegistrar:contents> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following sections include the supported registrar CSV file definitions.
The "registrar" CSV File Definition defines the fields and CSV file references used for the registrar object records.
The following "csvRegistrar" field elements
MUST be used in the "registrar" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvRegistrar:fId> or <csvRegistrar:fGurid>
-
A choice of the following:
-
<csvRegistrar:fId>
-
Contains the server-unique registrar identifier with type="eppcom:clIDType" and isRequired="true".
-
<csvRegistrar:fGurid>
-
Contains the GURID assigned by ICANN with type="positiveInteger" and isRequired="true".
-
<csvRegistrar:fName>
-
Contains the name of the registrar with type="normalizedString" and isRequired="true".
The following field elements
MAY be used in the "registrar" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvRegistrar:fStatus>
-
Contains the status of the registrar with type="csvRegistrar:statusValueType".
-
<csvRegistrar:fGurid>
-
Contains the ID assigned by ICANN with type="positiveInteger". This field is included in this section in addition to the section above to support optionally providing the <csvRegistrar:fGurid> field when the <csvRegistrar:fId> field is used.
-
<csvRegistrar:fWhoisUrl>
-
Contains the Whois URL of the registrar with type="anyURI".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MAY be used in the "registrar" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fCrDate>
-
Date and time of the registrar object creation.
-
<rdeCsv:fUpDate>
-
Date and time of the last update to the registrar object. This field MUST NOT be set if the domain name object has never been modified.
-
<rdeCsv:fUrl>
-
URL for the registrar web home page.
The following "csvContact" fields, defined in
Section 5.3,
MAY be used in the "registrar" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvContact:fStreet>
-
Registrar street address line with an "index" attribute that represents the order of the street address line from "0" to "2". An OPTIONAL "isLoc" attribute that is used to indicate the localized or internationalized form, as defined in Section 4.6.3.
-
<csvContact:fCity>
-
Registrar city with an OPTIONAL "isLoc" attribute that is used to indicate the localized or internationalized form, as defined in Section 4.6.3.
-
<csvContact:fCc>
-
Registrar country code with an OPTIONAL "isLoc" attribute that is used to indicate the localized or internationalized form, as defined in Section 4.6.3.
-
<csvContact:fEmail>
-
Registrar email address. The attribute "isRequired" MUST equal "false".
-
<csvContact:fSp>
-
Registrar state or province with an OPTIONAL "isLoc" attribute that is used to indicate the localized or internationalized form, as defined in Section 4.6.3.
-
<csvContact:fPc>
-
Registrar postal code with an OPTIONAL "isLoc" attribute that is used to indicate the localized or internationalized form, as defined in Section 4.6.3.
-
<csvContact:fVoice>
-
Registrar voice telephone number.
-
<csvContact:fVoiceExt>
-
Registrar voice telephone number extension.
-
<csvContact:fFax>
-
Registrar facsimile telephone number.
-
<csvContact:fFaxExt>
-
Registrar facsimile telephone number extension.
The following is an example of a "registrar" <csvRegistrar:contents> <rdeCsv:csv> element:
...
<csvRegistrar:contents>
...
<rdeCsv:csv name="registrar">
<rdeCsv:fields>
<csvRegistrar:fId/>
<csvRegistrar:fName isLoc="false"/>
<csvRegistrar:fGurid/>
<csvRegistrar:fStatus/>
<csvContact:fStreet isLoc="false" index="0"/>
<csvContact:fStreet isLoc="false" index="1"/>
<csvContact:fStreet isLoc="false" index="2"/>
<csvContact:fCity isLoc="false"/>
<csvContact:fSp isLoc="false" />
<csvContact:fPc isLoc="false" />
<csvContact:fCc isLoc="false"/>
<csvContact:fVoice/>
<csvContact:fVoiceExt/>
<csvContact:fFax/>
<csvContact:fFaxExt/>
<csvContact:fEmail isRequired="false"/>
<rdeCsv:fUrl/>
<csvRegistrar:fWhoisUrl/>
<rdeCsv:fCrDate/>
<rdeCsv:fUpDate/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="57F6856F">
registrar-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvRegistrar:contents>
...
The following is an example of the registrar-YYYYMMDD.csv file. The file contains one registrar record:
registrarX,"Example Inc.",8,ok,"123 Example Dr.",
"Suite 100",,Dulles,VA,20166-6503,US,+1.7035555555,1234,
+1.7035555556,,jdoe@example.example,http://www.example.example,
http://whois.example.example,2005-04-23T11:49:00.0Z,
2009-02-17T17:51:00.0Z
The <csvRegistrar:deletes> is used to hold the deleted registrar objects in a Differential or Incremental Deposit. All the registrar object data is deleted as part of a cascade delete. The <csvRegistrar:deletes> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following section defines the supported registrar deletes CSV file definition.
The following "csvRegistrar" field elements
MUST be used in the deletes "registrar" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvRegistrar:fId> or <csvRegistrar:fGurid>
-
A choice of the following:
-
<csvRegistrar:fId>
-
Contains the server-unique registrar identifier with type="eppcom:clIDType" and isRequired="true".
-
<csvRegistrar:fGurid>
-
Contains the GURID assigned by ICANN with type="positiveInteger". The attribute "isRequired" MUST equal "true".
The following is an example of a "registrar" <csvRegistrar:deletes> <rdeCsv:csv> element:
...
<csvRegistrar:deletes>
...
<rdeCsv:csv name="registrar">
<rdeCsv:fields>
<csvRegistrar:fId/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="5CB20A52">
registrar-delete-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvRegistrar:deletes>
...
The following is an example of the registrar-delete-YYYYMMDD.csv file. The file contains one registrar record:
The Internationalized Domain Names (IDN) table reference object is a pseudo-object that is used to provide a short reference to the IDN table and policy used in IDN registrations. The IDN reference object supports both the XML and the CSV model, defined in
Section 2. The elements used for both models are defined in the following sections.
There is one element used in the data escrow of the IDN table reference objects for the XML model, and that is the <rdeIDN:idnTableRef>, under the <rde:contents> element.
The <rdeIDN:idnTableRef> contains the following elements. An "id" attribute is used to specify an identifier for the IDN table.
-
A <url> element that contains the URL of the IDN table that is being referenced.
-
A <urlPolicy> element that contains the URL of the IDN policy document. If IDN variants are generated algorithmically, the policy document MUST define the algorithm and the state of the implicitly generated IDN variants. For a list of suggested states for implicit IDN variants, please see [variantTLDsReport].
The following is an example of <idnTableRef> object:
...
<rdeIDN:idnTableRef id="pt-BR">
<rdeIDN:url>
http://www.iana.org/domains/idn-tables/tables/br_pt-br_1.0.html
</rdeIDN:url>
<rdeIDN:urlPolicy>
http://registro.br/dominio/regras.html
</rdeIDN:urlPolicy>
</rdeIDN:idnTableRef>
...
The IDN domain names, defined in
Section 5.1,
MAY have references to the IDN language identifier using the <rdeCsv:fIdnTableId> field element. The IDN table reference object defines the mapping of a language identifier to a language table URL. The language table URL defines the character code points that can be used for the language identifier. The elements used for the IDN table reference object are defined in this section. The <csvIDN:contents> child element of the <rde:contents> element is used to hold the new or updated IDN table reference objects for the deposit. The <csvIDN:deletes> child element of the <rde:deletes> element is used to hold the deleted or purged IDN table reference objects for the deposit. Both the <csvIDN:contents> and <csvIDN:deletes> elements contain one or more <rdeCsv:csv> elements with a set of named CSV file definitions using the <rdeCsv:csv> "name" attribute.
The <csvIDN:contents> is used to hold the new or updated IDN table reference object information for the deposit. The <csvIDN:contents> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following sections include the supported IDN table reference CSV file definitions.
The "idnLanguage" CSV File Definition defines the fields and CSV file references used for the IDN table reference object records.
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MUST be used in the "idnLanguage" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fIdnTableId>
-
The language identifier that matches the values for the <rdeCsv:fIdnTableId> field element in the Section 5.1.2.1.1 files. The attribute "isRequired" MUST equal "true".
-
<rdeCsv:fUrl>
-
URL that defines the character code points that can be used for <csvDomain:fName> field in the Section 5.1.2.1.1 files. The attribute "isRequired" MUST equal "true".
The following is an example of a "idnLanguage" <csvIDN:contents> <rdeCsv:csv> element:
...
<csvIDN:contents>
...
<rdeCsv:csv name="idnLanguage" sep=",">
<rdeCsv:fields>
<rdeCsv:fIdnTableId isRequired="true"/>
<rdeCsv:fUrl isRequired="true"/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="D6B0424F">
idnLanguage-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvIDN:contents>
...
The following is an example of the corresponding idnLanguage-YYYYMMDD.csv file. The file contains two IDN language records:
LANG-1,
http://www.iana.org/domains/idn-tables/tables/test_tab1_1.1.txt
LANG-2,
http://www.iana.org/domains/idn-tables/tables/test_tab2_1.1.txt
The <csvIDN:deletes> is used to hold the deleted IDN table reference objects in a Differential or Incremental Deposit. The <csvIDN:deletes> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following section defines the supported IDN table reference deletes CSV file definition.
The following "idnLanguage" field elements
MUST be used in the deletes "idnLanguage" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fIdnTableId>
-
The language identifier that matches the values for the <rdeCsv:fIdnTableId> field element in the Section 5.1.2.1.1 files. The attribute "isRequired" MUST equal "true".
The following is an example of a "idnLanguage" <csvIDN:deletes> <rdeCsv:csv> element:
...
<csvIDN:deletes>
...
<rdeCsv:csv name="idnLanguage">
<rdeCsv:fields>
<rdeCsv:fIdnTableId isRequired="true"/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="4A28A569">
idnLanguage-delete-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvIDN:deletes>
...
The following is an example of the idnLanguage-delete-YYYYMMDD.csv file. The file contains one IDN language record:
An NNDN (NNDN's not domain name) can be used to store registry reserved names or (blocked, withheld, or mirrored) IDN variants.
Domain name registries may maintain domain names without their being persisted as domain objects in the registry system, for example, a list of reserved names not available for registration. The NNDN is a lightweight domain-like object that is used to escrow domain names not maintained as domain name objects.
A domain name can only exist as a domain name object or an NNDN object, but not both.
The NNDN object supports both the XML and the CSV model, defined in
Section 2. The elements used for both models are defined in the following sections.
There are two elements used in the data escrow of the NNDN objects for the XML model including the <rdeNNDN:NNDN> element, under the <rde:contents> element, and the <rdeNNDN:delete> element, under the <rde:deletes> element.
An <rdeNNDN:NNDN> element substitutes for the <rdeNNDN:abstractNNDN> abstract element to create a concrete definition of an NNDN. The <rdeNNDN:abstractDomain> element can be replaced by other NNDN definitions using the XML schema substitution groups feature.
The <rdeNNDN:NNDN> element contains the following child elements:
-
An <aName> element that contains the fully qualified name of the NNDN. For IDNs, the A-label is used (see RFC 5891, Section 4.4).
-
An OPTIONAL <uName> element that contains the fully qualified name of the NNDN in the Unicode character set. It MUST be provided if available.
-
An OPTIONAL <idnTableId> element that references the IDN table used for the NNDN. This corresponds to the "id" attribute of the <idnTableRef> element. This element MUST be present if the NNDN is an IDN.
-
An OPTIONAL <originalName> element is used to indicate that the NNDN is used for an IDN variant. This element contains the domain name used to generate the IDN variant.
-
A <nameState> element that indicates the state of the NNDN: blocked, withheld, or mirrored.
-
If an NNDN is considered undesirable for registration (i.e., unavailable for allocation to anyone), then the NNDN will be tagged as "blocked".
-
If an NNDN is considered a potential registration of a domain name object for a registrant, then the NNDN will be tagged as "withheld". This status is only used when the NNDN is used for an IDN variant.
-
If an NNDN is considered a mirrored IDN variant of a domain name object, then the NNDN will be tagged as "mirrored". A "mirroringNS" attribute is used to specify if the mirrored IDN variant uses the NS mirror mechanism, meaning that the activated variant domain name (i.e., NNDN) is delegated in the DNS using the same NS records as in the <originalName>. The default value of "mirroringNS" is true. If another mechanism such as DNAME [RFC 6672] is used, the value of the "mirroringNS" attribute MUST be false.
-
An OPTIONAL <crDate> element that contains the date and time of the NNDN object creation.
The following is an example of an <rdeNNDN:NNDN> object:
...
<rdeNNDN:NNDN>
<rdeNNDN:aName>xn--exampl-gva.example</rdeNNDN:aName>
<rdeNNDN:idnTableId>pt-BR</rdeNNDN:idnTableId>
<rdeNNDN:originalName>example.example</rdeNNDN:originalName>
<rdeNNDN:nameState>withheld</rdeNNDN:nameState>
<rdeNNDN:crDate>2005-04-23T11:49:00.0Z</rdeNNDN:crDate>
</rdeNNDN:NNDN>
...
The <rdeNNDN:delete> element contains the NNDN that was deleted, i.e., the <aName>.
The following is an example of an <rdeNNDN::delete> object:
...
<rde:deletes>
...
<rdeNNDN:delete>
<rdeNNDN:aName>xn--pingino-q2a.example</rdeNNDN:aName>
</rdeNNDN:delete>
...
</rde:deletes>
...
For the CSV model of the NNDN object, the <csvNNDN:contents> child element of the <rde:contents> element is used to hold the new or updated NNDN objects for the deposit. The <csvNNDN:deletes> child element of the <rde:deletes> element is used to hold the deleted or purged NNDN objects for the deposit. Both the <csvNNDN:contents> and <csvNNDN:deletes> elements contain one or more <rdeCsv:csv> elements with a set of named CSV file definitions using the <rdeCsv:csv> "name" attribute.
The <csvNNDN:contents> is used to hold the new or updated NNDN object information for the deposit. The <csvNNDN:contents> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following sections include the supported NNDN CSV file definitions.
The "NNDN" CSV File Definition defines the fields and CSV file references used for the NNDN object records.
The following "csvNNDN" field elements
MUST be used in the "NNDN" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvNNDN:fAName>
-
Fully qualified name of the NNDN with type="eppcom:labelType" and isRequired="true". For IDNs, the A-label is used (see RFC 5891, Section 4.4).
-
<csvNNDN:fNameState>
-
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 <rdeNNDN:nameState> element.
The following field elements
MAY be used in the "NNDN" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvNNDN:fOriginalName>
-
Domain name used to generate the IDN variant with type="eppcom:labelType".
-
<csvNNDN:fMirroringNS>
-
Defines whether the "mirroring" <csvNNDN:fNameState> uses the NS mirror mechanism, as described for the <rdeNNDN:nameState> "mirroringNS" attribute in Section 5.6.1.1, with type="boolean". If the field element is not defined the default value is "true".
The following "rdeCsv" fields, defined in
Section 4.6.2.2,
MAY be used in the "NNDN" <rdeCsv:csv> <rdeCsv:fields> element:
-
<rdeCsv:fCrDate>
-
Date and time of the NNDN object creation.
-
<rdeCsv:fUName>
-
Name of the NNDN in the Unicode character set for the <csvNNDN:fAName> field element.
-
<rdeCsv:fIdnTableId>
-
IDN table identifier for the NNDN that matches an IDN table reference object record, as defined in Section 5.5.2.
The following is an example of an "NNDN" <csvNNDN:contents> <rdeCsv:csv> element:
...
<csvNNDN:contents>
...
<rdeCsv:csv name="NNDN" sep=",">
<rdeCsv:fields>
<csvNNDN:fAName/>
<rdeCsv:fIdnTableId/>
<csvNNDN:fOriginalName/>
<csvNNDN:fNameState/>
<csvNNDN:fMirroringNS/>
<rdeCsv:fCrDate/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="085A7CE4">
NNDN-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvNNDN:contents>
...
The following is an example of the corresponding NNDN-YYYYMMDD.csv file. The file contains two NNDN records for an IDN with one blocked variant and one mirrored variant:
xn--bc456-3ve.example,LANG-1,xn--bc123-3ve.example,
blocked,,2005-04-23T11:49:00.0Z
xn--bc789-3ve.example,LANG-1,xn--bc123-3ve.example,
mirrored,1,2005-04-23T11:49:00.0Z
The <csvNNDN:deletes> is used to hold the deleted NNDN objects in a Differential or Incremental Deposit. The <csvNNDN:deletes> is split into separate CSV file definitions using named <rdeCsv:csv> elements with the "name" attribute. The following section defines the supported NNDN deletes CSV file definition.
The following "NNDN" field elements
MUST be used in the deletes "NNDN" <rdeCsv:csv> <rdeCsv:fields> element:
-
<csvNNDN:fAName>
-
Fully qualified name of the NNDN with type="eppcom:labelType" and isRequired="true".
The following is an example of an "NNDN" <csvNNDN:deletes> <rdeCsv:csv> element:
...
<csvNNDN:deletes>
...
<rdeCsv:csv name="NNDN">
<rdeCsv:fields>
<csvNNDN:fAName/>
</rdeCsv:fields>
<rdeCsv:files>
<rdeCsv:file
cksum="A41F1D9B">
NNDN-delete-YYYYMMDD.csv
</rdeCsv:file>
</rdeCsv:files>
</rdeCsv:csv>
...
</csvNNDN:deletes>
...
The following is an example of the corresponding NNDN-delete-YYYYMMDD.csv file. The file contains one NNDN records:
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 [
RFC 5730]. The EPP parameters object is only defined as XML but could be used in either the XML model or CSV model. The EPP parameters object is defined using the <rdeEppParams:eppParams> element. The EPP parameters object
SHOULD be included if the registry supports EPP. A maximum of one EPP parameters object
MUST exist at a certain point in time (Time Watermark).
The syntax and content of the <rdeEppParams:eppParams> children elements is as explained in
Section 2.4 of
RFC 5730. The children of the <eppParams> are as follows:
-
One or more <version> elements that indicate the EPP versions supported by the registry.
-
One or more <lang> elements that indicate the identifiers of the text response languages supported by the registry's EPP server.
-
One or more <objURI> elements that contain namespace URIs representing the objects that the registry's EPP server is capable of managing.
-
An OPTIONAL <svcExtension> element that contains one or more <extURI> elements that contain namespace URIs representing object extensions supported by the registry's EPP server.
-
A <dcp> element that contains child elements used to describe the server's privacy policy for data collection and management. See Section 2.4 of RFC 5730 for more details.
The following is an example of <eppParams> element object:
...
<rdeEppParams:eppParams>
<rdeEppParams:version>1.0</rdeEppParams:version>
<rdeEppParams:lang>en</rdeEppParams:lang>
<rdeEppParams:objURI>urn:ietf:params:xml:ns:domain-1.0
</rdeEppParams:objURI>
<rdeEppParams:objURI>urn:ietf:params:xml:ns:contact-1.0
</rdeEppParams:objURI>
<rdeEppParams:objURI>urn:ietf:params:xml:ns:host-1.0
</rdeEppParams:objURI>
<rdeEppParams:svcExtension>
<epp:extURI>urn:ietf:params:xml:ns:rgp-1.0</epp:extURI>
<epp:extURI>urn:ietf:params:xml:ns:secDNS-1.1</epp:extURI>
</rdeEppParams:svcExtension>
<rdeEppParams:dcp>
<epp:access><epp:all/></epp:access>
<epp:statement>
<epp:purpose>
<epp:admin/>
<epp:prov/>
</epp:purpose>
<epp:recipient>
<epp:ours/>
<epp:public/>
</epp:recipient>
<epp:retention>
<epp:stated/>
</epp:retention>
</epp:statement>
</rdeEppParams:dcp>
</rdeEppParams:eppParams>
...
The policy object is a pseudo-object that is used to specify which
OPTIONAL elements from the XML model are
REQUIRED based on the business model of the registry. For the CSV model, the
OPTIONAL "isRequired" attribute of the <rdeCsv:field> elements, defined in
Section 4.6.2.1, is used to specify which
OPTIONAL fields are
REQUIRED based on the business model of the registry.
The
OPTIONAL <policy> contains the following attributes:
-
An <element> that defines that the referenced <element> is REQUIRED.
-
<scope> that defines the XPath (see [W3C.REC-xpath-31-20170321]) of the element referenced by <element>.
The following is an example of <rdePolicy:policy> object:
...
<rdePolicy:policy scope="//rde:deposit/rde:contents/rdeDomain:domain"
element="rdeDomain:registrant" />
...
The header object is a pseudo-object that is used to specify the number of objects in the repository at a specific point in time (Timeline Watermark) regardless of the type of deposit: Differential, Full, or Incremental Deposit. The header object may also be used to provide additional information on the contents of the deposit. The header object is only defined as XML but one header object
MUST always be present per escrow deposit regardless of using the XML model or CSV model. The header object is defined using the <rdeHeader:header> element.
The <rdeHeader:header> contains the following elements:
-
A choice of one of the elements defined in the "repositoryTypeGroup" group element that indicates the unique identifier for the repository being escrowed. Possible elements are:
-
An <rdeHeader:tld> element that defines TLD or the RCDN being escrowed in the case of a registry data escrow deposit. For IDNs, the A-label is used (see RFC 5891, Section 4.4).
-
An <rdeHeader:registrar> element that defines the Registrar ID corresponding to a registrar data escrow deposit. In the case of an ICANN-accredited registrar, the <rdeHeader:registrar> element MUST be the IANA Registrar ID assigned by ICANN.
-
An <rdeHeader:ppsp> element that defines the provider ID corresponding to a Privacy and Proxy Services Provider (PPSP) data escrow deposit. In the case of an ICANN-accredited PPSP, the <rdeHeader:ppsp> element MUST be the unique ID assigned by ICANN.
-
An <rdeHeader:reseller> element that defines the provider ID corresponding to a reseller data escrow deposit.
-
A <count> element that contains the number of objects in the SRS at a specific point in time (Timeline Watermark) regardless of the type of deposit: Differential, Full, or Incremental. The <count> element supports the following attributes:
-
A "uri" attribute reflects the XML namespace URI of the primary objects for the XML model and CSV model. For example, the "uri" is set to "urn:ietf:params:xml:ns:rdeDomain-1.0" for domain name objects using the XML model, and the "uri" is set to "urn:ietf:params:xml:ns:csvDomain-1.0" for domain name objects using the CSV model.
-
An OPTIONAL "rcdn" attribute indicates the RCDN of the objects included in the <count> element. For IDNs, the A-label is used RFC 5891, Section 4.4. If the "rcdn" attribute is present, the value of the <count> 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 <count> 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 <count> element. In the case of an ICANN-accredited registrar, the value MUST be the IANA Registrar ID assigned by ICANN.
-
An OPTIONAL <contentTag> 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 <contentTag> element values.
The following is an example of <rdeHeader:header> object referencing only the XML model objects:
...
<rdeHeader:header>
<rdeHeader:tld>test</rdeHeader:tld>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:rdeDomain-1.0">2</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:rdeHost-1.0">1</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:rdeContact-1.0">1</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:rdeRegistrar-1.0">1
</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:rdeIDN-1.0">1</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:rdeNNDN-1.0">1</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1
</rdeHeader:count>
</rdeHeader:header>
...
The following is an example of an <rdeHeader:header> object referencing the CSV and XML model objects:
...
<rdeHeader:header>
<rdeHeader:tld>test</rdeHeader:tld>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:csvDomain-1.0">2</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:csvHost-1.0">1</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:csvContact-1.0">1</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:csvRegistrar-1.0">1
</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:csvIDN-1.0">1</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:csvNNDN-1.0">1</rdeHeader:count>
<rdeHeader:count
uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1
</rdeHeader:count>
</rdeHeader:header>
...
The DNRD common objects collection contains data structures referenced by two or more of the main objects in the XML model.