RFC 9361 | ICANN TMCH | March 2023 |
Lozano | Informational | [Page] |
This document describes the requirements, the architecture, and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and Domain Name Registries, as well as between the ICANN TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9361.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
Domain Name Registries may operate in special modes for certain periods of time, enabling Trademark Holders to protect their rights during the introduction of a Top-Level Domain (TLD).¶
Along with the introduction of new generic TLDs (gTLDs), two special modes came into effect:¶
This document describes the requirements, the architecture, and the interfaces between the ICANN TMCH and Domain Name Registries (called "Registries" in the rest of the document), as well as between the ICANN TMCH and Domain Name Registrars (called "Registrars" in the rest of the document) for the provisioning and management of domain names during Sunrise and Trademark Claims Periods.¶
For any date and/or time indications, Coordinated Universal Time (UTC) applies.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.¶
"tmNotice-1.0" is used as an abbreviation for "urn:ietf:params:xml:ns:tmNotice-1.0". The XML namespace prefix "tmNotice" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents.¶
Extensible Markup Language (XML) 1.0, as described in [W3C.REC-xml-20081126], and XML Schema notation, as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028], are used in this specification.¶
In the following section, the most common terms are briefly explained:¶
Figure 1 depicts the architecture of the Sunrise Period, including all the actors and interfaces.¶
Figure 2 depicts the architecture of the Trademark Claims Period, including all the actors and interfaces.¶
The subsections below contain short descriptions of each interface to provide an overview of the architecture. More detailed descriptions of the relevant interfaces are in Section 5.¶
The TMH registers a mark with a TMV via the hv interface.¶
After successful registration of the mark, the TMV makes a Signed Mark Data (SMD) File available (see Section 6.4) to the TMH to be used during the Sunrise Period.¶
The specifics of the hv interface are beyond the scope of this document.¶
After successful registration of the mark, the TMV ensures the TMDB inserts the corresponding DNLs and marks information into the database via the vd interface.¶
The specifics of the vd interface are beyond the scope of this document.¶
During the Trademark Claims Period, the Registry fetches the latest DNL List from the TMDB via the dy interface at regular intervals. The protocol used on the dy interface is HTTPS.¶
This interface is not relevant during the Sunrise Period.¶
The Registrant communicates with the Registrar via the tr interface.¶
The specifics of the tr interface are beyond the scope of this document.¶
The Registrar communicates with the Registry via the ry interface. The ry interfaces are typically implemented in EPP.¶
During the Trademark Claims Period, the Registrar fetches the TCN from the TMDB (to be displayed to the Registrant via the tr interface) via the dr interface. The protocol used for fetching the TCN is HTTPS.¶
This interface is not relevant during the Sunrise Period.¶
During the Sunrise Period, the Registry notifies the TMDB via the yd interface of all DNs effectively allocated.¶
During the Trademark Claims Period, the Registry notifies the TMDB via the yd interface of all DNs effectively allocated that matched an entry in the DNL List that the Registry previously downloaded during the creation of the DN.¶
The protocol used on the yd interface is HTTPS.¶
The TMDB notifies the TMV via the dv interface of all effectively allocated DNs that match a mark registered by that TMV.¶
The specifics of the dv interface are beyond the scope of this document.¶
The TMV notifies the TMH via the vh interface after an effectively allocated DN matches a PRM of this THM.¶
The specifics of the vh interface are beyond the scope of this document.¶
The TMV requests to add revoked SMDs to the SMD Revocation List at the TMDB.¶
The specifics of the vs interface are beyond the scope of this document.¶
This interface is not relevant during the Trademark Claims Period.¶
During the Sunrise Period, the Registry fetches the most recent SMD Revocation List from the TMDB via the sy interface in regular intervals. The protocol used on the sy interface is HTTPS.¶
This interface is not relevant during the Trademark Claims Period.¶
During the Sunrise Period, the Registrar may fetch the most recent SMD Revocation List from the TMDB via the sr interface. The protocol used on the sr interface is the same as on the sy interface (see above), i.e., HTTPS.¶
This interface is not relevant during the Trademark Claims Period.¶
The TMV registers its public key and requests to revoke an existing key with the ICANN TMCH-CA over the vc interface.¶
The specifics of the vc interface are beyond the scope of this document, but it involves personal communication between the operators of the TMV and the operators of the ICANN TMCH-CA.¶
This interface is not relevant during the Trademark Claims Period.¶
During the Sunrise Period, the Registry fetches the most recent TMV CRL file from the ICANN TMCH-CA via the cy interface at regular intervals. The TMV CRL is used for validation of TMV certificates. The protocol used on the cy interface is HTTPS.¶
This interface is not relevant during the Trademark Claims Period.¶
During the Sunrise Period, the Registrar optionally fetches the most recent TMV CRL file from the ICANN TMCH-CA via the cr interface at regular intervals. The TMV CRL is used for validation of TMV certificates. The protocol used on the cr interface is HTTPS.¶
This interface is not relevant during the Trademark Claims Period.¶
Each Registry Operator will receive authentication credentials from the TMDB to be used:¶
Note: Credentials are created per TLD and provided to the Registry Operator.¶
Each Registry Operator MUST provide the TMDB with all IP addresses, which will be used to:¶
This access restriction MAY be applied by the TMDB in addition to HTTP Basic access authentication (see [RFC7617]). For credentials to be used, see Section 5.1.1.1.¶
The TMDB MAY limit the number of IP addresses to be accepted per Registry Operator.¶
Each Registry Operator MUST fetch the PKIX certificate [RFC5280] of the ICANN TMCH-CA (Trust Anchor) from <https://ca.icann.org/tmch.crt> to be used:¶
The TMDB MUST provide each Registry Operator with the public portion of the PGP Key used by the TMDB, which is to be used:¶
Each ICANN-Accredited Registrar will receive authentication credentials from the TMDB to be used:¶
Each Registrar MUST provide the TMDB with all IP addresses, which will be used to:¶
This access restriction MAY be applied by the TMDB in addition to HTTP Basic access authentication (for credentials to be used, see Section 5.1.2.1).¶
The TMDB MAY limit the number of IP addresses to be accepted per Registrar.¶
Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust Anchor) from <https://ca.icann.org/tmch.crt> to be used:¶
Registrars MUST receive the public portion of the PGP Key used by TMDB from the TMDB administrator to be used:¶
Figure 3 represents a synchronous DN registration workflow (usually called first come first served).¶
Registries MUST perform a minimum set of checks for verifying each DN registration during the Sunrise Period upon reception of a registration request over the ry interface (Section 4.3.5). If any of these checks fail, the Registry MUST abort the registration. Each of these checks MUST be performed before the DN is effectively allocated.¶
In case of asynchronous registrations (e.g., auctions), the minimum set of checks MAY be performed when creating the intermediate object (e.g., a DN application) used for DN registration. If the minimum set of checks is performed when creating the intermediate object (e.g., a DN application), a Registry MAY effectively allocate the DN without performing the minimum set of checks again.¶
Performing the minimum set of checks, Registries MUST verify that:¶
These procedures apply to all DN effective allocations at the second level, as well as to all other levels subordinate to the TLD that the Registry accepts registrations for.¶
A new SMD Revocation List MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC.¶
Registries MUST refresh the latest version of the SMD Revocation List at least once every 24 hours.¶
Note: The SMD Revocation List will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the SMD Revocation List once every 24 hours, and the SMD Revocation List could be used for all the TLDs managed by the Backend Registry Operator.¶
Figure 4 depicts the process of downloading the latest SMD Revocation List initiated by the Registry.¶
Registries MUST refresh their local copy of the TMV CRL file at least once every 24 hours using the CRL distribution point specified in the TMV certificate.¶
Operationally, the TMV CRL file and CRL distribution point are the same for all TMVs and (at publication of this document) are located at <http://crl.icann.org/tmch.crl>.¶
Note: The TMV CRL file will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the TMV CRL file once every 24 hours, and the TMV CRL file could be used for all the TLDs managed by the Backend Registry Operator.¶
Figure 5 depicts the process of downloading the latest TMV CRL file initiated by the Registry.¶
The Registry MUST send a LORDN file containing DNs effectively allocated to the TMDB (over the yd interface; see Section 4.3.7).¶
The effective allocation of a DN MUST be reported by the Registry to the TMDB within 26 hours of the effective allocation of such DN.¶
The Registry MUST create and upload a LORDN file in case there are effective allocations in the SRS that have not been successfully reported to the TMDB in a previous LORDN file.¶
Based on the timers used by TMVs and the TMDB, the RECOMMENDED maximum frequency to upload LORDN files from the Registries to the TMDB is every 3 hours.¶
It is RECOMMENDED that Registries try to upload at least two LORDN files per day to the TMDB, with enough time in between, in order to have time to fix problems reported in the LORDN file.¶
The Registry SHOULD upload a LORDN file only when the previous LORDN file has been processed by the TMDB and the related LORDN Log file has been downloaded and processed by the Registry.¶
The Registry MUST upload LORDN files for DNs that are effectively allocated during the Sunrise or Trademark Claims Periods (same applies to DNs that are effectively allocated using applications created during the Sunrise or Trademark Claims Periods in case of using asynchronous registrations).¶
The yd interface (Section 4.3.7) MUST support at least one (1) and MAY support up to ten (10) concurrent connections from each IP address registered by a Registry Operator to access the service.¶
The TMDB MUST process each uploaded LORDN file and make the related log file available for Registry download within 30 minutes of the finalization of the upload.¶
Figure 6 depicts the process to notify the TMH of Registered Domain Names.¶
The format used for the LORDN is described in Section 6.3.¶
Registrars MAY choose to perform the checks for verifying DN registrations, as performed by the Registries (see Section 5.2.2) before sending the command to register a DN.¶
The processes described in Sections 5.2.3.1 and 5.2.3.2 are also available for Registrars to optionally validate the SMDs received.¶
Figure 7 represents a synchronous DN registration workflow (usually called first come first served).¶
During the Trademark Claims Period, Registries perform two main functions:¶
In the following instances, a minimum set of checks are described:¶
Performing the minimum set of checks, Registries MUST verify that:¶
The TCNID (<tmNotice:id>), expiration datetime (<tmNotice:notAfter>), and acceptance datetime of the TCN have been received from the Registrar, along with the DN registration.¶
If the three elements mentioned above are not provided by the Registrar for a DN matching a DNL of a PRM, but the DNL was inserted (or reinserted) for the first time into the DNL List less than 24 hours ago, the registration MAY continue without this data, and the tests listed below are not required to be performed.¶
These procedures apply to all DN registrations at the second level, as well as to all other levels subordinate to the TLD that the Registry accepts registrations for.¶
A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC.¶
Registries MUST refresh the latest version of the DNL List at least once every 24 hours.¶
Figure 8 depicts the process of downloading the latest DNL List initiated by the Registry.¶
Note: The DNL List will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the DNL List once every 24 hours, and the DNL List could be used for all the TLDs managed by the Backend Registry Operator.¶
The NORDN process during the Trademark Claims Period is almost the same as during the Sunrise Period, as defined in Section 5.2.3.3; the difference is that only registrations subject to a Trademark Claim (i.e., at registration time, the name appeared in the current DNL List downloaded by the Registry Operator) are included in the LORDN.¶
For each DN matching a DNL of a PRM, Registrars MUST perform the following steps:¶
Perform the minimum set of checks for verifying DN registrations. If any of these checks fail, the Registrar MUST abort the DN registration. Each of these checks MUST be performed before the registration is sent to the Registry. Performing the minimum set of checks, Registrars MUST verify the following:¶
Send the registration to the Registry (via the ry interface; see Section 4.3.5) and include the following information:¶
Currently, TCNs are generated twice a day by the TMDB. The expiration date (<tmNotice:notAfter>) of each TCN MUST be set to a value defined by ICANN policy. In the gTLD round of 2012, the TMDB set the expiration value to 48 hours into the future, as there were no defined ICANN policies at that time. Implementers should be aware that ICANN policy may define this value in the future.¶
Registrars SHOULD implement a cache of TCNs to minimize the number of queries sent to the TMDB. A cached TCN MUST be removed from the cache after the expiration date of the TCN, as defined by <tmNotice:notAfter>.¶
The TMDB MAY implement rate limiting as one of the protection mechanisms to mitigate the risk of performance degradation.¶
The TCNs are provided by the TMDB online and are fetched by the Registrar via the dr interface (Section 4.3.6).¶
To get access to the TCNs, the Registrar needs the credentials provided by the TMDB (Section 5.1.2.1) and the lookup key received from the Registry via the ry interface (Section 4.3.5). The dr interface (Section 4.3.6) uses HTTPS with Basic access authentication.¶
The dr interface (Section 4.3.6) MAY support up to ten (10) concurrent connections from each Registrar.¶
The URL of the dr interface (Section 4.3.6) is:¶
https://<tmdb-domain-name>/cnis/<lookupkey>.xml¶
Note that the "lookupkey" may contain slash characters ("/"). The slash character is part of the URL path and MUST NOT be escaped when requesting the TCN.¶
The TLS certificate (HTTPS) used on the dr interface (Section 4.3.6) MUST be signed by a well-know public CA. Registrars MUST perform the certification path validation described in Section 6 of [RFC5280]. Registrars will be authenticated in the dr interface using HTTP Basic access authentication. The dr interface (Section 4.3.6) MUST support HTTPS keep-alive and MUST maintain the connection for up to 30 minutes.¶
During the OPTIONAL Qualified Launch Program (QLP) Period (see [QLP-Addendum]), effective allocations of DNs to third parties could require that Registries and Registrars provide Sunrise and/or Trademark Claims services. If required, Registries and Registrars MUST provide Sunrise and/or Trademark Claims services, as described in Sections 5.2 and 5.3.¶
The effective allocation scenarios are as follows:¶
The following table lists all the effective allocation scenarios during a QLP Period:¶
QLP Name Match in the SURL | QLP Name Match in the DNL List | SMD Was Provided by the Potential Registrant | Registry MUST Provide Sunrise or Trademark Claims Services | Registry MUST Report DN Registration in <type> LORDN File |
---|---|---|---|---|
Y | Y | Y | Sunrise | Sunrise |
Y | N | Y | Sunrise | Sunrise |
N | Y | -- | Trademark Claims | Trademark Claims |
N | N | -- | -- | -- |
Y | Y | N (see Section 2.2 of [QLP-Addendum]) | Trademark Claims | Trademark Claims |
Y | N | N (see Section 2.2 of [QLP-Addendum]) | -- | Sunrise (using special SMD-id) |
The TMDB MUST provide the following services to Registries during a QLP Period:¶
The TMDB MUST provide the following services to Registrars during a QLP Period:¶
A new SURL MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC.¶
Registries offering the OPTIONAL QLP Period MUST refresh the latest version of the SURL at least once every 24 hours.¶
Figure 9 depicts the process of downloading the latest SURL initiated by the Registry.¶
Note: The SURL will be the same regardless of the TLD. If a Backend Registry Operator manages the infrastructure of several TLDs, the Backend Registry Operator could refresh the SURL once every 24 hours, and the SURL could be used for all the TLDs managed by the Backend Registry Operator.¶
This section defines the format of the list containing every DNL that matches a Pre-Registered Mark (PRM). The list is maintained by the TMDB and downloaded by Registries in regular intervals (see Section 5.3.3.1). The Registries use the DNL List during the Trademark Claims Period to check whether a requested DN matches a DNL of a PRM.¶
The DNL List contains all the DNLs covered by a PRM present in the TMDB at the datetime that the DNL List is generated.¶
The DNL List is contained in a CSV-formatted file that has the following structure:¶
first line: <version>,<DNL List creation datetime>¶
One or more lines with: <DNL>,<lookup key>,<DNL insertion datetime>¶
Where:¶
<lookup key>: lookup key that the Registry MUST provide to the Registrar. The lookup key has the following format: <YYYY><MM><DD><vv>/<X>/<X>/<X>/<Random bits><Sequential number>, where:¶
Example of a DNL list:¶
To provide authentication and integrity protection, the DNL List will be PGP [RFC4880] signed by the TMDB (see Section 5.1.1.4). The PGP signature of the DNL List can be found in the similar URI but with extension .sig, as shown below.¶
The URLs of the dy interface (Section 4.3.3) are:¶
This section defines the format of the list of SMDs that have been revoked. The list is maintained by the TMDB and downloaded by Registries (and optionally by Registrars) in regular intervals (see Section 5.2.3.1). The SMD Revocation List is used during the Sunrise Period to validate SMDs received. The SMD Revocation List has a similar function as CRLs used in PKI [RFC5280].¶
The SMD Revocation List contains all the revoked SMDs present in the TMDB at the datetime it is generated.¶
The SMD Revocation List is contained in a CSV-formatted file that has the following structure:¶
first line: <version>,<SMD Revocation List creation datetime>¶
One or more lines with: <smd-id>,<revoked SMD datetime>¶
To provide integrity protection, the SMD Revocation List is PGP signed by the TMDB (see Section 5.1.1.4). The SMD Revocation List is provided by the TMDB with extension .csv. The PGP signature of the SMD Revocation List can be found in the similar URI but with extension .sig, as shown below.¶
The URLs of the sr interface (Section 4.3.12) and sy interface (Section 4.3.11) are:¶
Example of an SMD Revocation List:¶
This section defines the format of the List of Registered Domain Names (LORDN), which is maintained by each Registry and uploaded at least daily to the TMDB. Every time there is a DN matching a DNL of a PRM, said DN is added to the LORDN, along with further information related to its registration.¶
The URIs of the yd interface (Section 4.3.7) used to upload the LORDN file are:¶
Sunrise LORDN file:¶
https://<tmdb-domain-name>/LORDN/<TLD>/sunrise¶
Trademark Claims LORDN file:¶
https://<tmdb-domain-name>/LORDN/<TLD>/claims¶
During a QLP Period, Registries MAY be required to upload Sunrise or Trademark Claims LORDN files. The URIs of the yd interface used to upload LORDN files during a QLP Period are:¶
Sunrise LORDN file (during QLP Period):¶
https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/qlp¶
Trademark Claims LORDN file (during a QLP Period):¶
https://<tmdb-domain-name>/LORDN/<TLD>/claims/qlp¶
The yd interface (Section 4.3.7) returns the following HTTP status codes after an HTTP POST request method is received:¶
The interface provides an HTTP/202 status code if the interface was able to receive the LORDN file and the syntax of the LORDN file is correct.¶
The interface provides the LORDN Transaction Identifier in the HTTP Entity-body that would be used by the Registry to download the LORDN Log file. The LORDN Transaction Identifier is a zero-padded natural number in the range 0000000000000000001 to 9223372036854775807.¶
The TMDB uses the <LORDN creation datetime> element of the LORDN file as a unique client-side identifier. If a LORDN file with the same <LORDN creation datetime> of a previously sent LORDN file is received by the TMDB, the LORDN Transaction Identifier of the previously sent LORDN file MUST be provided to the Registry. The TMDB MUST ignore the DN Lines present in the LORDN file if a LORDN file with the same <LORDN creation datetime> was previously sent.¶
The HTTP Location header field contains the URI where the LORDN Log file could be retrieved later, for example:¶
For example, to upload the Sunrise LORDN file for TLD "example", the URI would be:¶
https://<tmdb-domain-name>/LORDN/example/sunrise¶
The LORDN is contained in a CSV-formatted file that has the following structure:¶
For Sunrise Period:¶
first line: <version>,<LORDN creation datetime>,<Number of DN Lines>¶
One or more lines with: <roid>,<DN registered>,<SMD-id>,<IANA Registrar id>,<datetime of registration>,<datetime of application creation>¶
Where:¶
Example of a Sunrise LORDN file:¶
For the Trademark Claims Period:¶
first line: <version>,<LORDN creation datetime>,<Number of DN Lines>¶
One or more lines with: <roid>,<DN registered>,<TCNID>,<IANA Registrar id>,<datetime of registration>,<datetime of acceptance of the TCN>,<datetime of application creation>¶
Where:¶
Example of a Trademark Claims LORDN file:¶
After reception of the LORDN file, the TMDB verifies its content for syntactical and semantic correctness. The output of the LORDN file verification is retrieved using the yd interface (Section 4.3.7).¶
The URIs of the yd interface (Section 4.3.7) used to retrieve the LORDN Log file are:¶
Sunrise LORDN Log file:¶
https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/<lordn-transaction-identifier>/result¶
Trademark Claims LORDN Log file:¶
https://<tmdb-domain-name>/LORDN/<TLD>/claims/<lordn-transaction-identifier>/result¶
A Registry Operator MUST NOT send more than one request per minute per TLD to download a LORDN Log file.¶
The yd interface (Section 4.3.7) returns the following HTTP status codes after an HTTP GET request method is received:¶
For example, to obtain the LORDN Log file in case of a Sunrise LORDN file with LORDN Transaction Identifier 0000000000000000001 and TLD "example", the URI would be:¶
https://<tmdb-domain-name>/LORDN/example/sunrise/0000000000000000001/result¶
The LORDN Log file is contained in a CSV-formatted file that has the following structure:¶
first line: <version>,<LORDN Log creation datetime>,<LORDN file creation datetime>,<LORDN Log Identifier>,<Status flag>,<Warning flag>,<Number of DN Lines>¶
Where:¶
One or more lines with: <roid>,<result code>¶
Where:¶
Example of a LORDN Log file:¶
The classes of result codes (rc) are listed below. The classes in square brackets are not used at this time but may come into use at some later stage. The first two digits of a result code denote the result code class, which defines the outcome at the TMDB:¶
In cases where a DN line is processed and the error result code is 45xx or 46xx, the LORDN file MUST be rejected by the TMDB. If the LORDN file is rejected, DN Lines that are syntactically valid will be reported with a 2001 result code. A 2001 result code means that the DN Line is syntactically valid; however, the DN Line was not processed because the LORDN file was rejected. All DNs reported in a rejected LORDN file MUST be reported again by the Registry because none of the DN Lines present in the LORDN file have been processed by the TMDB.¶
LORDN Log Result Code Classes:¶
Code | Class | Outcome |
---|---|---|
20xx | Success | ok |
35xx | [ DN Line syntax warning ] | warn |
36xx | DN Line semantic warning | warn |
45xx | DN Line syntax error | err |
46xx | DN Line semantic error | err |
In Table 3, the LORDN Log result codes used by the TMDB are described.¶
rc | Short Description / Long Description |
---|---|
2000 | OK |
The DN Line is successfully processed. | |
2001 | OK but not processed |
The DN Line is syntactically correct but was not processed because the LORDN file was rejected. | |
3601 | TCN Acceptance Date after Registration Date |
The TCN Acceptance Date in the DN Line is newer than the registration date. | |
3602 | Duplicate DN Line |
This DN Line is an exact duplicate of another DN Line in the same file; the DN Line is ignored. | |
3603 | DNROID Notified Earlier |
The same DNROID has been notified earlier; the DN Line is ignored. | |
3604 | TCN Checksum invalid |
Based on the DN effective allocation, the TCNID, and the expiration date of the linked TCN, the TCN Checksum is invalid. | |
3605 | TCN Expired |
The TCN was already expired (based on the <tmNotice:notAfter> field of the TCN) at the datetime of acknowledgement. | |
3606 | Wrong TCNID used |
The TCNID used for the registration does not match the related DN. | |
3609 | Invalid SMD used |
The SMD used for registration was not valid at the moment of registration based on the <smd:notBefore> and <smd:notAfter> elements. In case of an asynchronous registration, this refers to the <datetime of application creation>. | |
3610 | DN reported outside of the time window |
The DN was reported outside of the required 26-hour reporting window. | |
3611 | DN does not match the labels in SMD |
The DN does not match the labels included in the SMD. | |
3612 | SMDID does not exist |
The Signed Mark Data Identifier (SMDID) has never existed in the central repository. | |
3613 | SMD was revoked when used |
The SMD used for registration was revoked more than 24 hours ago of the <datetime of registration>. In case of an asynchronous registration, the <datetime of application creation> is used when validating the DN Line. | |
3614 | TCNID does not exist |
The Trademark Claims Notice Identifier (TCNID) has never existed in the central repository. | |
3615 | Recent-dnl-insertion outside of the time window |
The DN registration is reported as a recent-dnl-insertion, but the (re) insertion into the DNL occurred more than 24 hours ago. | |
3616 | Registration Date of DN in Claims before the end of the Sunrise Period |
The registration date of the DN is before the end of the Sunrise Period, and the DN was reported in a Trademark Claims LORDN file. | |
3617 | Registrar has not been approved by the TMDB |
The Registrar ID in the DN Line has not completed Trademark Claims integration testing with the TMDB. | |
3618 | Registration Date of DN in QLP LORDN file out of the QLP Period |
The registration date of the DN in a QLP LORDN file is outside of the QLP Period. | |
3619 | TCN was not valid |
The TCN was not valid (based on the <tmNotice:notBefore> field of the TCN) at the datetime of acknowledgement. | |
4501 | Syntax Error in DN Line |
There is a syntax error in the DN Line. | |
4601 | Invalid TLD used |
The TLD in the DN Line does not match what is expected for this LORDN. | |
4602 | Registrar ID Invalid |
The Registrar ID in the DN Line is not a valid ICANN-Accredited Registrar. | |
4603 | Registration Date in the future |
The <datetime of registration> in the DN Line is in the future. | |
4606 | TLD not in Sunrise or Trademark Claims Periods |
The <datetime of registration> was reported when the TLD was not in Sunrise or Trademark Claims Periods. In case of an asynchronous registration, the <datetime of application creation> is used when validating the DN Line. | |
4607 | Application Date in the future |
The <datetime of application creation> in the DN Line is in the future. | |
4608 | Application Date is later than Registration Date |
The <datetime of application creation> in the DN Line is later than the <datetime of registration>. | |
4609 | TCNID wrong syntax |
The syntax of the TCNID is invalid. | |
4610 | TCN Acceptance Date is in the future |
The <datetime of acceptance of the TCN> is in the future. | |
4611 | Label has never existed in the TMDB |
The label in the registered DN has never existed in the TMDB. |
This section defines the format of the SMD File. After a successful registration of a mark, the TMV returns an SMD File to the TMH. The SMD File can then be used for registration of one or more DNs covered by the PRM during the Sunrise Period of a TLD.¶
Two encapsulation boundaries are defined for delimiting the encapsulated base64-encoded SMD: "-----BEGIN ENCODED SMD-----" and "-----END ENCODED SMD-----". Only data inside the encapsulation boundaries MUST be used by Registries and Registrars for validation purposes, i.e., any data outside these boundaries as well as the boundaries themselves MUST be ignored for validation purposes.¶
The structure of the SMD File is as follows. All the elements are REQUIRED and MUST appear in the specified order.¶
Example of an SMD file:¶
The TMDB MUST provide the TCN to Registrars in XML format, as specified below.¶
The enclosing element <tmNotice:notice> describes the Trademark Notice to a given label.¶
The child elements of the <tmNotice:notice> element include:¶
A <tmNotice:id> element that contains the unique identifier of the Trademark Notice. This element contains the TCNID.¶
Example of a TCNID:¶
Where:¶
The TMDB MUST use the Unix time conversion of the <tmNotice:notAfter> in UTC to calculate the TCN Checksum. Unix time is defined as the number of seconds that have elapsed since 1970-01-01T00:00:00Z, not counting leap seconds. For example, the conversion of 2010-08-16T09:00:00.0Z to Unix time is:¶
An example computation of the TCN Checksum is:¶
One or more <tmNotice:claim> elements that contain the Trademark Claims. The <tmNotice:claim> element contains the following child elements:¶
One or more <tmNotice:holder> elements that contain the information of the holder of the mark. An "entitlement" attribute is used to identify the entitlement of the holder; possible values are: owner, assignee, or licensee. The child elements of <tmNotice:holder> include:¶
A <tmNotice:addr> element that contains the address information of the holder of a mark. <tmNotice:addr> contains the following child elements:¶
Zero or more OPTIONAL <tmNotice:contact> elements that contain the information of the representative of the mark registration. A "type" attribute is used to identify the type of contact; possible values are: owner, agent, or third party. The child elements of <tmNotice:contact> include:¶
A <tmNotice:addr> element that contains the address information of the contact. <tmNotice:addr> contains the following child elements:¶
An OPTIONAL <tmNotice:notExactMatch> element signals that the claim notice was added to the TCN based on rules (e.g., [Claims50]) other than exact match (defined in [MatchingRules]). <tmNotice:notExactMatch> contains one or more of the following:¶
An OPTIONAL <tmNotice:udrp> element that signals that the claim notice was added because of a previously abused name included in a Uniform Domain-Name Dispute-Resolution Policy (UDRP) case. <tmNotice:udrp> contains:¶
An OPTIONAL <tmNotice:court> element that signals that the claim notice was added because of a previously abused name included in a court's resolution. <tmNotice:court> contains:¶
Example of a <tmNotice:notice> object:¶
For the formal syntax of the TCN, please refer to Section 7.1.¶
This section defines the format of the list containing every DNL that matches a PRM eligible for Sunrise. The list is maintained by the TMDB and downloaded by Registries in regular intervals (see Section 5.4.2.1). The Registries use the Sunrise List during the QLP Period to check whether a requested DN matches a DNL of a PRM eligible for Sunrise.¶
The Sunrise List contains all the DNLs covered by a PRM eligible for Sunrise that are present in the TMDB at the datetime it is generated.¶
The Sunrise List is contained in a CSV-formatted file that has the following structure:¶
first line: <version>,<Sunrise List creation datetime>¶
One or more lines with: <DNL>,<DNL insertion datetime>¶
Example of a Sunrise List:¶
To provide authentication and integrity protection, the Sunrise List will be PGP signed by the TMDB (see Section 5.1.1.4). The PGP signature of the Sunrise List can be found in the similar URI but with extension .sig, as shown below.¶
The URLs of the dy interface (Section 4.3.3) are:¶
The schema presented here is for a Trademark Claims Notice.¶
The CODE BEGINS and CODE ENDS tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.¶
<CODE BEGINS> <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="urn:ietf:params:xml:ns:tmNotice-1.0" xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0" xmlns:mark="urn:ietf:params:xml:ns:mark-1.0" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <annotation> <documentation> Schema for representing a Trademark Claim Notice. </documentation> </annotation> <import namespace="urn:ietf:params:xml:ns:mark-1.0"/> <element name="notice" type="tmNotice:noticeType"/> <complexType name="holderType"> <sequence> <element name="name" type="token" minOccurs="0"/> <element name="org" type="token" minOccurs="0"/> <element name="addr" type="tmNotice:addrType"/> <element name="voice" type="mark:e164Type" minOccurs="0"/> <element name="fax" type="mark:e164Type" minOccurs="0"/> <element name="email" type="mark:minTokenType" minOccurs="0"/> </sequence> <attribute name="entitlement" type="mark:entitlementType"/> </complexType> <complexType name="noticeType"> <sequence> <element name="id" type="tmNotice:idType"/> <element name="notBefore" type="dateTime"/> <element name="notAfter" type="dateTime"/> <element name="label" type="mark:labelType"/> <element name="claim" type="tmNotice:claimType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="claimType"> <sequence> <element name="markName" type="token"/> <element name="holder" type="tmNotice:holderType" maxOccurs="unbounded"/> <element name="contact" type="tmNotice:contactType" minOccurs="0" maxOccurs="unbounded"/> <element name="jurDesc" type="tmNotice:jurDescType"/> <element name="classDesc" type="tmNotice:classDescType" minOccurs="0" maxOccurs="unbounded"/> <element name="goodsAndServices" type="token"/> <element name="notExactMatch" type="tmNotice:noExactMatchType" minOccurs="0"/> </sequence> </complexType> <complexType name="jurDescType"> <simpleContent> <extension base="token"> <attribute name="jurCC" type="mark:ccType" use="required"/> </extension> </simpleContent> </complexType> <complexType name="classDescType"> <simpleContent> <extension base="token"> <attribute name="classNum" type="integer" use="required"/> </extension> </simpleContent> </complexType> <complexType name="noExactMatchType"> <choice maxOccurs="unbounded"> <element name="udrp" type="tmNotice:udrpType"/> <element name="court" type="tmNotice:courtType"/> </choice> </complexType> <complexType name="udrpType"> <sequence> <element name="caseNo" type="token"/> <element name="udrpProvider" type="token"/> </sequence> </complexType> <complexType name="courtType"> <sequence> <element name="refNum" type="token"/> <element name="cc" type="mark:ccType"/> <element name="region" type="token" minOccurs="0" maxOccurs="unbounded"/> <element name="courtName" type="token"/> </sequence> </complexType> <complexType name="addrType"> <sequence> <element name="street" type="token" minOccurs="1" maxOccurs="3"/> <element name="city" type="token"/> <element name="sp" type="token" minOccurs="0"/> <element name="pc" type="mark:pcType" minOccurs="0"/> <element name="cc" type="mark:ccType"/> </sequence> </complexType> <complexType name="contactType"> <sequence> <element name="name" type="token"/> <element name="org" type="token" minOccurs="0"/> <element name="addr" type="tmNotice:addrType"/> <element name="voice" type="mark:e164Type"/> <element name="fax" type="mark:e164Type" minOccurs="0"/> <element name="email" type="mark:minTokenType"/> </sequence> <attribute name="type" type="mark:contactTypeType"/> </complexType> <simpleType name="idType"> <restriction base="token"> <pattern value="[a-fA-F0-9]{8}\d{1,19}"/> </restriction> </simpleType> </schema> <CODE ENDS>¶
The code point assigned in support of this document is taken from the wrong point in the registration tree. Unfortunately, the code point has already been deployed in the field without following the proper registration review process. The designated experts for the registry have considered the issues that correcting this action would cause for deployed implementations and have consented to the continued use of the code point.¶
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. IANA has registered two URI assignments as follows.¶
Trademark Claims Notice namespace:¶
Trademark Claims Notice XML schema:¶
This specification uses HTTP Basic Authentication to provide a simple application-layer authentication service. HTTPS is used in all interfaces in order to protect against most common attacks. In addition, the client identifier is tied to a set of IP addresses that are allowed to connect to the interfaces described in this document, providing an extra security measure.¶
The TMDB MUST provide credentials to the appropriate Registries and Registrars.¶
The TMDB MUST require the use of strong passwords by Registries and Registrars.¶
The TMDB, Registries, and Registrars MUST use the best practices described in [RFC9325] or its successors.¶
This specification defines the interfaces to support the [RPM-Requirements]. Legal documents govern the interactions between the different parties, and such legal documents must ensure that privacy-sensitive and/or personal data receives the required protection.¶
This specification is a collaborative effort from several participants in the ICANN community. Bernie Hoeneisen participated as a coauthor for the first draft version of this document, providing invaluable support. This specification is based on a model spearheaded by Chris Wright, Jeff Neuman, Jeff Eckhaus, and Will Shorter. The author would also like to thank the thoughtful feedback provided by many in the tmch-tech mailing list but particularly the extensive help provided by James Gould, James Mitchell, and Francisco Arias. This document includes feedback received from Paul Hoffman.¶