TMCH functional specifications
draft-lozano-tmch-func-spec-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Gustavo Lozano Ibarra , Bernie Hoeneisen | ||
| Last updated | 2013-04-10 | ||
| Replaced by | draft-ietf-eppext-tmch-func-spec, draft-ietf-eppext-tmch-func-spec | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lozano-tmch-func-spec-04
Internet Engineering Task Force G. Lozano, Ed.
Internet-Draft ICANN
Intended status: Informational B. Hoeneisen
Expires: October 10, 2013 Ucom.ch
April 08, 2013
TMCH functional specifications
draft-lozano-tmch-func-spec-04
Abstract
This document describes the requirements, the architecture and the
interfaces between the Trademark Clearing House (TMCH) and Domain
Name Registries as well as between the TMCH and Domain Name
Registrars for the provisioning and management of domain names during
Sunrise and Trademark Claims Period of a domain name Registry.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2013.
Copyright Notice
Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Lozano & Hoeneisen Expires October 10, 2013 [Page 1]
Internet-Draft TMCH functional specifications April 2013
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Trademark Claims Period . . . . . . . . . . . . . . . . . 10
4.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. hv . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. vd . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.3. dy . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.4. tr . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.5. ry . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.6. dr . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.7. yd . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.8. dv . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.9. vh . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.10. vs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.11. sy . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.12. sr . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.13. vc . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.14. cy . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.15. cr . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Process Descriptions . . . . . . . . . . . . . . . . . . . . . 14
5.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Registries . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1.1. Credentials . . . . . . . . . . . . . . . . . . . 14
5.1.1.2. IP Addresses for Access Control . . . . . . . . . 14
5.1.1.3. TMCH Trust Anchor . . . . . . . . . . . . . . . . 14
5.1.1.4. TMDB/SMDM PGP Key . . . . . . . . . . . . . . . . 15
5.1.2. Registrars . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2.1. Credentials . . . . . . . . . . . . . . . . . . . 15
5.1.2.2. IP Addresses for Access Control . . . . . . . . . 15
5.1.2.3. TMCH Trust Anchor . . . . . . . . . . . . . . . . 16
5.1.2.4. TMDB PGP Key . . . . . . . . . . . . . . . . . . . 16
5.2. Sunrise Period . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. Domain Registration . . . . . . . . . . . . . . . . . 17
5.2.2. DN Registration by Registries . . . . . . . . . . . . 18
5.2.3. TMCH Sunrise Services for Registries . . . . . . . . . 20
5.2.3.1. SMD Revocation List . . . . . . . . . . . . . . . 20
5.2.3.2. Certificate Revocation List . . . . . . . . . . . 21
5.2.3.3. Notice of Registered Domain Names . . . . . . . . 22
5.2.4. DN registration by Registrars . . . . . . . . . . . . 24
Lozano & Hoeneisen Expires October 10, 2013 [Page 2]
Internet-Draft TMCH functional specifications April 2013
5.2.5. TMCH Sunrise Services for Registrars . . . . . . . . . 24
5.3. Trademark Claims Period . . . . . . . . . . . . . . . . . 25
5.3.1. Domain Registration . . . . . . . . . . . . . . . . . 25
5.3.2. DN registration by Registries . . . . . . . . . . . . 26
5.3.3. Trademark Claims Services for Registries . . . . . . . 28
5.3.3.1. Domain Name Label (DNL) List . . . . . . . . . . . 28
5.3.3.2. Notice of Registered Domain Names . . . . . . . . 28
5.3.4. DN Registration by Registrars . . . . . . . . . . . . 29
5.3.5. Trademark Claims Services for Registrars . . . . . . . 30
5.3.5.1. Claims Notice Information Service . . . . . . . . 30
6. Data Format Descriptions . . . . . . . . . . . . . . . . . . . 31
6.1. DNL List file . . . . . . . . . . . . . . . . . . . . . . 31
6.2. SMD revocation list . . . . . . . . . . . . . . . . . . . 33
6.3. LORDN File . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3.1. LORDN Log File . . . . . . . . . . . . . . . . . . . . 38
6.3.1.1. LORDN Result Codes . . . . . . . . . . . . . . . . 41
6.4. SMD File . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.5. Trademark Claims Notice . . . . . . . . . . . . . . . . . 46
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Trademark Claims Notice . . . . . . . . . . . . . . . . . 50
8. Status of this Draft . . . . . . . . . . . . . . . . . . . . . 52
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
11. Security Considerations . . . . . . . . . . . . . . . . . . . 53
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.1. Normative References . . . . . . . . . . . . . . . . . . . 53
12.2. Informative References . . . . . . . . . . . . . . . . . . 53
Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Lozano & Hoeneisen Expires October 10, 2013 [Page 3]
Internet-Draft TMCH functional specifications April 2013
1. Introduction
Domain Name Registries may operate in special modes within certain
periods of time to facilitate registration of domain names.
Along with the upcoming introduction of new generic Top Level Domains
(gTLD), two special modes will come into effect:
o Sunrise Period
o Trademark Claims Period
The Sunrise and Trademark Claims Periods are defined in the gTLD
Applicant Guidebook [ICANN-GTLD-AGB-20120604].
This document describes the requirements, the architecture and the
interfaces between the Trademark Clearing House (TMCH) and Domain
Name Registries as well as between the TMCH and Domain Name
Registrars for the provisioning and management of domain names during
the Sunrise and Trademark Claims Periods.
After the Terminology (Section 2) the Glossary (Section 3) is listed,
followed by the architecture (Section 4) and the different process
descriptions (Section 5). Afterwards, in Section 6, the necessary
Data Formats are defined, followed by their formal syntax
(Section 7).
For any date and/or time indications, Coordinated Universal Time
(UTC) applies.
1.1. Discussion
Any interested parties are invited to contribute to the discussion of
this draft and provide feedback. The discussion currently takes
place on the tmch-tech discussion list <tmch-tech@icann.org>.
Interested parties can subscribe to this mailing list via
< https://mm.icann.org/mailman/listinfo/tmch-tech >.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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
Lozano & Hoeneisen Expires October 10, 2013 [Page 4]
Internet-Draft TMCH functional specifications April 2013
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.
3. Glossary
In the following the most common terms are briefly explained:
o Effective allocation: A DN is considered effectively allocated
when the DN object for the DN has been created in the SRS of the
Registry and has been assigned to the effective user. A DN object
in status "pendingCreate" or any other status that precedes the
first time a DN is assigned to an end-user is not considered an
effective allocation. A DN object created internally by the
Registry for subsequent delegation to another Registrant is not
considered an effective allocation.
o Backend Registry Operator: Entity that manages (a part of) the
technical infrastructure for a Registry Operator. The Registry
Operator may also be the Backend Registry Operator.
o CA: Certificate Authority, see [RFC5280] and [RFC6818]
o CSV: Comma-Separated Values, see [RFC4180]
o CNIS, Claims Notice Information Service: This service provides
trademark claims notices to Registrars.
o CRC32, Cyclic Redundancy Check: algorithm used in the ISO 3309
standard and in section 8.1.1.6.2 of ITU-T recommendation V.42.
o CRL: Certificate Revocation List, see [RFC5280] and [RFC6818].
o Date and time, datetime: Date and time are specified following the
standard "Date and Time on the Internet specification", see
[RFC3339].
o DN: Domain Name, see [RFC1034]
o DNS: Domain Name System, see [RFC1034]
o DNL, Domain Name Label: A label as specified in [RFC1035]. For
IDNs the A-Label is used [RFC5890].
Lozano & Hoeneisen Expires October 10, 2013 [Page 5]
Internet-Draft TMCH functional specifications April 2013
o DNL List: A list of DNL that are covered by a PRM.
o EPP: Extensible Provisioning Protocol, see [RFC5730].
o FQDN: Fully Qualified Domain Name (e.g. myname.example.com)
o HTTP: Hypertext Transfer Protocol, see [RFC2616]
o HTTPS: HTTP over TLS (Transport Layer Security), [RFC5246].
o ICANN-CA: ICANN's Certificate Authority (CA); Trust Anchor for the
SMD PKI model.
o IDN: Internationalized Domain Name, see [RFC5890]
o LORDN, List of Registered Domain Names: This is the list of
effectively allocated domain names matching a DNL of a PRM that
Registries daily upload to the TMDB (during the NORDN process).
o Lookup Key: A random string of up to 64 chars from the set [a-zA-
Z0-9/] to be used as the lookup Key by Registrars to obtain the
claims notice using the CNIS. Lookup Keys are unique and are
related to one DNL only.
o NORDN, Notification of Registered Domain Names: The process by
which Registries daily upload their recent LORDN to the TMDB.
o PGP: Pretty Good Privacy, see [RFC4880]
o PKI: Public Key Infrastructure, see [RFC5280] and [RFC6818]
o PRM, Pre-registered mark: Mark that has been pre-registered with
the TMCH.
o Registrant: Person or Organization registering a Domain Name via a
Registrar.
o Registrar, Domain Name Registrar: Entity that registers Domain
Names with the Registry on behalf of the Registrant.
o Registry, Registry Operator, Domain Name Registry: Entity that
accepts Domain Name registrations from Registrars, maintains the
central Database of Registered Domains. A Registry Operator is
the contracting party for the TLD.
o SMD, Signed Mark Data: A cryptographically signed token issued by
the TMV to the TMH to be used in the Sunrise Period to apply for a
Domain Name that matches a DNL of a PRM; see also
Lozano & Hoeneisen Expires October 10, 2013 [Page 6]
Internet-Draft TMCH functional specifications April 2013
[I-D.lozano-tmch-smd]
o SMD File: A file containing the SMD (see above) and some human
readable data. The latter is usually ignored in the processing of
the SMD File. See also Section 6.4.
o SMDM, SMD Manager: A entity managing the SMDs, mainly maintaining
lists of revoked SMDs; see also [I-D.lozano-tmch-smd]
o SMD revocation list: The SMD revocation list is used by Registries
(and optionally by Registrars) during the Sunrise Period to ensure
that an SMD is still valid (i.e. not revoked). The SMD revocation
list has a similar function as CRLs used in PKI.
o SRS: Shared Registration System, see also
[ICANN-GTLD-AGB-20120604].
o Sunrise Period: During this period Domain Names matching a DNL of
a PRM can be exclusively obtained by the respective mark holders.
For domain names matching a PRM, a special process applies to
ensure a TMH gets informed on the effective allocation of a domain
name matching his/her PRM. Every launch of a new gTLD Registry
starts with a Sunrise Period, followed by a Trademark Claims
Period.
o TLD: Top Level Domain Name, see [RFC1591]
o Trademark, mark: Marks are used to claim exclusive properties of
products or services. A mark is typically a name, word, phrase,
logo, symbol, design, image, or a combination of these elements.
For the scope of this document only textual marks are relevant.
o Trademark Claims, Claims: Provides information to enhance the
understanding of the Trademark rights being claimed by the
Trademark Holder.
o Trademark Claims Notice, Claims Notice, Trademark Notice, TCN: A
Trademark Claims Notice consist of one or more Trademark Claims
and are provided to prospective Registrants of Domain Names.
o Trademark Claims Notice Identifier, Claims Notice Identifier,
Claims Notice ID, TCNID: An element of the Trademark Claims Notice
(see above), identifying said Claims Notice. The Trademark Claims
Notice identifier is specified in the element <tmNotice:id>.
o Trademark Claims Period: During this period, a special process
applies to DNs matching the DNL list, to ensure a TMH gets
informed of a domain name matching his PRM. For DNs matching the
Lozano & Hoeneisen Expires October 10, 2013 [Page 7]
Internet-Draft TMCH functional specifications April 2013
DNL list, Registrars show a Trademark Claims Notice to prospective
Registrants that has to be acknowledged before effective
allocation.
o TMCH, Trademark Clearinghouse: The Trademark Clearinghouse is an
ICANN central repository for information to be authenticated,
stored, and disseminated, pertaining to the rights of trademark
holders. The Clearinghouse is split into two functions TMV and
TMDB (see below). There could be several entities performing the
TMV function, but only one entity performing the TMDB function.
o TMDB, Trademark Clearinghouse Database: Serves as a database of
the TMCH to provide information to the new gTLD Registries and
Registrars to support Sunrise or Trademark Claims Services. There
is only one TMDB in the TMCH that concentrates the information
about the "verified" Trademark records from the TMVs.
o TMH, Trademark Holder: The person or organization owning rights on
a Trademark.
o TMV, Trademark Validator, Trademark validation organization: An
entity authorized by ICANN to authenticate and validate
registrations in the TMDB ensuring the marks qualify as registered
or are court-validated marks or marks that are protected by
statute or treaty. This entity would also be asked to ensure that
proof of use of marks is provided, which can be demonstrated by
furnishing a signed declaration and one specimen of current use.
o UTC: Coordinated Universal Time, as maintained by the Bureau
International des Poids et Mesures (BIPM); see also [RFC3339].
Lozano & Hoeneisen Expires October 10, 2013 [Page 8]
Internet-Draft TMCH functional specifications April 2013
4. Architecture
4.1. Sunrise Period
Architecture Sunrise Period
SMD hand over (out of band;
trivial if Registrant == TMH)
...........................................
: :
: .'''''''''''''''''''. :
: . TMCH . :
: ..................... :
v . . :
.------------. . .-------------. . hv .-----.
| Registrant | . | TMV |<------->| TMH |
'------------' . '-------------' . vh '-----'
| . | ^ \ .
| . | | \.
tr | . vs | | \
| . | | dv .\
v . v | . \
.-----------. sr . .---. | . \
.->| Registrar |<.........| S | vd | . \
: '-----------' . | M | | . \
: | sy . | D | v . \
: ry | .-----------| M | .---. . vc \
: | | . '---' | T | . \
: v v . | M | . v
: .-----------. . | D | . .----------.
: | Registry |----------------->| B | . | ICANN-CA |
: '-----------' . yd '---' . '----------'
: ^ . . | :
: | ''''''''''''''''''' | :
: | cy | :
: cr '---------------------------------------' :
:.....................................................:
Figure 1
Lozano & Hoeneisen Expires October 10, 2013 [Page 9]
Internet-Draft TMCH functional specifications April 2013
4.2. Trademark Claims Period
Architecture Trademark Claims Period
.'''''''''''''.
. TMCH .
...............
. .
.------------. . .-------. . hv .-----.
| Registrant | . | TMV |<------->| TMH |
'------------' . '-------' . vh '-----'
| . ^ .
tr | . | dv .
| . vd | .
v . v .
.-----------. dr . .-------. .
| Registrar |<--------| T | .
'-----------' . | | .
| . | M | .
ry | . | | .
v . | D | .
.----------. dy . | | .
| Registry |<------->| B | .
'----------' yd . '-------' .
. .
'''''''''''''
Figure 2
Lozano & Hoeneisen Expires October 10, 2013 [Page 10]
Internet-Draft TMCH functional specifications April 2013
4.3. Interfaces
In the sub-sections below follows a short description of each
interface to provide an overview of the architecture. More detailed
descriptions of the relevant interfaces follow further below
(Section 5).
4.3.1. hv
The TMH registers a mark with a TMV via the hv interface.
After the successful registration of the mark, the TMV makes
available a SMD (Signed Mark Data) file (see also 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.
4.3.2. vd
After successful mark registration, the TMV ensures the TMDB inserts
the corresponding DNLs and mark information into the database via the
vd interface.
The specifics of the vd interface are beyond the scope of this
document.
4.3.3. dy
Not used during the Sunrise Period.
During the Trademark Claims Period the Registry fetches the latest
DNL list from the TMDB via the dy interface in regular intervals.
The protocol used on the dy interface is HTTPS.
4.3.4. tr
The Registrant communicates with the Registrar via the tr interface.
The specifics of the tr interface are beyond the scope of this
document.
4.3.5. ry
The Registrar communicate with the Registry via the ry interface.
The ry interfaces is typically implemented in EPP [RFC5730]. A TMCH
specific EPP standard extension is yet to be developed.
Lozano & Hoeneisen Expires October 10, 2013 [Page 11]
Internet-Draft TMCH functional specifications April 2013
4.3.6. dr
Not used during the Sunrise Period.
During the Trademark Claims Period the Registrar fetches the
Trademark Claims Notice from the TMDB (to be displayed to the
Registrant via the tr interface) via the dr interface. The protocol
used for fetching the Trademark Claims Notice is HTTPS [RFC2818].
4.3.7. yd
During the Sunrise period the Registry notifies the TMDB daily via
the yd interface of all domain names effectively allocated.
During the Trademark Claims period, the Registry notifies daily the
TMDB via the yd interface of all domains effectively allocated that
matched an entry in the Registry's DNL during the creation of the
domain name.
The protocol used on the yd interface is HTTPS.
4.3.8. dv
The TMDB notifies via the dv interface to the TMV of all domains
effectively allocated that match a mark registered by that TMV.
The specifics of the dv interface are beyond the scope of this
document.
4.3.9. vh
The TMV notifies the TMH via the vh interface after a domain has been
effectively allocated that matches a PRM of this TMH.
The specifics of the vh interface are beyond the scope of this
document.
4.3.10. vs
The TMV requests to add a revoked SMD to the list of revoked SMDs at
the SMDM.
The specifics of the vs interface are beyond the scope of this
document.
Not relevant during the Trademark Claims Period.
Lozano & Hoeneisen Expires October 10, 2013 [Page 12]
Internet-Draft TMCH functional specifications April 2013
4.3.11. sy
During the Sunrise Period the Registry fetches the most recent list
of revoked SMDs from the SMDM via the sy interface in regular
intervals. The protocol used on the sy interface is HTTPS.
Not relevant during the Trademark Claims Period.
4.3.12. sr
During the Sunrise Period the Registrar may fetch the most recent
list of revoked SMDs from the SMDM via the sr interface. The
protocol used on the sr interface is the same as on the sy interface
(s. above), i.e. HTTPS.
Not relevant during the Trademark Claims Period.
4.3.13. vc
The TMV requests to add a revoked TMV certificate to the CRL at the
ICANN-CA via the vc interface.
The specifics of the vc interface are beyond the scope of this
document.
Not relevant during the Trademark Claims Period.
4.3.14. cy
During the Sunrise Period the Registry fetches the most recent CRL
from the ICANN-CA via the cy interface in regular intervals. The CRL
is mainly used for validation of TMV certificates. The protocol used
on the cy interface is HTTPS [RFC2818].
Not relevant during the Trademark Claims Period.
4.3.15. cr
During the Sunrise Period the Registrar may fetch the most recent CRL
from the ICANN-CA via the cr interface. The protocol used on the cr
interface is the same as on the cy interface (s. above).
Not relevant during the Trademark Claims Period.
Lozano & Hoeneisen Expires October 10, 2013 [Page 13]
Internet-Draft TMCH functional specifications April 2013
5. Process Descriptions
5.1. Bootstrap
5.1.1. Registries
5.1.1.1. Credentials
Each Registry will receive authentication credentials from the TMDB/
SMDM to be used:
o During the Sunrise Period to fetch the lists of revoked SMDs from
the SMDM via the sy interface (Section 4.3.11).
o During Trademark Claims Period to fetch the lists of DNLs from the
TMDB via the dy interface (Section 4.3.3).
o During the NORDN process to notify the LORDN to the TMDB via the
yd interface (Section 4.3.7).
Note: credentials are created per TLD and provided to the Registry
Operator.
5.1.1.2. IP Addresses for Access Control
Each Registry Operator MUST provide to the TMDB all IP addresses that
will be used to:
o Fetch the list of revoked SMDs via the sy interface
(Section 4.3.11).
o Fetch the lists of DNLs from the TMDB via the dy interface
(Section 4.3.3).
o Notify the LORDN to the TMDB via the yd interface (Section 4.3.7).
This access restriction MAY be applied by the TMDB/SMDM in addition
to HTTP Basic access authentication (for credentials to be used, see
Section 5.1.1.1).
The TMDB/SMDM MAY limit the number of IP addresses to be accepted per
Registry Operator.
5.1.1.3. TMCH Trust Anchor
Each Registry MUST fetch the X.509 certificate ([RFC5280] /
[RFC6818]) of the ICANN-CA (Trust Anchor) from
< https://ca.icann.org/tmch.crt > to be used:
Lozano & Hoeneisen Expires October 10, 2013 [Page 14]
Internet-Draft TMCH functional specifications April 2013
o During the Sunrise Period to validate the TMV certificates and the
CRL of TMV certificates.
5.1.1.4. TMDB/SMDM PGP Key
The TMDB MUST provide each Registry with the public portion of the
PGP Key used by TMDB and SMDM, to be used:
o During the Sunrise Period to perform integrity checking of the
list of revoked SMDs fetched from the SMDM via the sy interface
(Section 4.3.11).
o During Trademark Claims Period to perform integrity checking of
the list of DNL fetched from the TMDB via the dy interface
(Section 4.3.3).
5.1.2. Registrars
5.1.2.1. Credentials
Each ICANN-accredited Registrar will receive authentication
credentials from the TMDB to be used:
o During the Sunrise Period to (optionally) fetch the lists of
revoked SMDs from the SMDM via the sr interface (Section 4.3.12).
o During Trademark Claims Period to fetch Claims Notices from the
TMDB via the dr interface (Section 4.3.6).
5.1.2.2. IP Addresses for Access Control
Each Registrar MUST provide to the TMDB all IP addresses, which will
be used to:
o Fetch the list of revoked SMDs via the sr interface
(Section 4.3.12).
o Fetch Trademark Claims Notices via the dr interface
(Section 4.3.6).
This access restriction MAY be applied by the TMDB/SMDM 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.
Lozano & Hoeneisen Expires October 10, 2013 [Page 15]
Internet-Draft TMCH functional specifications April 2013
5.1.2.3. TMCH Trust Anchor
Registrars MAY fetch the X.509 certificate ([RFC5280] / [RFC6818]) of
the ICANN-CA (Trust Anchor) from < https://ca.icann.org/tmch.crt > to
be used:
o During the Sunrise Period to (optionally) validate the TMV's
certificates and the CRL of TMV certificates.
5.1.2.4. TMDB PGP Key
Registrars MUST receive the public portion of the PGP Key used by
TMDB and SMDM from the TMDB administrator to be used:
o During the Sunrise Period to (optionally) perform integrity
checking of the list of revoked SMDs fetched from the SMDM via the
sr interface (Section 4.3.12).
Lozano & Hoeneisen Expires October 10, 2013 [Page 16]
Internet-Draft TMCH functional specifications April 2013
5.2. Sunrise Period
5.2.1. Domain Registration
Registration during Sunrise Period
.------------. .-----------. .----------.
| Registrant | | Registrar | | Registry |
'------------' '-----------' '----------'
^ | | |
| | Request DN | |
| | Registration | |
| | (with SMD) | |
| |------------->| Check DN availability |
| | |---------------------------->|
| | | |
| | DN unava. | DN unavailable .-------------.
'---|<-------------|<--------------------( DN available? )
| | no '-------------'
| | | yes
| | DN available |
| |<----------------------------|
| | |
| | Request DN registration |
| | (with SMD) |
| |---------------------------->|
| | |
| | .------------------------------.
| | | DN registration validation / |
| | | SMD validation |
| | '------------------------------'
| Registration | |
| Error |.-----------. Error .----------------------.
|<-------------|| TRY AGAIN |<------( Validation successful? )
| || / ABORT | no '----------------------'
| |'-----------' | yes
| | |
| | DN registered |
| DN regist. |<----------------------------|
|<-------------| |
| | |
Figure 3
Lozano & Hoeneisen Expires October 10, 2013 [Page 17]
Internet-Draft TMCH functional specifications April 2013
5.2.2. DN Registration by Registries
Registries MUST perform a minimum set of checks for verifying DN
registrations during Sunrise Period upon reception of a registration
request over the ry interface (Section 4.3.5). If any of these
checks fails 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 domain name application) used for DN registration. If the
minimum set of checks is performed when creating the intermediate
object (e.g. a domain name application) a Registry MAY effective
allocate the DN without performing the minimum set of checks again.
However, the validation of the SMD compared to the moment of
effective allocation of the DN MUST NOT be older than a period of
time, i.e., the SMD-validation validity period that is defined in the
RPM requirements document referenced in Specification 7 of the gTLD
Applicant Guidebook [ICANN-GTLD-AGB-20120604].
Performing the minimum set of checks Registries MUST verify that:
1. A SMD has been received from the Registrar along with the DN
registration.
2. The certificate of the TMV has been correctly signed by the
ICANN-CA. (The certificate of the TMV is contained within the
SMD.)
3. The validity period of the TMV certificate is within the allowed
range.
4. The certificate of the TMV is not be listed in the CRL file
specified in the CRL distribution point of the TMV certificate.
5. The signature of the SMD (signed with the TMV certificate) is
valid.
6. The validity period of the SMD is within the allowed range (<smd:
notBefore> and <smd:notAfter> elements).
7. The SMD has not been revoked, i.e., is not contained in the SMD
revocation list.
8. The leftmost DNS label (A-label in case of IDNs) of the DN being
effectively allocated matches one of the labels (<mark:label>)
elements in the SMD.
Lozano & Hoeneisen Expires October 10, 2013 [Page 18]
Internet-Draft TMCH functional specifications April 2013
These procedure 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.
Lozano & Hoeneisen Expires October 10, 2013 [Page 19]
Internet-Draft TMCH functional specifications April 2013
5.2.3. TMCH Sunrise Services for Registries
5.2.3.1. SMD Revocation List
A new SMD revocation list MUST be published by the SMDM twice a day,
by 00:00 and 12: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, the SMD Revocation List could be used for
all the TLDs managed by the Backend Registry Operator.
Update SMD revocation list
.----------. .------.
| Registry | | SMDM |
'----------' '------'
| |
.----------------. |
| Periodically, | |
| at least | |
| every 24 hours | |
'----------------' |
| |
|----------------------------------------------------->|
| Download latest revocation list for SMD certificates |
|<-----------------------------------------------------|
| |
| |
Figure 4
Lozano & Hoeneisen Expires October 10, 2013 [Page 20]
Internet-Draft TMCH functional specifications April 2013
5.2.3.2. Certificate Revocation List
Registries MUST refresh their local copy of the CRL at least every 24
hours using the CRL distribution point specified in the TMV
certificate.
Operationally, the CRL file and CRL distribution point is the same
for all TMVs and (at publication of this document) located at
< http://crl.icann.org/tmch.crl >.
Note: the 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 CRL file once every
24 hours, the CRL file could be used for all the TLDs managed by the
Backend Registry Operator.
Update CRL for TMV certificates
.----------. .----------.
| Registry | | ICANN-CA |
'----------' '----------'
| |
.----------------. |
| Periodically, | |
| at least | |
| every 24 hours | |
'----------------' |
| |
|------------------------------------------->|
| Download latest CRL for TMV certificates |
|<-------------------------------------------|
| |
| |
Figure 5
Lozano & Hoeneisen Expires October 10, 2013 [Page 21]
Internet-Draft TMCH functional specifications April 2013
5.2.3.3. Notice of Registered Domain Names
The Registry MUST send a LORDN file containing DNs effectively
allocated to the TMDB (over the yd interface, Section 4.3.7).
The registration of a DN MUST be reported by the Registry to the TMDB
within 24 hours of the effective allocation.
The Registry MUST send LORDN files for DNs effectively allocated
during Sunrise or Claims period.
The yd interface (Section 4.3.7) MAY support up to 10 concurrent
connections from each IP address registered by a Registry Operator to
access the service.
The TMDB MUST process each uploaded LORDN file within 30 minutes of
the finalization of the upload and have the response indicating the
errors and warnings to the Registry.
Lozano & Hoeneisen Expires October 10, 2013 [Page 22]
Internet-Draft TMCH functional specifications April 2013
NORDN
.----------. .------. .-----. .-----.
| Registry | | TMDB | | TMV | | TMH |
'----------' '------' '-----' '-----'
| | | |
.------------------. .-----------. | |
| Periodically; | | Wait for |<-------. | |
| at least | | LORDN | | | |
| every 24 hours | '-----------' | | |
'------------------' | | | |
| | | | |
.--------->| Upload LORDN | | | |
| |-------------------->| | | |
| | | | | |
| | .-------------------------. | | |
| | | Verify each domain name | | | |
| | | in the uploaded file | | | |
| | | (within 30') | | | |
| | '-------------------------' | | |
| | | | | |
| | Download log file | | | |
| |<--------------------| | | |
| | | | | |
| .-----------------. .---------------. | | |
| | Check whether | / everything fine \ no | | |
| | log file | ( (i.e. no errors )----' | |
| | contains errors | \ in log file )? / | |
| '-----------------' '---------------' | |
| | | yes | |
| .---------------. | | |
| / everything fine \ yes | | |
|( (i.e. no errors )-----. | Notify TMVs | |
| \ in log file )? / | | on the LORDN | |
| '---------------' | | pre-registered | |
| | no v | with said TMV | |
| .----------------. .------. |--------------->| |
'-| Correct Errors | | DONE | | | |
'----------------' '------' | | Notify each |
| | | affected TMH |
| | |------------->|
| | | |
Figure 6
The format used for the LORDN is described in Section 6.3
Lozano & Hoeneisen Expires October 10, 2013 [Page 23]
Internet-Draft TMCH functional specifications April 2013
5.2.4. DN registration by Registrars
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.
5.2.5. TMCH Sunrise Services for Registrars
The processes described in Section 5.2.3.1 and Section 5.2.3.2 are
also available for Registrars to optionally validate the SMDs
received.
Lozano & Hoeneisen Expires October 10, 2013 [Page 24]
Internet-Draft TMCH functional specifications April 2013
5.3. Trademark Claims Period
5.3.1. Domain Registration
Registration during Trademark Claims Period
.------------. .-----------. .----------. .------.
| Registrant | | Registrar | | Registry | | TMDB |
'------------' '-----------' '----------' '------'
^ | Request DN | | |
| | Registration | Check DN availability | |
| |------------->|---------------------------->| |
| | DN unava. | DN unavailable .-------------. |
'---|<-------------|<--------------------( DN available? ) |
| | no '-------------' |
| | | yes |
| | DN available | |
| |<----------------------------| |
| | Request Lookup key | |
| |---------------------------->| |
| | .---------. |
| |.----------. / Does DN \ |
| || CONTINUE |<---------( match DNL ) |
| || NORMALLY | no \ of PRM? / |
| |'----------' '---------' |
| | | yes |
| | Lookup key | |
| |<----------------------------| |
| | Request Claims Notice |
| Display |----------------------------------------->|
| Claims | |
| Notice | Return Claims Notice |
|<-------------|<-----------------------------------------|
| | |
.------. yes | Register DN (TCNID included) |
( Ack? )--------->|---------------------------->| |
'------' | | |
||no | Error .----------------------. |
|| .-------. |<--------------( Validation successful? ) |
|'->| ABORT | | no '----------------------' |
| '-------' | | yes |
| DN regist. | DN registered | |
|<-------------|<----------------------------| |
| | | |
Figure 7
Lozano & Hoeneisen Expires October 10, 2013 [Page 25]
Internet-Draft TMCH functional specifications April 2013
5.3.2. DN registration by Registries
During Trademark Claim Periods, Registries perform two main
functions:
o Registries MUST provide Registrars (over the ry interface,
Section 4.3.5) the Lookup Key used to retrieve the Trademark
Claims for domain names that match the DNL list.
o Registries MUST provide the Lookup Key only when queried about a
specific DN.
o For any DN matching a DNL of a PRM, Registries MUST perform a
minimum set of checks for verifying DN registrations during
Trademark Claims Period upon reception of a registration request
over the ry interface (Section 4.3.5). If any of these checks
fails the Registry MUST abort the registration. Each of these
checks MUST be performed before the DN is effectively allocated.
o In case of asynchronous registrations (e.g. auctions), the minimum
set of checks MAY be performed when creating the intermediate
object (e.g. a domain name application) used for DN effective
allocation. If the minimum set of checks is performed when
creating the intermediate object (e.g. a domain name application)
a Registry MAY effective allocate the DN without performing the
minimum set of checks again. However, the acknowledgement of the
Trademark Notice compared to the moment of effective allocation of
the DN MUST NOT be older than a period of time, i.e., the TCN-Ack
validity period that is defined in the RPM requirements document
referenced in Specification 7 of the gTLD Applicant Guidebook
[ICANN-GTLD-AGB-20120604].
o Performing the minimum set of checks Registries MUST verify that:
1. The Claims Notice Identifier, expiration datetime and
acceptance datetime of the Trademark Notice, 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 re-inserted) for the first time into 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.
2. The claim notice has not expired (according to the expiration
datetime sent by the Registrar).
Lozano & Hoeneisen Expires October 10, 2013 [Page 26]
Internet-Draft TMCH functional specifications April 2013
3. The acceptance datetime is no more than 48 hours in the past.
4. Using the leftmost DNS label (A-label in the case of IDNs) of
the DN being effectively allocated, the expiration datetime
provided by the registrar and the TMDB identifier extracted
from the Claims Notice identifier provided by the registrar
compute the checksum. Verify using that the checksum match
the checksum present in the Claims Notice identifier (see, <
xref="procDescClaimsNotice" />).
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.
Lozano & Hoeneisen Expires October 10, 2013 [Page 27]
Internet-Draft TMCH functional specifications April 2013
5.3.3. Trademark Claims Services for Registries
5.3.3.1. Domain Name Label (DNL) List
A new DNL list MUST be published by the TMDB twice a day, by 00:00
and 12:00 UTC.
Registries MUST refresh the latest version of the DNL list at least
once every 24 hours.
Update DNL list
.----------. .------.
| Registry | | TMDB |
'----------' '------'
| |
.----------------. |
| Periodically, | |
| at least | |
| every 24 hours | |
'----------------' |
| |
|-------------------------------->|
| Download latest list of DNLs |
|<--------------------------------|
| |
| |
Figure 8
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, the DNL List could be used for all the TLDs managed by the
Backend Registry Operator.
5.3.3.2. Notice of Registered Domain Names
The NORDN process during the Trademark Claims Period is almost the
same as during Sunrise Period as defined in Section 5.2.3.3 with the
difference 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) are included in the LORDN.
If reporting the LORDN of the day when the Registry transition from
the Sunrise Period to Trademark Claims Period, the TMDB MUST support
Lozano & Hoeneisen Expires October 10, 2013 [Page 28]
Internet-Draft TMCH functional specifications April 2013
receiving two LORDN files for the same date. A Registry MAY submit
two LORDN files, for Sunrise and Claims, respectively.
5.3.4. DN Registration by Registrars
For any DN matching a DNL of a PRM, Registrars MUST perform the
following steps:
1. Use the Lookup Key received from the Registry to obtain the
Claims Notice from the TMDB using the dr interface
(Section 4.3.6) Registrars MUST only query for the Lookup Key of
a DN that is available for registration.
2. Present the Claims Notice to the Registrant as described in
[ICANN-GTLD-AGB-20120604].
3. Ask Registrant for acknowledgement, i.e. the Registrant MUST
consent with the Claims Notice, before any further processing.
(The transmission of a Trademark Claims Identifier to the
Registry over the ry interface, Section 4.3.5 implies that the
Registrant has expressed his consent with the Claims Notice.)
4. Perform the minimum set of checks for verifying DN registrations.
If any of these checks fails 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 that:
1. The claim notice has not expired (using expiration date
(<tmNotice:notAfter>).
2. The claim notice validity based on the (<tmNotice:
notBefore>).
3. The leftmost DNS label (A-label in case of IDNs) of the DN
being effectively allocated matches the label (<tmNotice:
label>) element in the Trademark Claim Notice.
4. The Registrant has acknowledged (expressed his consent with)
the Claims Notice.
5. Record the date and time when the registrant acknowledged the
trademark claims notice.
6. Send the registration to the Registry (ry interface,
Section 4.3.5) and include the following information:
Lozano & Hoeneisen Expires October 10, 2013 [Page 29]
Internet-Draft TMCH functional specifications April 2013
* Trademark Claims Identifier (<tmNotice:id>)
* Expiration date of the claims notice (<tmNotice:notAfter>)
* Acceptance datetime of the trademark claims notice.
Claims notices are generated twice a day. The expiration date
(<tmNotice:notAfter>) of each claims notice MUST be set to 48 hours
in the future, allowing the implementation of a cache by Registrars
and enough time for acknowledging the TM notice. Registrars SHOULD
implement a cache of claims notices to minimize the number of queries
sent to the TMDB. A cached TM Notice MUST be removed from the cache
after the expiration date of the TM notice as defined by <tmNotice:
notAfter>. The TMDB MAY implement rate-limiting as one of the
protection mechanisms to mitigate the risk of performance
degradation.
5.3.5. Trademark Claims Services for Registrars
5.3.5.1. Claims Notice Information Service
The Trademark Claims Notices 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 Trademark Claims Notices, 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 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 Trademark Claims Notice.
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 (Section 4.3.6) interface MUST support
HTTPS keep-alive and MUST maintain the connection for up to 30
minutes.
Lozano & Hoeneisen Expires October 10, 2013 [Page 30]
Internet-Draft TMCH functional specifications April 2013
6. Data Format Descriptions
6.1. DNL List file
This section defines format of the list containing every Domain Name
Label (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
matched a DNL of a PRM.
The DNL list is contained in a CSV-like formatted file that has the
following structure:
o first line: <version>,<DNL list creation datetime>
Where:
+ <version>, version of the file. Version 1 MUST always be
present.
+ <DNL list creation datetime>, date and time in UTC that the
DNL was created.
o second line: a header line as specified in [RFC4180]
With the header names as follows:
DNL,lookup-key,insertion-datetime
o One or more lines with: <DNL>,<lookup key>,<DNL insertion
datetime>
Where:
+ <DNL>, a domain label covered by a trademark.
+ <lookup key>, lookup key that the registry MUST provide to
the registrar.
+ <DNL insertion datetime>, datetime in UTC that the DNL was
first inserted into the DNL. The possible two values of
time for inserting a DNL to the DNL list are 00:00 and 12:00
UTC.
Lozano & Hoeneisen Expires October 10, 2013 [Page 31]
Internet-Draft TMCH functional specifications April 2013
Example for DNL list
1,2012-08-16T00:00:00.0Z
DNL,lookup-key,insertion-datetime
example,j8f/KR6/Dex/dac5KfYddfEr,2010-07-14T00:00:00.0Z
another-example,lj3/l4F/33F/f4HGgg42l5Ts,2012-08-16T00:00:00.0Z
anotherexample,h7h/nm9/FEJ/iHH82mkj3d2c,2011-08-16T12:00:00.0Z
Figure 9
To provide authentication and integrity protection, the DNL list will
be PGP [RFC4880] signed by the TMDB with the private key of the TMDB
(see also 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 URL of the dy interface (Section 4.3.3) is:
o < https://<tmdb-domain-name>/dnl/dnl-latest.csv >
o < https://<tmdb-domain-name>/dnl/dnl-latest.sig >
Lozano & Hoeneisen Expires October 10, 2013 [Page 32]
Internet-Draft TMCH functional specifications April 2013
6.2. SMD revocation list
This section defines format of the list of SMDs that have been
revoked. The list is maintained by the SMDM 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] / [RFC6818].
The SMD revocation list is contained in a CSV-like formatted file
that has the following structure:
o first line: <version>,<SMD revocation list creation datetime>
Where:
+ <version>, version of the file. Version 1 MUST always be
present.
+ <SMD revocation list creation datetime>, datetime in UTC
that the SMD revocation list was created.
o second line: a header line as specified in [RFC4180]
With the header names as follows:
smd-id,insertion-datetime
o One or more lines with: <smd-id>,<revoked smd datetime>
Where:
+ <smd-id>, identifier of the SMD that was revoked.
+ <revoked smd datetime>, revocation datetime in UTC of the
SMD. The possible two values of time for inserting a DNL to
the DNL list are 00:00 and 12:00 UTC.
To provide integrity protection, the SMD revocation list is PGP
[RFC4880] signed by the TMDB with the private key of the TMDB (see
also 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 URL of the sr interface (Section 4.3.12) and sy interface
(Section 4.3.11) is:
Lozano & Hoeneisen Expires October 10, 2013 [Page 33]
Internet-Draft TMCH functional specifications April 2013
o < https://<tmdb-domain-name>/smdrl/smdrl-latest.csv >
o < https://<tmdb-domain-name>/smdrl/smdrl-latest.sig >
Example for SMD Revocation list
1,2012-08-16T00:00:00.0Z
smd-id,insertion-datetime
2-2,2012-08-15T00:00:00.0Z
3-2,2012-08-15T00:00:00.0Z
1-2,2012-08-15T00:00:00.0Z
Figure 10
Lozano & Hoeneisen Expires October 10, 2013 [Page 34]
Internet-Draft TMCH functional specifications April 2013
6.3. LORDN File
This section defines the format of the List of Registered Domain
Names (LORDN), which is maintained by each Registry and uploaded
daily to the TMDB. Every time a DN matching a DNL of a PRL said DN
is added to the LORDN along with further information related to its
registration.
The URI of the dy interface (Section 4.3.3) used to upload the LORDN
file is:
o Sunrise LORDN file:
< https://<tmdb-domain-name>/LORDN/<TLD>/sunrise >
o Claims LORDN file:
< https://<tmdb-domain-name>/LORDN/<TLD>/claims >
For example, to upload the Sunrise LORDN file for TLD "example",
the URI would be:
< https://<tmdb-domain-name>/LORDN/example/sunrise >
After uploading a LORDN file, the TMDB MUST return a LORDN
transaction identifier that is used by the Registry to download the
LORDN Log file.
The LORDN is contained in a CSV-like formatted file that has the
following structure:
o For Sunrise Period:
* first line: <version>,<LORDN creation datetime>,<Number of
lines>
Where:
- <version>, version of the file. Version 1 MUST always be
present.
- <LORDN creation datetime>, date and time in UTC that the
LORDN was created.
- <Number of lines>, number of domain names allocated on
the reporting date <date of registration>.
Lozano & Hoeneisen Expires October 10, 2013 [Page 35]
Internet-Draft TMCH functional specifications April 2013
* second line: a header line as specified in [RFC4180]
With the header names as follows:
roid,domain-name,SMD-id,registrar-id,registration-
datetime,application-datetime
* One or more lines with: <roid>,<DN registered>,<smd-id>, <IANA
registrar id>,<datetime of registration>,<datetime of
application creation>
Where:
- <roid>, Repository Object IDentifier (ROID) in the SRS.
- <DN registered>, domain name that was allocated.
- <SMD-id>, SMD ID used when the domain was allocated.
- <IANA registrar ID>, IANA registrar ID.
- <datetime of registration>, date and time in UTC that the
domain was allocated.
- OPTIONAL <datetime of application creation>, date and
time in UTC that the application was created, in case of
a DN effective allocation based on an asynchronous
registration (e.g., when using auctions).
Example for LORDN during Sunrise
1,2012-08-16T00:00:00.0Z,3
roid,domain-name,SMD-id,registrar-id,registration-datetime,\
application-datetime
SH8013-REP,example1.gtld,1-2,9999,2012-08-15T13:20:00.0Z,\
2012-07-15T00:50:00.0Z
EK77-REP,example2.gtld,2-2,9999,2012-08-15T14:00:03.0Z
HB800-REP,example3.gtld,3-2,9999,2012-08-15T15:40:00.0Z
Figure 11
o For Trademark Claims Period:
* first line: <version>,<LORDN creation datetime>,<Number of
lines>
Lozano & Hoeneisen Expires October 10, 2013 [Page 36]
Internet-Draft TMCH functional specifications April 2013
Where:
- <version>, version of the file. Version 1 MUST always be
present.
- <LORDN creation datetime>, date and time in UTC that the
LORDN was created.
- <Number of lines>, number of domain names allocated on
the reporting date <date of registration>.
* second line: a header line as specified in [RFC4180]
With the header names as follows:
roid,domain-name,notice-id,registrar-id,registration-
datetime,ack-datetime,application-datetime
* One or more lines with: <roid>,<DN registered>,<TM notice ID>,
<IANA registrar id>,<datetime of registration>,<datetime of
acceptance of the TM notice>,< datetime of application
creation>
Where:
- <roid>, Repository Object IDentifier (ROID) in the SRS.
- <DN registered>, domain name that was allocated.
- <TM notice ID>, trademark notice identifier as specified
in <tmNotice:id>.
- <IANA registrar ID>, IANA registrar ID.
- <datetime of registration>, date and time in UTC that the
domain was allocated.
- <datetime of acceptance of the TM notice>, date and time
in UTC that the TM notice was acknowledged.
- OPTIONAL <datetime of application creation>, date and
time in UTC that the application was created, in case of
a DN effective allocation based on an asynchronous
registration (e.g., when using auctions).
For a DN matching a DNL of a PRM at the moment of
registration, created without the Claims Notice Identifier,
expiration datetime and acceptance datetime, because DNL was
Lozano & Hoeneisen Expires October 10, 2013 [Page 37]
Internet-Draft TMCH functional specifications April 2013
inserted (or re-inserted) for the first time into DNL list
less than 24 hours ago, the string "recent-dnl-insertion"
MAY be specified in <TM notice ID> and <datetime of
acceptance of the TM notice>.
Example for LORDN during Claims
1,2012-08-16T00:00:00.0Z,3
roid,domain-name,notice-id,registrar-id,registration-datetime,\
ack-datetime,application-datetime
SH8013-REP,example1.gtld,a76716ed9223352036854775808,\
9999,2012-08-15T14:20:00.0Z,2012-08-15T13:20:00.0Z
EK77-REP,example2.gtld,a7b786ed9223372036856775808,\
9999,2012-08-15T11:20:00.0Z,2012-08-15T11:19:00.0Z
HB800-REP,example3.gtld,recent-dnl-insertion,\
9999,2012-08-15T13:20:00.0Z,recent-dnl-insertion
Figure 12
6.3.1. LORDN Log File
After reception of the LORDN File, the TMDB verifies its content for
syntactical and semantical correctness. The output of the LORDN File
verification is retrieved using the dy interface (Section 4.3.3).
The URI of the dy interface (Section 4.3.3) used to retrieve the
LORDN Log File is:
o Sunrise LORDN Log file:
< https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/
<lordn-transaction-identifier>/result >
o Claims LORDN Log file:
< https://<tmdb-domain-name>/LORDN/<TLD>/claims/
<lordn-transaction-identifier>/result >
For example, to obtain the LORN Log File in case of a Sunrise
LORDN file with transaction identifier 0000000000000001 and TLD
"example" the URI would be:
< https://<tmdb-domain-name>/LORDN/example/sunrise/
0000000000000001/result >
Lozano & Hoeneisen Expires October 10, 2013 [Page 38]
Internet-Draft TMCH functional specifications April 2013
A Registry Operator MUST NOT send more than one request per minute
per TLD to download a LORDN Log file.
The LORDN log file is contained in a CSV-like formatted file that has
the following structure:
o first line: <version>,<LORDN Log creation datetime><LORDN file
creation datetime>, <LORDN Log identifier>,<Status flag>,<Warning
flag>,<Number of lines>
Where:
+ <version>, version of the file. Version 1 MUST always be
present.
+ <LORDN Log creation datetime>, date and time in UTC that the
LORDN Log was created.
+ <LORDN file creation datetime>, date and time in UTC of
creation for the LORDN file that this log file is referring
to.
+ <LORDN Log identifier>, unique identifier of the LORDN Log
provided by the TMDB. This identifier could be used by the
Registry Operator to unequivocally identify the LORDN Log.
The identified will be a string of a maximum LENGTH of 60
characters from the Base 64 alphabet.
+ <Status flag>, whether the LORDN file has been accepted for
processing by the TMDB. Possible values are "accepted" or
"rejected".
+ <Warning flag>, whether the LORDN Log has any warning result
codes. Possible values are "no-warnings" or "warnings-
present".
+ <Number of lines>, number of DNs effective allocations
processed in the LORDN file.
A Registry Operator is NOT REQUIRED to process a LORDN Log with
a <Status flag>="accepted" and <Warning flag>="no-warnings".
o second line: a header line as specified in [RFC4180]
With the header names as follows:
roid,result-code
Lozano & Hoeneisen Expires October 10, 2013 [Page 39]
Internet-Draft TMCH functional specifications April 2013
o One or more lines with: <roid>,<result code>
Where:
+ <roid>, Repository Object IDentifier (ROID) in the SRS.
+ <result code>, result code as described in Section 6.3.1.1.
Example for LORDN Log file
1,2012-08-16T02:15:00.0Z,2012-08-16T00:00:00.0Z,\
0000000000000478Nzs+3VMkR8ckuUynOLmyeqTmZQSbzDuf/R50n2n5QX4=,\
accepted,no-warnings,1
roid,result-code
SH8013-REP,2000
Figure 13
Lozano & Hoeneisen Expires October 10, 2013 [Page 40]
Internet-Draft TMCH functional specifications April 2013
6.3.1.1. LORDN Result Codes
In Figure 14 the classes of result codes (rc) are listed. Those
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:
o ok: Success, domain name line accepted
o warn: a warning is issued, domain name line accepted
o err: an error is issued, LORDN file rejected
LORDN Result Code Classes
code Class outcome
---- ----- -------
20xx Success ok
33xx [ header line syntax warning ] warn
34xx [ header line semantic warning ] warn
35xx [ domain name line syntax warning ] warn
36xx domain name line semantic warning warn
43xx header information syntax error err
44xx header information semantic error err
45xx domain name line syntax error err
46xx domain name line semantic error err
Figure 14
In the following the LORDN result codes used by the TMDB are
described:
LORDN result Codes
rc Short Description
Long Description
---- ------------------------------------------------------------
2000 OK
Domain Name line successfully processed
3601 TCN Acceptance Date after Registration Date
Lozano & Hoeneisen Expires October 10, 2013 [Page 41]
Internet-Draft TMCH functional specifications April 2013
TCN Acceptance Date in Domain Name is newer than the
Registration Date
3602 Duplicate DN Line
This DN Line is an exact duplicate of another line in same
file, DN line ignored
3603 ROID Notified Earlier
Same ROID has been notified earlier, DN line ignored
3604 Checksum Invalid
Based on the DN allocated, the TMC-ID and
the expiration date of the linked TM notice, the
checksum is invalid.
3605 TMC-ID Expired
Trademark Claim Notice Identifier was expired
when accepted, but still accepted.
In case of an asynchronous registration, this may refer
to the date of the application creation.
3606 Wrong TMC-ID used
The TMC-ID used for the registration was not valid
for this DN.
3607 SMD-Validation too old
The validation of the SMD was done outside of the SMD-validation
validity period, and still was used for registration.
3608 TCN-Acknowledgement too old
The Acknowledgement of the TCN was done outside of the TCN-Ack
validity period, and still was used for registration.
3609 Invalid SMD used
The SMD used for registration was not valid. In case of
an asynchronous registration, this may refer to the date of
the application creation.
3610 DN reported outside of the time window
The DN was reported outside of the required 24 hours reporting window.
4301 Syntax Error in Header
Syntax Error in Header information.
4401 Domain Name Count Mismatch
The number of Domain Names in Header does not match
the count of DN lines
Lozano & Hoeneisen Expires October 10, 2013 [Page 42]
Internet-Draft TMCH functional specifications April 2013
4402 Creation Date in the future
Creation Date of LORDN file is in the future
4501 Syntax Error in DN line
Syntax Error in Domain Name line
4601 Invalid TLD used
The TLD in the DN line does not match what is expected for this LORDN
4602 Registrar ID Invalid
Registrar ID in DN line is not valid (ICANN-Accredited Registrar)
4603 Registration Date in the future
Registration Date in the DN line is in the future
4604 DN/application reported for Sunrise but TLD is in Claims
The DN datetime of registration or datetime of application creation was reported
during Sunrise but the TLD was in Claims
4605 DN/application reported for Claims but TLD is in Sunrise
The DN datetime of registration or datetime of application creation was reported
during Claims but the TLD was in Sunrise
4606 DN/application reported for Sunrise/Claims but TLD is not in Sunrise nor Claims
The DN datetime of registration or datetime of application creation was reported
during Sunrise/Claims but the TLD was not in Sunrise nor Claims
Figure 15
Lozano & Hoeneisen Expires October 10, 2013 [Page 43]
Internet-Draft TMCH functional specifications April 2013
6.4. SMD File
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: i.e. "-----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:
o Marks: <marks>
o smdID: <smd-ID>
o U-labels: <comma separated list of U-labels>
o notBefore: <begin validity>
o notAfter: <end validity>
o -----BEGIN ENCODED SMD-----
o <encoded SMD (see [I-D.lozano-tmch-smd])>
o -----END ENCODED SMD-----
Lozano & Hoeneisen Expires October 10, 2013 [Page 44]
Internet-Draft TMCH functional specifications April 2013
Example for SMD File (shortened at [...]):
Marks: Example One
smdID: 1-2
U-labels: example-one, exampleone
notBefore: 2011-08-16 09:00
notAfter: 2012-08-16 09:00
-----BEGIN ENCODED SMD-----
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWdu
ZWRNYXJrIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRN
YXJrLTEuMCIgaWQ9InNpZ25lZE1hcmsiPgogIDxzbWQ6aWQ+MS0yPC9zbWQ6aWQ+
CiAgPHNtZDppc3N1ZXJJbmZvIGlzc3VlcklEPSIyIj4KICAgIDxzbWQ6b3JnPkV4
YW1wbGUgSW5jLjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+c3VwcG9ydEBleGFt
cGxlLnRsZDwvc21kOmVtYWlsPgogICAgPHNtZDp1cmw+aHR0cDovL3d3dy5leGFt
cGxlLnRsZDwvc21kOnVybD4KICAgIDxzbWQ6dm9pY2UgeD0iMTIzNCI+KzEuNzAz
NTU1NTU1NTwvc21kOnZvaWNlPgogIDwvc21kOmlzc3VlckluZm8+CiAgPHNtZDpu
b3RCZWZvcmU+MjAwOS0wOC0xNlQwOTowMDowMC4wWjwvc21kOm5vdEJlZm9yZT4K
ICA8c21kOm5vdEFmdGVyPjIwMTAtMDgtMTZUMDk6MDA6MDAuMFo8L3NtZDpub3RB
ZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhcmFtczp4
[...]
UFMxOWw3REJLcmJ3YnpBZWEvMGpLV1Z6cnZtVjdUQmZqeEQzQVFvMVIKYlU1ZEJy
NklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVyaWh5aVVScEZEcHdIOEtBSDF3TWND
cFhHWEZSdEdLawp3eWRneVZZQXR5N290a2wvejNiWmtDVlQzNGdQdkY3MHNSNitR
eFV5OHUwTHpGNUEvYmVZYVpweFNZRzMxYW1MCkFkWGl0VFdGaXBhSUdlYTlsRUdG
TTBMOStCZzdYek5uNG5WTFhva3lFQjNiZ1M0c2NHNlF6blgyM0ZHazwvWDUwOUNl
cnRpZmljYXRlPgo8L1g1MDlEYXRhPgogICAgPC9LZXlJbmZvPgogIDwvU2lnbmF0
dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo=
-----END ENCODED SMD-----
Figure 16
Lozano & Hoeneisen Expires October 10, 2013 [Page 45]
Internet-Draft TMCH functional specifications April 2013
6.5. Trademark Claims Notice
The TMDB MUST provide the Trademark Claim Notice to Registrars in XML
format as specified below.
An enclosing element <tmNotice:notice> that describes the Trademark
Notice to a given label.
The child elements of the <tmNotice:notice> element include:
o A <tmNotice:id> element that contains the unique identifier of the
Trademark Notice.
The Trademark Notice identifier is a concatenation of a
checksum and the TMDB identifier. The first 8 characters of
the Trademark Notice identifier is a checksum. The rest is the
TMDB identifier, which is a zero-padded number in the range of
1 to 9223372036854775808.
Example of a Trademark Notice identifier
a7b216ed9223372036854775808.
Where:
+ Checksum=a7b216ed
+ TMDB identifier=9223372036854775808
The checksum is a 8 characters long Base16 encoded output of
computing the CRC32 of the string concatenation of: label +
unix_timestamp(<tmNotice:notAfter>) + TMDB identifier
The TMDB uses the <tmNotice:label> and <tmNotice:notAfter>
elements from the Trademark Notice along with the TMDB
identifier to compute the checksum.
A registry MUST use the leftmost DNS label (A-label in case of
IDNs) of the DN being effectively allocated, the expiration
datetime of the Trademark Notice and the TMDB identifier
extracted from the Trademark Notice identifier provided by the
Registrar to compute the checksum. For example the DN
"foo.bar.example" being effectively allocated, the left most
label would be "foo".
Example of computation of the checksum: CRC32(example-
one12819492009223372036854775808)=a7b216ed
Lozano & Hoeneisen Expires October 10, 2013 [Page 46]
Internet-Draft TMCH functional specifications April 2013
o A <tmNotice:notBefore> element that contains the start of the
validity date and time of the TM notice.
o A <tmNotice:notAfter> element that contains the expiration date
and time of the TM notice.
o A <tmNotice:label> elements that contain the DNS label (A-label in
case of IDNs) form of the label that correspond to the DN covered
by a PRM.
o One or more <tmNotice:claim> elements that contain the claim. The
<tmNotice:claim> element contains the following child elements:
* A <tmNotice:markName> element that contains the mark text
string.
* One or more <tmNotice:holder> elements that contains 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 and licensee.
* Zero or more OPTIONAL <tmNotice:contact> elements that contains
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 thirdparty.
* A <tmNotice:jurDesc> element that contains the name (in
English) of the jurisdiction where the trademark is protected.
A jurCC attribute contains the two-character code of the
jurisdiction where the trademark was registered. This is a
two-character code from [WIPO.ST3].
* Zero or more OPTIONAL <tmNotice:classDesc> element that
contains the description (in English) of the Nice
Classification as defined in [WIPO-NICE-CLASSES]. A classNum
attribute contains the class number.
* A <tmNotice:goodsAndServices> element that contains the full
description of the goods and services mentioned in the mark
registration document.
Lozano & Hoeneisen Expires October 10, 2013 [Page 47]
Internet-Draft TMCH functional specifications April 2013
Example of <tmNotice:notice> object:
<?xml version="1.0" encoding="UTF-8"?>
<tmNotice:notice xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0">
<tmNotice:id>a7b216ed9223372036854775808</tmNotice:id>
<tmNotice:notBefore>2010-08-14T09:00:00.0Z</tmNotice:notBefore>
<tmNotice:notAfter>2010-08-16T09:00:00.0Z</tmNotice:notAfter>
<tmNotice:label>example-one</tmNotice:label>
<tmNotice:claim>
<tmNotice:markName>Example One</tmNotice:markName>
<tmNotice:holder entitlement="owner">
<tmNotice:org>Example Inc.</tmNotice:org>
<tmNotice:addr>
<tmNotice:street>123 Example Dr.</tmNotice:street>
<tmNotice:street>Suite 100</tmNotice:street>
<tmNotice:city>Reston</tmNotice:city>
<tmNotice:sp>VA</tmNotice:sp>
<tmNotice:pc>20190</tmNotice:pc>
<tmNotice:cc>US</tmNotice:cc>
</tmNotice:addr>
</tmNotice:holder>
<tmNotice:contact type="owner">
<tmNotice:name>Joe Doe</tmNotice:name>
<tmNotice:org>Example Inc.</tmNotice:org>
<tmNotice:addr>
<tmNotice:street>123 Example Dr.</tmNotice:street>
<tmNotice:street>Suite 100</tmNotice:street>
<tmNotice:city>Reston</tmNotice:city>
<tmNotice:sp>VA</tmNotice:sp>
<tmNotice:pc>20190</tmNotice:pc>
<tmNotice:cc>US</tmNotice:cc>
</tmNotice:addr>
<tmNotice:voice x="4321">+1.7035555555</tmNotice:voice>
<tmNotice:email>jdoe@example.com</tmNotice:email>
</tmNotice:contact>
<tmNotice:jurDesc jurCC="US">UNITED STATES OF AMERICA</tmNotice:jurDes>
<tmNotice:classDesc classNum="35">
Advertising; business management; business administration.
</tmNotice:classDesc>
<tmNotice:classDesc classNum="36">
Insurance; financial affairs; monetary affairs; real estate.
</tmNotice:classDesc>
<tmNotice:goodsAndServices>
Bardus populorum circumdabit se cum captiosus populum.
Smert populorum circumdabit se cum captiosus populum qui eis differimus.
</tmNotice:goodsAndServices>
</tmNotice:claim>
Lozano & Hoeneisen Expires October 10, 2013 [Page 48]
Internet-Draft TMCH functional specifications April 2013
<tmNotice:claim>
<tmNotice:markName>Example-One</tmNotice:markName>
<tmNotice:holder entitlement="owner">
<tmNotice:org>Example S.A. de C.V.</tmNotice:org>
<tmNotice:addr>
<tmNotice:street>Calle conocida #343</tmNotice:street>
<tmNotice:city>Conocida</tmNotice:city>
<tmNotice:sp>SP</tmNotice:sp>
<tmNotice:pc>82140</tmNotice:pc>
<tmNotice:cc>BR</tmNotice:cc>
</tmNotice:addr>
</tmNotice:holder>
<tmNotice:jurDesc jurCC="BR">BRAZIL</tmNotice:jurDesc>
<tmNotice:goodsAndServices>
Bardus populorum circumdabit se cum captiosus populum.
Smert populorum circumdabit se cum captiosus populum qui eis differimus.
</tmNotice:goodsAndServices>
</tmNotice:claim>
</tmNotice:notice>
This example generates a TRADEMARK NOTICE with two mark claims.
For formal syntax of the Trademark Claims Notice please refer to
Section 7.1.
Lozano & Hoeneisen Expires October 10, 2013 [Page 49]
Internet-Draft TMCH functional specifications April 2013
7. Formal Syntax
7.1. Trademark Claims Notice
The schema presented here is for the Trademark Claims Notice.
Copyright (c) 2012 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
BEGIN
<?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>
Lozano & Hoeneisen Expires October 10, 2013 [Page 50]
Internet-Draft TMCH functional specifications April 2013
Schema for representing a Trademark Notice.
</documentation>
</annotation>
<import namespace="urn:ietf:params:xml:ns:mark-1.0"
schemaLocation="mark-1.0.xsd"/>
<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"/>
</sequence>
</complexType>
<complexType name="jurDescType">
<simpleContent>
<extension base="token">
<attribute name="jurCC" type="mark:ccType" use="required"/>
</extension>
</simpleContent>
</complexType>
<complexType name="classDescType">
Lozano & Hoeneisen Expires October 10, 2013 [Page 51]
Internet-Draft TMCH functional specifications April 2013
<simpleContent>
<extension base="token">
<attribute name="classNum" type="integer" use="required"/>
</extension>
</simpleContent>
</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>
END
8. Status of this Draft
This draft is the product of several discussions regarding the
interaction between the TMCH and Registries/Registrars. It does by
no means claim to be complete and minor updates are likely to be
added in future versions of this document.
9. Acknowledgements
TBD
Lozano & Hoeneisen Expires October 10, 2013 [Page 52]
Internet-Draft TMCH functional specifications April 2013
10. IANA Considerations
TBD
11. Security Considerations
TBD
12. References
12.1. Normative References
[I-D.lozano-tmch-smd]
Lozano, G., "Mark and Signed Mark Objects Mapping",
draft-lozano-tmch-smd-02 (work in progress), March 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[ICANN-GTLD-AGB-20120604]
ICANN, "gTLD Applicant Guidebook Version 2012-06-04",
June 2012, <http://newgtlds.icann.org/en/applicants/agb/
guidebook-full-04jun12-en.pdf>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1591] Postel, J., "Domain Name System Structure and Delegation",
RFC 1591, March 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
Randers-Pehrson, "GZIP file format specification version
4.3", RFC 1952, May 1996.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Lozano & Hoeneisen Expires October 10, 2013 [Page 53]
Internet-Draft TMCH functional specifications April 2013
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180, October 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, August 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 6818, January 2013.
[WIPO-NICE-CLASSES]
WIPO, "Nice List of Classes", <http://www.wipo.int/
classifications/nivilo/nice/index.htm>.
[WIPO.ST3]
WIPO, "Recommended standard on two-letter codes for the
representation of states, other entities and
intergovernmental organizations", March 2007.
Appendix A. Document Changelog
[RFC Editor: This section is to be removed before publication]
Lozano & Hoeneisen Expires October 10, 2013 [Page 54]
Internet-Draft TMCH functional specifications April 2013
Authors' Addresses
Gustavo Lozano (editor)
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles 90292
US
Phone: +1.3103015800
Email: gustavo.lozano@icann.org
Bernie Hoeneisen
Ucom Standards Track Solutions GmbH
CH-8000 Zuerich
Switzerland
Phone: +41 44 500 52 44
Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: http://www.ucom.ch/
Lozano & Hoeneisen Expires October 10, 2013 [Page 55]