[要約] RFC 9361は、ICANN商標クリアリングハウス（TMCH）の機能仕様を定義し、ドメイン登録所や登録機関とのインターフェースを提供することで、サンライズ期間や商標クレーム期間中のドメイン名の提供と管理を支援することを目的としています。
Independent Submission G. Lozano
Request for Comments: 9361 ICANN
Category: Informational March 2023
ISSN: 2070-1721
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.
このドキュメントでは、ICANNトレードマーククリアリングハウス（TMCH）とドメイン名レジストリ間の要件、アーキテクチャ、および日の出および商標請求期間中のドメイン名のプロビジョニングと管理のためのICANN TMCHとドメイン名レジストラの間のインターフェイスについて説明します。。
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.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開されることが承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9361で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Terminology
3. Glossary
4. Architecture
4.1. Sunrise Period
4.2. Trademark Claims Period
4.3. Interfaces
4.3.1. hv
4.3.2. vd
4.3.3. dy
4.3.4. tr
4.3.5. ry
4.3.6. dr
4.3.7. yd
4.3.8. dv
4.3.9. vh
4.3.10. vs
4.3.11. sy
4.3.12. sr
4.3.13. vc
4.3.14. cy
4.3.15. cr
5. Process Descriptions
5.1. Bootstrapping
5.1.1. Bootstrapping for Registries
5.1.1.1. Credentials
5.1.1.2. IP Addresses for Access Control
5.1.1.3. ICANN TMCH Trust Anchor
5.1.1.4. TMDB PGP Key
5.1.2. Bootstrapping for Registrars
5.1.2.1. Credentials
5.1.2.2. IP Addresses for Access Control
5.1.2.3. ICANN TMCH Trust Anchor
5.1.2.4. TMDB PGP Key
5.2. Sunrise Period
5.2.1. Domain Name Registration
5.2.2. Sunrise Domain Name Registration by Registries
5.2.3. TMDB Sunrise Services for Registries
5.2.3.1. SMD Revocation List
5.2.3.2. TMV Certificate Revocation List (CRL)
5.2.3.3. Notice of Registered Domain Names (NORDN)
5.2.4. Sunrise Domain Name Registration by Registrars
5.2.5. TMDB Sunrise Services for Registrars
5.3. Trademark Claims Period
5.3.1. Domain Registration
5.3.2. Trademark Claims Domain Name Registration by Registries
5.3.3. TMDB Trademark Claims Services for Registries
5.3.3.1. Domain Name Label (DNL) List
5.3.3.2. Notice of Registered Domain Names (NORDN)
5.3.4. Trademark Claims Domain Name Registration by Registrars
5.3.5. TMDB Trademark Claims Services for Registrars
5.3.5.1. Claims Notice Information Service (CNIS)
5.4. Qualified Launch Program (QLP) Period
5.4.1. Domain Registration
5.4.2. TMDB QLP Services for Registries
5.4.2.1. Sunrise List (SURL)
6. Data Format Descriptions
6.1. Domain Name Label (DNL) List
6.2. SMD Revocation List
6.3. List of Registered Domain Names (LORDN) File
6.3.1. LORDN Log File
6.3.1.1. LORDN Log Result Codes
6.4. Signed Mark Data (SMD) File
6.5. Trademark Claims Notice (TCN)
6.6. Sunrise List (SURL)
7. Formal Syntax
7.1. Trademark Claims Notice (TCN)
8. IANA Considerations
9. Security Considerations
10. Privacy Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Author's Address
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).
ドメイン名レジストリは、一定期間特別なモードで動作する場合があり、トップレベルドメイン（TLD）の導入中に商標所有者が権利を保護できるようになります。
Along with the introduction of new generic TLDs (gTLDs), two special modes came into effect:
新しいジェネリックTLD（GTLD）の導入に加えて、2つの特別なモードが施行されました。
* Sunrise Period: The Sunrise Period allows Trademark Holders an advance opportunity to register domain names corresponding to their marks before names are generally available to the public.
* 日の出期間：日の出期間により、商標所有者は、一般的に一般に公開される前に、マークに対応するドメイン名を登録する事前の機会を許可します。
* Trademark Claims Period: The Trademark Claims Period follows the Sunrise Period and runs for at least the first 90 days of an initial operating period of general registration. During the Trademark Claims Period, anyone attempting to register a domain name matching a mark that is recorded in the ICANN Trademark Clearinghouse (TMCH) will receive a notification displaying the relevant mark information.
* 商標請求期間：商標請求期間は日の出期間に続き、少なくとも一般的な登録の最初の90日間は実行されます。商標請求期間中、ICANN商標Clearinghouse（TMCH）に記録されているマークに一致するドメイン名を登録しようとする人は、関連するマーク情報を表示する通知を受け取ります。
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.
このドキュメントでは、ICANN TMCHとドメイン名レジストリ（ドキュメントの残りの「レジストリ」と呼ばれる）の要件、アーキテクチャ、およびICANN TMCHとドメイン名レジストラの間のインターフェイス（「レジストラ」と呼ばれるインターフェイスについて説明します。ドキュメントの残りの部分）は、日の出および商標請求期間中のドメイン名のプロビジョニングと管理のため。
For any date and/or time indications, Coordinated Universal Time (UTC) applies.
任意の日付および/または時間の適応について、調整されたユニバーサル時間（UTC）が適用されます。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
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.
XMLはケースに敏感です。特に明記しない限り、このドキュメントで提供されるXMLの仕様と例は、適合実装を開発するために提示されたキャラクターケースで解釈する必要があります。
"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.
「Tmnotice-1.0」は、「urn：ietf：params：xml：ns：tmnotice-1.0」の略語として使用されます。XML NameSpaceのプレフィックス「Tmnotice」が使用されますが、実装はそれに依存してはならず、代わりにXMLドキュメントを解釈および出力するために、適切な名前空間認識XMLパーサーとシリアイザーを使用してはなりません。
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.
[W3C.REC-XML-20081126]で説明されているように、拡張可能なマークアップ言語（XML）1.0、およびXMLスキーマ表記、[w3c.rec-xmlschema-1-20041028]および[w3c.rec-xmlschema-2-で説明されているように20041028]、この仕様で使用されています。
In the following section, the most common terms are briefly explained:
次のセクションでは、最も一般的な用語を簡単に説明します。
Backend Registry Operator:
バックエンドレジストリオペレーター：
An entity that manages (a part of) the technical infrastructure for a Registry Operator. The Registry Operator may also be the Backend Registry Operator.
レジストリオペレーターの技術インフラストラクチャを管理する（一部）エンティティ。レジストリオペレーターは、バックエンドレジストリオペレーターでもあります。
CA:
CA：
Certification Authority. See [RFC5280].
認証局。[RFC5280]を参照してください。
CNIS:
CNIS：
Claims Notice Information Service. This service provides Trademark Claims Notices (TCNs) to Registrars.
請求通知情報サービス。このサービスは、レジストラに商標請求通知（TCNS）を提供します。
CRC32:
CRC32：
Cyclic Redundancy Check. This algorithm is used in the ISO 3309 standard and in Section 8.1.1.6.2 of ITU-T recommendation V.42.
周期的な冗長性チェック。このアルゴリズムは、ISO 3309標準およびITU-T推奨V.42のセクション8.1.1.6.2で使用されます。
CRL:
CRL：
Certificate Revocation List. See [RFC5280].
証明書の取り消しリスト。[RFC5280]を参照してください。
CSV:
CSV：
Comma-Separated Values. See [RFC4180].
コンマ分離値。[RFC4180]を参照してください。
datetime:
日付時刻：
Date and time. The date and time are specified following the standard specification "Date and Time on the Internet: Timestamps". See [RFC3339].
日時。日付と時刻は、標準の仕様「インターネット上の日付と時刻：タイムスタンプ」に従って指定されます。[RFC3339]を参照してください。
DN:
DN：
Domain Name. See [RFC8499].
ドメイン名。[RFC8499]を参照してください。
DNL:
DNL：
Domain Name Label. The DNL is an A-label or a Non-Reserved LDH (NR-LDH) label. See [RFC5890].
ドメイン名ラベル。DNLは、Aラベルまたは非返済LDH（NR-LDH）ラベルです。[RFC5890]を参照してください。
DNL List:
DNLリスト：
A list of DNLs that are covered by a PRM.
PRMでカバーされているDNLのリスト。
DNROID:
アンドロイド：
DN Repository Object IDentifier. This identifier is assigned by the Registry to each DN object that unequivocally identifies said DN object. For example, if a new DN object is created for a name that existed in the past, the DN objects will have different DNROIDs.
DNリポジトリオブジェクト識別子。この識別子は、レジストリによって各DNオブジェクトに割り当てられ、そのDNオブジェクトを明確に識別します。たとえば、過去に存在していた名前に対して新しいDNオブジェクトが作成された場合、DNオブジェクトには異なるDNroidがあります。
DNS:
DNS：
Domain Name System. See [RFC8499].
ドメイン名システム。[RFC8499]を参照してください。
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.
DNは、DNのDNオブジェクトがレジストリのSRSに作成され、効果的なユーザーに割り当てられた場合に効果的に割り当てられると見なされます。ステータス「保留中」のDNオブジェクトまたはDNが初めてエンドユーザーに割り当てられたときに先行するその他のステータスは、効果的な割り当てとは見なされません。他の登録者へのその後の代表団のためにレジストリによって内部的に作成されたDNオブジェクトは、効果的な割り当てとは見なされません。
EPP:
EPP：
Extensible Provisioning Protocol. See [RFC8499].
拡張可能なプロビジョニングプロトコル。[RFC8499]を参照してください。
FQDN:
fqdn：
Fully Qualified Domain Name. See [RFC8499].
完全資格のドメイン名。[RFC8499]を参照してください。
HTTP:
http：
Hypertext Transfer Protocol. See [RFC9110].
ハイパーテキスト転送プロトコル。[RFC9110]を参照してください。
HTTPS:
https：
HTTP over TLS (Transport Layer Security). See [RFC9110].
TLSを超えるHTTP（輸送層のセキュリティ）。[RFC9110]を参照してください。
ICANN TMCH:
icann tmch：
A central repository for information to be authenticated, stored, and disseminated, pertaining to the rights of TMHs. The ICANN TMCH 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.
TMHSの権利に関連する情報を認証、保存、および普及させるための中央リポジトリ。ICANN TMCHは、TMVとTMDBの2つの関数に分割されます（以下を参照）。TMV関数を実行するいくつかのエンティティが存在する可能性がありますが、TMDB関数を実行するエンティティは1つだけです。
ICANN TMCH-CA:
icann tmch-ca：
The Certification Authority (CA) for the ICANN TMCH. This CA is operated by ICANN. The public key for this CA is the trust anchor used to validate the identity of each TMV.
ICANN TMCHの認証機関（CA）。このCAはICANNによって操作されます。このCAの公開鍵は、各TMVのIDを検証するために使用される信頼アンカーです。
IDN:
IDN：
Internationalized Domain Name. See [RFC8499].
国際化されたドメイン名。[RFC8499]を参照してください。
Lookup Key:
ルックアップキー：
A random string of up to 51 characters from the set [a-zA-Z0-9/] to be used as the lookup key by Registrars to obtain the TCN using the CNIS. Lookup keys are unique and are related to one DNL only.
セットから最大51文字のランダムな文字列[A-ZA-Z0-9/]は、CNISを使用してTCNを取得するためにレジストラのルックアップキーとして使用されます。ルックアップキーは一意であり、1つのDNLのみに関連しています。
LORDN:
Lordn：
List of Registered Domain Names. This is the list of effectively allocated DNs matching a DNL of a PRM. Registries will upload this list to the TMDB (during the NORDN process).
登録ドメイン名のリスト。これは、PRMのDNLに一致する効果的に割り当てられたDNSのリストです。レジストリは、このリストをTMDBにアップロードします（NORDNプロセス中）。
Matching Rules:
一致するルール：
Some trademarks entitled to inclusion in the TMDB include characters that are impermissible in the DNS as a DNL. The TMV changes (using the ICANN TMCH Matching Rules [MatchingRules]) certain DNS-impermissible characters in a trademark into DNS-permissible equivalent characters.
TMDBに含める権利のあるいくつかの商標には、DNLとしてDNSで容認できない文字が含まれています。TMVは（ICANN TMCHマッチングルール[MatchingRules]を使用して）DNSに適切な同等の文字にトレードマークに変化します。
NORDN:
Nordn：
Notification of Registered Domain Names. This is the process by which Registries upload their recent LORDN to the TMDB.
登録ドメイン名の通知。これは、レジストリが最近のLordnをTMDBにアップロードするプロセスです。
PGP:
PGP：
Pretty Good Privacy. See [RFC4880].
かなり良いプライバシー。[RFC4880]を参照してください。
PKI:
PKI：
Public Key Infrastructure. See [RFC5280].
公開鍵インフラストラクチャ。[RFC5280]を参照してください。
PRM:
PRM：
Pre-Registered Mark. A mark that has been pre-registered with the ICANN TMCH.
事前に登録されたマーク。ICANN TMCHで事前に登録されたマーク。
QLP Period:
QLP期間：
Qualified Launch Program Period. During this optional period, a special process applies to DNs matching the Sunrise List (SURL) and/or the DNL List to ensure that TMHs are informed of a DN matching their PRM.
資格のある打ち上げプログラム期間。このオプションの期間中、Sunriseリスト（SURL）および/またはDNLリストと一致するDNSに特別なプロセスが適用され、TMHがPRMに一致するDNが通知されるようにします。
Registrant:
登録者：
See the definition of Registrant in [RFC8499].
[RFC8499]の登録者の定義を参照してください。
Registrar:
レジストラ：
Domain Name Registrar. See [RFC8499].
ドメイン名レジストラ。[RFC8499]を参照してください。
Registry:
レジストリ：
Domain Name Registry, Registry Operator. See [RFC8499]. A Registry Operator is the contracting party with ICANN for the TLD.
ドメイン名レジストリ、レジストリオペレーター。[RFC8499]を参照してください。レジストリオペレーターは、TLDのICANNとの契約当事者です。
SMD:
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 DN that matches a DNL of a PRM. See [RFC7848]. An SMD generated by an ICANN-approved Trademark Validator (TMV) contains both the signed token and the TMV's PKIX certificate.
署名されたマークデータ。TMVがTMHに発行した暗号化された署名されたトークンは、PRMのDNLに一致するDNを申請するために使用されるために使用されます。[RFC7848]を参照してください。ICANN承認の商標検証装置（TMV）によって生成されたSMDには、署名されたトークンとTMVのPKIX証明書の両方が含まれています。
SMD File:
SMDファイル：
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 Section 6.4.
SMD（上記を参照）を含むファイルと人間が読めるデータ。後者は通常、SMDファイルの処理では無視されます。セクション6.4を参照してください。
SMD Revocation List:
SMD Rogocationリスト：
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.
SMD取り消しリストは、SMDがまだ有効であることを確認するために、日の出期間中にレジストリ（およびオプションでレジストラによって）で使用されます（つまり、取り消されていません）。SMD取り消しリストは、PKIで使用されるCRLと同様の機能を持っています。
SRS:
SRS：
Shared Registration System. See [ICANN-GTLD-AGB-20120604].
共有登録システム。[icann-gtld-agb-20120604]を参照してください。
Sunrise Period:
日の出期間：
During this period, DNs matching a DNL of a PRM can be exclusively obtained by the respective TMHs. For DNs matching a PRM, a special process applies to ensure that TMHs are informed on the effective allocation of a DN matching their PRM.
この期間中、PRMのDNLを一致させるDNSは、それぞれのTMHSによってのみ取得できます。PRMを一致させるDNSの場合、PRMに一致するDNの効果的な割り当てについてTMHSが通知されることを確認するために特別なプロセスが適用されます。
SURL:
SURL：
Sunrise List. The list of DNLs that are covered by a PRM and are eligible for Sunrise.
日の出リスト。PRMでカバーされ、日の出の対象となるDNLのリスト。
TCN:
TCN：
Trademark Claims Notice, Claims Notice, Trademark Notice. A Trademark Claims Notice consists of one or more Trademark Claims and is provided to prospective Registrants of DNs.
商標請求通知、請求通知、商標通知。商標請求は、通知が1つ以上の商標請求で構成され、DNSの将来の登録者に提供されます。
TCNID:
tcnid：
Trademark Claims Notice Identifier. An element of the Trademark Claims Notice (see above), identifying said TCN. The Trademark Claims Notice Identifier is specified in the element <tmNotice:id>.
商標請求通知識別子。商標請求通知の要素（上記を参照）。商標請求通知識別子は、要素<tmnotice：id>で指定されています。
TLD:
TLD：
Top-Level Domain Name. See [RFC8499].
トップレベルのドメイン名。[RFC8499]を参照してください。
TMDB:
TMDB：
Trademark Clearinghouse Database. This serves as a database of the ICANN TMCH to provide information to the gTLD Registries and Registrars to support Sunrise or Trademark Claims services. There is only one TMDB in the ICANN TMCH that concentrates the information about the "verified" trademark records from the TMVs.
商標Clearinghouseデータベース。これは、ICANN TMCHのデータベースとして機能し、GTLDレジストリとレジストラに情報を提供して、日の出または商標請求サービスをサポートします。ICANN TMCHには、TMVの「検証された」商標記録に関する情報を集中するTMDBは1つだけです。
TMH:
TMH：
Trademark Holder. The person or organization owning rights on a mark.
商標所有者。マーク上の権利を所有する個人または組織。
TMV:
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, are court-validated marks, or 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.
トレードマークの有効化者、トレードマーク検証組織。ICANNがTMDBの登録を認証および検証することを許可され、登録されたマークが登録されているか、裁判所が検証されたマークであるか、法令または条約によって保護されていることを保証するエンティティ。このエンティティは、マークの使用の証明が提供されるように要求されます。これは、署名された宣言と現在の使用の1つの標本を提供することで実証できます。
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.
マークは、製品またはサービスの排他的なプロパティを請求するために使用されます。マークは通常、名前、単語、フレーズ、ロゴ、シンボル、デザイン、画像、またはこれらの要素の組み合わせです。このドキュメントの範囲では、テキストマークのみが関連しています。
Trademark Claims, Claims:
商標請求、主張：
Provides information to enhance the understanding of the trademark rights being claimed by the TMH.
TMHが請求されている商標権の理解を高めるための情報を提供します。
Trademark Claims Period:
商標請求期間：
During this period, a special process applies to DNs matching the DNL List to ensure that TMHs are informed of a DN matching their PRM. For DNs matching the DNL List, Registrars show a TCN to prospective Registrants that has to be acknowledged before effective allocation of the DN.
この期間中、DNLリストに一致するDNSに特別なプロセスが適用され、TMHがPRMに一致するDNが通知されるようにします。DNLリストに一致するDNSの場合、レジストラは、DNの効果的な割り当ての前に認められなければならない将来の登録者にTCNを表示します。
UTC:
UTC：
Coordinated Universal Time. This is maintained by the Bureau International des Poids et Mesures (BIPM). See [RFC3339].
調整された普遍的な時間。これは、Bureau International Des Poids et Mesures（BIPM）によって維持されています。[RFC3339]を参照してください。
SMD hand over (out-of-band)
..............................................
: :
: .'''''''''''''''''''. :
: . ICANN TMCH . :
: ..................... :
v . . :
.------------. . .-------------. . hv .-----.
| Registrant | . | TMV |<---------->| TMH |
'------------' . '-------------' . vh '-----'
| . | ^ \ .
| . | | \.
tr | . vs | | dv \
| . | vd | .\
v . v v . \
.-----------. sr . .---------. . \
.->| Registrar |<..........| | . \
: '-----------' . | | . \
: | sy . | T | . \
: ry | .------------| M | . vc \
: | | . | D | . \
: v v . | B | . v
: .-----------. . yd | | . .---------------.
: | Registry |---------->| | . | ICANN TMCH-CA |
: '-----------' . '---------' . '---------------'
: ^ . . | :
: | ''''''''''''''''''' | :
: | cy | :
: cr '-----------------------------------------' :
:......................................................:
Figure 1: Architecture of the Sunrise Period
図1：日の出期間のアーキテクチャ
Figure 1 depicts the architecture of the Sunrise Period, including all the actors and interfaces.
図1は、すべての俳優とインターフェイスを含む、日の出期間のアーキテクチャを示しています。
.''''''''''''''.
. ICANN TMCH .
................
. .
.------------. . .-------. . hv .-----.
| Registrant | . | TMV |<----------->| TMH |
'------------' . '-------' . vh '-----'
| . ^ .
| . | dv .
tr | . vd | .
v . v .
.-----------. dr . .-------. .
| Registrar |<--------| | .
'-----------' . | T | .
ry | . | M | .
v . | D | .
.----------. dy . | B | .
| Registry |<------->| | .
'----------' yd . '-------' .
. .
''''''''''''''
Figure 2: Architecture of the Trademark Claims Period
図2：商標請求期間のアーキテクチャ
Figure 2 depicts the architecture of the Trademark Claims Period, including all the actors and interfaces.
図2は、すべての俳優とインターフェイスを含む商標請求期間のアーキテクチャを示しています。
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.
以下のサブセクションには、各インターフェイスの短い説明が含まれており、アーキテクチャの概要を提供します。関連するインターフェイスのより詳細な説明は、セクション5にあります。
The TMH registers a mark with a TMV via the hv interface.
TMHは、HVインターフェイスを介してTMVでマークを登録します。
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.
マークの登録が成功した後、TMVは、日の出期間中に使用されるTMHに署名されたマークデータ（SMD）ファイル（セクション6.4を参照）を利用可能にします。
The specifics of the hv interface are beyond the scope of this document.
HVインターフェイスの詳細は、このドキュメントの範囲を超えています。
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.
マークの登録が成功した後、TMVはTMDBが対応するDNLSを挿入し、VDインターフェイスを介してデータベースにマーク情報を挿入するようにします。
The specifics of the vd interface are beyond the scope of this document.
VDインターフェイスの詳細は、このドキュメントの範囲を超えています。
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.
商標請求期間中、レジストリは定期的にDYインターフェイスを介してTMDBから最新のDNLリストを取得します。DYインターフェイスで使用されるプロトコルはHTTPSです。
This interface is not relevant during the Sunrise Period.
このインターフェイスは、日の出期間中は関連しません。
The Registrant communicates with the Registrar via the tr interface.
登録者は、TRインターフェイスを介してレジストラと通信します。
The specifics of the tr interface are beyond the scope of this document.
TRインターフェイスの詳細は、このドキュメントの範囲を超えています。
The Registrar communicates with the Registry via the ry interface. The ry interfaces are typically implemented in EPP.
レジストラは、RYインターフェイスを介してレジストリと通信します。RYインターフェイスは通常、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.
商標請求期間中、レジストラは、DRインターフェイスを介してTMDB（TRインターフェイスを介して登録者に表示される）からTCNを取得します。TCNの取得に使用されるプロトコルは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.
日の出期間中、レジストリは、効果的に割り当てられたすべてのDNSのYDインターフェイスを介してTMDBに通知します。
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.
商標請求期間中、レジストリは、DNの作成中にレジストリが以前にダウンロードしたDNLリストのエントリと一致するすべてのDNSのYDインターフェイスを介してTMDBに通知します。
The protocol used on the yd interface is HTTPS.
YDインターフェイスで使用されるプロトコルはHTTPSです。
The TMDB notifies the TMV via the dv interface of all effectively allocated DNs that match a mark registered by that TMV.
TMDBは、そのTMVによって登録されたマークに一致するすべての効果的に割り当てられたDNSのDVインターフェイスを介してTMVに通知します。
The specifics of the dv interface are beyond the scope of this document.
DVインターフェイスの詳細は、このドキュメントの範囲を超えています。
The TMV notifies the TMH via the vh interface after an effectively allocated DN matches a PRM of this THM.
TMVは、このTHMのPRMと効果的に割り当てられたDN一致後、VHインターフェイスを介してTMHに通知します。
The specifics of the vh interface are beyond the scope of this document.
VHインターフェイスの詳細は、このドキュメントの範囲を超えています。
The TMV requests to add revoked SMDs to the SMD Revocation List at the TMDB.
TMVは、TMDBのSMD取り消しリストに取り消されたSMDを追加するように要求します。
The specifics of the vs interface are beyond the scope of this document.
VSインターフェイスの詳細は、このドキュメントの範囲を超えています。
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.
日の出期間中、レジストリは通常の間隔でSYインターフェイスを介してTMDBから最新のSMD取り消しリストを取得します。SYインターフェイスで使用されるプロトコルは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.
日の出期間中、レジストラは、SRインターフェイスを介してTMDBから最新のSMD取り消しリストを取得できます。SRインターフェイスで使用されるプロトコルは、SYインターフェイス（上記参照）、つまり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.
TMVは公開キーを登録し、VCインターフェイス上のICANN TMCH-CAを使用して既存のキーを取り消すよう要求します。
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.
VCインターフェイスの詳細はこのドキュメントの範囲を超えていますが、TMVのオペレーターと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.
日の出期間中、レジストリは、定期的にCyインターフェイスを介してICANN TMCH-CAから最新のTMV CRLファイルを取得します。TMV CRLは、TMV証明書の検証に使用されます。Cyインターフェイスで使用されるプロトコルは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.
日の出期間中、レジストラはオプションで、定期的にCRインターフェイスを介してICANN TMCH-CAから最新のTMV CRLファイルを取得します。TMV CRLは、TMV証明書の検証に使用されます。CRインターフェイスで使用されるプロトコルはHTTPSです。
This interface is not relevant during the Trademark Claims Period.
このインターフェイスは、商標請求期間中には関連しません。
Each Registry Operator will receive authentication credentials from the TMDB to be used:
各レジストリオペレーターは、使用するTMDBから認証資格情報を受け取ります。
* during the Sunrise Period to fetch the SMD Revocation List from the TMDB via the sy interface (Section 4.3.11),
* 日の出期間中、SYインターフェイスを介してTMDBからSMD取り消しリストを取得する（セクション4.3.11）、
* during the Trademark Claims Period to fetch the DNL List from the TMDB via the dy interface (Section 4.3.3), and
* 商標請求期間中、DYインターフェイスを介してTMDBからDNLリストを取得する（セクション4.3.3）、
* during the NORDN process to notify the LORDN to the TMDB via the yd interface (Section 4.3.7).
* Nordnプロセス中に、YDインターフェイスを介してLordnにTMDBに通知する（セクション4.3.7）。
Note: Credentials are created per TLD and provided to the Registry Operator.
注：資格情報はTLDごとに作成され、レジストリオペレーターに提供されます。
Each Registry Operator MUST provide the TMDB with all IP addresses, which will be used to:
各レジストリ演算子は、すべてのIPアドレスをTMDBに提供する必要があります。これは以下に使用されます。
* fetch the SMD Revocation List via the sy interface (Section 4.3.11),
* SYインターフェイス（セクション4.3.11）を介してSMD取り消しリストを取得し、
* fetch the DNL List from the TMDB via the dy interface (Section 4.3.3), and
* DYインターフェイス（セクション4.3.3）を介してTMDBからDNLリストを取得し、
* upload the LORDN to the TMDB via the yd interface (Section 4.3.7).
* YDインターフェイスを介してLordnをTMDBにアップロードします（セクション4.3.7）。
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.
このアクセス制限は、HTTP Basic Access認証に加えて、TMDBによって適用される場合があります（[RFC7617]を参照）。使用する資格情報については、セクション5.1.1.1を参照してください。
The TMDB MAY limit the number of IP addresses to be accepted per Registry Operator.
TMDBは、レジストリ演算子ごとに受け入れるIPアドレスの数を制限する場合があります。
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:
各レジストリオペレーターは、<https://can.icann.org/tmch.crt>からICANN TMCH-CA（信頼アンカー）のPKIX証明書[RFC5280]を使用する必要があります。
* during the Sunrise Period to validate the TMV certificates and the TMV CRL.
* 日の出の期間中、TMV証明書とTMV CRLを検証します。
The TMDB MUST provide each Registry Operator with the public portion of the PGP Key used by the TMDB, which is to be used:
TMDBは、各レジストリオペレーターにTMDBが使用するPGPキーの公開部分を提供する必要があります。
* during the Sunrise Period to perform integrity checking of the SMD Revocation List fetched from the TMDB via the sy interface (Section 4.3.11) and
* 日の出期間中、SYインターフェイス（セクション4.3.11）を介してTMDBから取得されたSMD取り消しリストの整合性チェックを実行する
* during the Trademark Claims Period to perform integrity checking of the DNL List fetched from the TMDB via the dy interface (Section 4.3.3).
* 商標請求期間中、DYインターフェイスを介してTMDBから取得されたDNLリストの整合性チェックを実行します（セクション4.3.3）。
Each ICANN-Accredited Registrar will receive authentication credentials from the TMDB to be used:
各ICANNが認識したレジストラは、使用するTMDBから認証資格情報を受け取ります。
* during the Sunrise Period to (optionally) fetch the SMD Revocation List from the TMDB via the sr interface (Section 4.3.12) and
* 日の出期間中、（オプションで）SRインターフェイス（セクション4.3.12）を介してTMDBからSMD取り消しリストを取得する
* during the Trademark Claims Period to fetch TCNs from the TMDB via the dr interface (Section 4.3.6).
* 商標請求期間中、DRインターフェイスを介してTMDBからTCNSを取得するために（セクション4.3.6）。
Each Registrar MUST provide the TMDB with all IP addresses, which will be used to:
各レジストラは、すべてのIPアドレスをTMDBに提供する必要があります。これは以下に使用されます。
* fetch the SMD Revocation List via the sr interface (Section 4.3.12) and
* SRインターフェイス（セクション4.3.12）を介してSMD取り消しリストを取得し、
* fetch TCNs via the dr interface (Section 4.3.6).
* DRインターフェイスを介してTCNをフェッチします（セクション4.3.6）。
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).
このアクセス制限は、HTTP Basic Access認証に加えて、TMDBによって適用される場合があります（使用する資格情報については、セクション5.1.2.1を参照）。
The TMDB MAY limit the number of IP addresses to be accepted per Registrar.
TMDBは、レジストラごとに受け入れるIPアドレスの数を制限する場合があります。
Registrars MAY fetch the PKIX certificate of the ICANN TMCH-CA (Trust Anchor) from <https://ca.icann.org/tmch.crt> to be used:
レジストラは、<https://ca.icann.org/tmch.crt>から<https://ca.icann.org/tmch.crt>からICANN TMCH-CA（Trust Anchor）のPKIX証明書を取得できます。
* during the Sunrise Period to (optionally) validate the TMV certificates and TMV CRL.
* （オプションで）TMV証明書とTMV CRLを検証する日の出期間中。
Registrars MUST receive the public portion of the PGP Key used by TMDB from the TMDB administrator to be used:
レジストラは、TMDB管理者からTMDBが使用するPGPキーの公開部分を使用する必要があります。
* during the Sunrise Period to (optionally) perform integrity checking of the SMD Revocation List fetched from the TMDB via the sr interface (Section 4.3.12).
* 日の出期間中、（オプションで）SRインターフェイスを介してTMDBから取得されたSMD取り消しリストの整合性チェックを実行します（セクション4.3.12）。
.------------. .-----------. .----------.
| Registrant | | Registrar | | Registry |
'------------' '-----------' '----------'
| | |
| Request DN | |
| registration | |
| (with SMD) | |
|---------------->| Check DN availability |
| |---------------------------->|
| | |
| | DN unavailable .-------------.
| 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 registered |<----------------------------|
|<----------------| |
| | |
Figure 3: Domain Name Registration during the Sunrise Period
図3：日の出期間中のドメイン名登録
Figure 3 represents a synchronous DN registration workflow (usually called first come first served).
図3は、同期DN登録ワークフローを表しています（通常はFirst Come First Serverと呼ばれます）。
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.
レジストリは、RYインターフェイス（セクション4.3.5）を介した登録要求を受信したときに、日の出期間中に各DN登録を確認するための最小チェックセットを実行する必要があります。これらのチェックのいずれかが失敗した場合、レジストリは登録を中止する必要があります。これらの各チェックは、DNが効果的に割り当てられる前に実行する必要があります。
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.
非同期登録（オークションなど）の場合、DN登録に使用される中間オブジェクト（例：DNアプリケーション）を作成するときに最小チェックセットを実行できます。中間オブジェクトの作成時に最小チェックセットが実行される場合（例：DNアプリケーション）、レジストリは最小チェックセットを再度実行せずにDNを効果的に割り当てることができます。
Performing the minimum set of checks, Registries MUST verify that:
小切手の最小セットを実行すると、レジストリは次のことを確認する必要があります。
1. an SMD has been received from the Registrar, along with the DN registration,
1. DN登録とともに、SMDがレジストラから受信されました。
2. the certificate of the TMV has been correctly signed by the ICANN TMCH-CA (the certificate of the TMV is contained within the SMD),
2. TMVの証明書は、ICANN TMCH-CA（TMVの証明書はSMD内に含まれる）によって正しく署名されています。
3. the datetime when the validation is done is within the validity period of the TMV certificate,
3. 検証が行われた場合のデータタイムは、TMV証明書の有効期間内にあります。
4. the certificate of the TMV is not listed in the TMV CRL file specified in the CRL distribution point of the TMV certificate,
4. TMVの証明書は、TMV証明書のCRL配布ポイントで指定されたTMV CRLファイルにリストされていません。
5. the signature of the SMD (signed with the TMV certificate) is valid,
5. SMDの署名（TMV証明書で署名）は有効です、
6. the datetime when the validation is done is within the validity period of the SMD based on <smd:notBefore> and <smd:notAfter> elements,
6. 検証が行われた場合のデータタイムは、<SMD：NotBeFore>および<SMD：Notafter>要素に基づいてSMDの有効期間内にあります。
7. the SMD has not been revoked, i.e., is not contained in the SMD Revocation List, and
7. SMDは取り消されていません。つまり、SMD取り消しリストには含まれていません。
8. the leftmost DNL of the DN being effectively allocated matches one of the label (<mark:label>) elements in the SMD. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn--mgbachtv".
8. 効果的に割り当てられているDNの左端のDNLは、SMDのラベル（<マーク：ラベル>）要素の1つと一致します。たとえば、dn "xn - mgbachtv.xn - mgbh0fb"が効果的に割り当てられている場合、左端のdnlは「xn - mgbachtv」になります。
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.
これらの手順は、第2レベルでのすべてのDN効果的な割り当て、およびレジストリが登録を受け入れるTLDに従属する他のすべてのレベルに適用されます。
A new SMD Revocation List MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC.
新しいSMD取り消しリストは、TMDBによって1日2回、00:00:00および12:00:00 UTCまでに公開する必要があります。
Registries MUST refresh the latest version of the SMD Revocation List at least once every 24 hours.
レジストリは、少なくとも24時間に1回は、SMD Rococationリストの最新バージョンを更新する必要があります。
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.
注：SMD取り消しリストは、TLDに関係なく同じです。バックエンドレジストリオペレーターが複数のTLDのインフラストラクチャを管理する場合、バックエンドレジストリオペレーターは24時間に1回SMD取り消しリストを更新でき、SMD取り消しリストはバックエンドレジストリオペレーターが管理するすべてのTLDに使用できます。
.----------. .------.
| Registry | | TMDB |
'----------' '------'
| |
.----------------. |
| Periodically, | |
| at least | |
| every 24 hours | |
'----------------' |
| |
|----------------------------------------------------->|
| Download the latest SMD Revocation List |
|<-----------------------------------------------------|
| |
| |
Figure 4: Update of the SMD Revocation List
図4：SMD取り消しリストの更新
Figure 4 depicts the process of downloading the latest SMD Revocation List initiated by the Registry.
図4は、レジストリによって開始された最新のSMD取り消しリストをダウンロードするプロセスを示しています。
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.
レジストリは、TMV証明書で指定されたCRL配布ポイントを使用して、少なくとも24時間に1回、TMV CRLファイルのローカルコピーを更新する必要があります。
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>.
操作的に、TMV CRLファイルとCRL分布ポイントはすべてのTMVで同じであり、（このドキュメントの公開時）は<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.
注：TMV CRLファイルは、TLDに関係なく同じです。バックエンドレジストリオペレーターが複数のTLDのインフラストラクチャを管理する場合、バックエンドレジストリオペレーターは24時間に1回TMV CRLファイルを更新でき、TMV CRLファイルはバックエンドレジストリオペレーターが管理するすべてのTLDに使用できます。
.----------. .---------------.
| Registry | | ICANN TMCH-CA |
'----------' '---------------'
| |
.----------------. |
| Periodically, | |
| at least | |
| every 24 hours | |
'----------------' |
| |
|-------------------------------------------->|
| Download the latest TMV CRL file |
|<--------------------------------------------|
| |
| |
Figure 5: Update of the TMV CRL File
図5：TMV CRLファイルの更新
Figure 5 depicts the process of downloading the latest TMV CRL file initiated by the Registry.
図5は、レジストリによって開始された最新のTMV CRLファイルをダウンロードするプロセスを示しています。
The Registry MUST send a LORDN file containing DNs effectively allocated to the TMDB (over the yd interface; see Section 4.3.7).
レジストリは、TMDBに効果的に割り当てられたDNSを含むLORDNファイルを送信する必要があります（YDインターフェイスを介して、セクション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.
DNの効果的な割り当ては、そのようなDNの効果的な割り当てから26時間以内にレジストリによってTMDBに報告する必要があります。
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.
レジストリは、SRSに以前のLODNファイルのTMDBに成功していない効果的な割り当てがある場合に備えて、LORDNファイルを作成およびアップロードする必要があります。
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.
TMVSとTMDBが使用するタイマーに基づいて、RODNファイルをTMDBにアップロードするための推奨最大周波数は3時間ごとです。
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.
登録は、Lordnファイルで報告された問題を修正する時間を確保するために、1日に少なくとも2つのlordnファイルをTMDBにアップロードしようとすることをお勧めします。
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.
レジストリは、以前のlordnファイルがTMDBによって処理され、関連するlordnログファイルがレジストリによってダウンロードおよび処理された場合にのみ、lordnファイルをアップロードする必要があります。
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).
レジストリは、日の出または商標請求期間中に効果的に割り当てられたDNSのlordnファイルをアップロードする必要があります（同じことは、非同期登録を使用した場合に日の出または商標請求期間中に作成されたアプリケーションを使用して効果的に割り当てられるDNSに適用されます）。
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.
YDインターフェイス（セクション4.3.7）は、少なくとも1つの（1）をサポートする必要があり、サービスにアクセスするためにレジストリオペレーターによって登録された各IPアドレスから最大10（10）の同時接続をサポートする場合があります。
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.
TMDBは、アップロードされた各lordnファイルを処理し、アップロードの最終化から30分以内にレジストリのダウンロードに関連するログファイルを使用できるようにする必要があります。
.----------. .------. .-----. .-----.
| Registry | | TMDB | | TMV | | TMH |
'----------' '------' '-----' '-----'
| | | |
.------------------. | | |
| Periodically | | | |
| upload LORDN | | | |
| file | | | |
'------------------' | | |
| | | |
.--------->| Upload LORDN | | |
| |-------------------->| | |
| | | | |
| | .-------------------------. | |
| | | Verify each domain name | | |
| | | in the uploaded file | | |
| | | (within 30') | | |
| | '-------------------------' | |
| | | ._____.| |
| | Download Log file | | END || |
| |<--------------------| '-----'| |
| | | ^ | |
| .-----------------. .---------------. | | |
| | 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: Notification of the Registered Domain Name
図6：登録ドメイン名の通知
Figure 6 depicts the process to notify the TMH of Registered Domain Names.
図6は、登録ドメイン名のTMHに通知するプロセスを示しています。
The format used for the LORDN is described in Section 6.3.
Lordnに使用される形式は、セクション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.
レジストラは、DNを登録するためにコマンドを送信する前に、レジストリ（セクション5.2.2を参照）で実行される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.
セクション5.2.3.1および5.2.3.2で説明されているプロセスは、受信したSMDをオプションで検証するためにレジストラが利用できます。
.------------. .-----------. .----------. .------.
| Registrant | | Registrar | | Registry | | TMDB |
'------------' '-----------' '----------' '------'
| Request DN | | |
| registration | | |
|--------------->| Check DN availability | |
| |--------------------------->| |
| | DN unavailable .-------------. |
| DN unavailable |<-------------------( DN available? ) |
|<---------------| no '-------------' |
| | DN available | yes |
| |<---------------------------| |
| | Request lookup key | |
| |--------------------------->| |
| |.__________. .---------. |
| || CONTINUE | / Does DN \ |
| || NORMALLY |<--------( match DNL ) |
| |'----------' no \ of PRM? / |
| | '---------' |
| | Lookup key | yes |
| |<----------------------------' |
| | |
.-----. | | Request TCN |
|ABORT| | Display |---------------------------------------->|
'-----' | Claims | Return TCN |
^ | Notice |<----------------------------------------|
| no |<---------------| |
| .------. yes | |
'-( Ack? )----------->| Register DN (with TCNID) | |
'------' |--------------------------->| |
| Registration | Error .----------------------. |
| error |<-------------( Validation successful? ) |
|<---------------| no '----------------------' |
| | | yes |
| | DN registered | |
| DN registered |<---------------------------| |
|<---------------| | |
Figure 7: Domain Name Registration during the Trademark Claims Period
図7：商標請求期間中のドメイン名登録
Figure 7 represents a synchronous DN registration workflow (usually called first come first served).
図7は、同期DN登録ワークフローを表しています（通常はFirst Come First Serverと呼ばれます）。
During the Trademark Claims Period, Registries perform two main functions:
商標請求期間中、レジストリは2つの主要な機能を実行します。
* Registries MUST provide Registrars (over the ry interface; see Section 4.3.5) the lookup key used to retrieve the TCNs for DNs that match the DNL List.
* レジストリは、レジストラ（RYインターフェイスを介して、セクション4.3.5を参照）を提供する必要があります。DNLリストに一致するDNSのTCNSを取得するために使用されるルックアップキー。
* Registries MUST provide the lookup key only when queried about a specific DN.
* レジストリは、特定のDNについて照会した場合にのみ、ルックアップキーを提供する必要があります。
In the following instances, a minimum set of checks are described:
次の例では、最小チェックセットについて説明します。
* For each DN matching a DNL of a PRM, Registries MUST perform a minimum set of checks for verifying DN registrations during the Trademark Claims 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.
* PRMのDNLを一致させる各DNについて、レジストリは、RYインターフェイスを介した登録要求を受信したときに、商標請求期間中にDN登録を確認するための最小チェックセットを実行する必要があります（セクション4.3.5）。これらのチェックのいずれかが失敗した場合、レジストリは登録を中止する必要があります。これらの各チェックは、DNが効果的に割り当てられる前に実行する必要があります。
* 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 effective allocation. 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.
* 非同期登録（オークションなど）の場合、DN効果的な割り当てに使用される中間オブジェクト（DNアプリケーションなど）を作成するときに、最小チェックセットを実行できます。中間オブジェクトの作成時に最小チェックセットが実行される場合（例：DNアプリケーション）、レジストリは最小チェックセットを再度実行せずにDNを効果的に割り当てることができます。
* Performing the minimum set of checks, Registries MUST verify that:
* 小切手の最小セットを実行すると、レジストリは次のことを確認する必要があります。
1. 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.
1. tcnid（<tmnotice：id>）、有効期限のDateTime（<tmnotice：notafter>）、およびTCNの受け入れ日は、DN登録とともにレジストラから受信されました。
1. 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.
1. 上記の3つの要素が、PRMのDNLを一致させるDNのレジストラから提供されていないが、DNLが24時間前にDNLリストに初めて挿入（または再挿入された）場合、登録は継続できない場合があります。このデータ、および以下にリストされているテストは実行する必要はありません。
2. The TCN has not expired (according to the expiration datetime sent by the Registrar).
2. TCNは有効期限が切れていません（レジストラが送信した有効期限の日付によると）。
3. The acceptance datetime is within the window of time defined by ICANN policy. In the gTLD round of 2012, Registrars verified that the acceptance datetime was less than or equal to 48 hours in the past, as there were no defined ICANN policies at that time. Implementers should be aware that ICANN policy may define this value in the future.
3. 受け入れ日付は、ICANNポリシーで定義された時間の窓内にあります。2012年のGTLDラウンドでは、レジストラは、その時点で定義されたICANNポリシーがなかったため、受け入れデータタイムが過去48時間以下であることを確認しました。実装者は、ICANNポリシーが将来この値を定義する可能性があることに注意する必要があります。
4. The TCN Checksum is computed using the leftmost DNL of the DN being effectively allocated, the expiration datetime provided by the Registrar, and the TMDB Notice Identifier extracted from the TCNID provided by the Registrar. Verify that the computed TCN Checksum matches the TCN Checksum present in the TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn-- mgbachtv".
4. TCNチェックサムは、効果的に割り当てられているDNの左端のDNL、レジストラが提供する有効期限のデータ、およびレジストラが提供するTCNIDから抽出されたTMDB通知識別子を使用して計算されます。計算されたTCNチェックサムがTCNIDに存在するTCNチェックサムと一致することを確認します。たとえば、dn "xn - mgbachtv.xn - mgbh0fb"が効果的に割り当てられている場合、左端のdnlは「xn-mgbachtv」になります。
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.
これらの手順は、第2レベルのすべてのDN登録と、レジストリが登録を受け入れるTLDに従属する他のすべてのレベルに適用されます。
A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC.
新しいDNLリストは、TMDBによって1日2回、00：00：00および12:00:00 UTCまでに公開する必要があります。
Registries MUST refresh the latest version of the DNL List at least once every 24 hours.
レジストリは、24時間に少なくとも1回DNLリストの最新バージョンを更新する必要があります。
.----------. .------.
| Registry | | TMDB |
'----------' '------'
| |
.----------------. |
| Periodically, | |
| at least | |
| every 24 hours | |
'----------------' |
| |
|-------------------------------->|
| Download the latest DNL List |
|<--------------------------------|
| |
| |
Figure 8: Update of the DNL List
図8：DNLリストの更新
Figure 8 depicts the process of downloading the latest DNL List initiated by the Registry.
図8は、レジストリによって開始された最新のDNLリストをダウンロードするプロセスを示しています。
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.
注：DNLリストは、TLDに関係なく同じです。バックエンドレジストリオペレーターが複数のTLDのインフラストラクチャを管理する場合、バックエンドレジストリオペレーターは24時間に1回DNLリストを更新でき、DNLリストはバックエンドレジストリオペレーターが管理するすべてのTLDに使用できます。
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.
商標請求期間中のNORDNプロセスは、セクション5.2.3.3で定義されているように、日の出期間とほぼ同じです。違いは、商標請求の対象となる登録のみが（つまり、登録時に、レジストリオペレーターによってダウンロードされた現在のDNLリストに名前が表示される）ことです。
For each DN matching a DNL of a PRM, Registrars MUST perform the following steps:
PRMのDNLに一致する各DNについて、レジストラは次の手順を実行する必要があります。
1. Use the lookup key received from the Registry to obtain the TCN 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.
1. レジストリから受信したルックアップキーを使用して、DRインターフェイスを使用してTMDBからTCNを取得します（セクション4.3.6）。レジストラは、登録に利用できるDNのルックアップキーのみをクエリする必要があります。
2. Present the TCN to the Registrant, as described in Exhibit A of [RPM-Requirements].
2. [rpm-requirements]の展示Aで説明されているように、TCNを登録者に提示します。
3. Ask the Registrant for acknowledgement, i.e., the Registrant MUST consent with the TCN, before any further processing. (The transmission of a TCNID to the Registry over the ry interface (Section 4.3.5) implies that the Registrant has expressed their consent with the TCN.)
3. 登録者に承認を求めます。つまり、登録者は、さらに処理する前にTCNに同意する必要があります。（RYインターフェイス（セクション4.3.5）を介したTCNIDのレジストリへの送信は、登録者がTCNに同意を表明したことを意味します。）
4. 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:
4. DN登録を確認するために、チェックの最小セットを実行します。これらのチェックのいずれかが失敗した場合、レジストラはDN登録を中止する必要があります。これらの各チェックは、登録がレジストリに送信される前に実行する必要があります。小切手の最小セットを実行すると、レジストラは以下を確認する必要があります。
a. The datetime when the validation is done is within the TCN validity based on the <tmNotice:notBefore> and <tmNotice:notAfter> elements.
a. 検証が行われた場合のデータタイムは、<tmnotice：notbefore> and <tmnotice：notafter>要素に基づいてTCNの有効性内にあります。
b. The leftmost DNL of the DN being effectively allocated matches the label (<tmNotice:label>) element in the TCN. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn-- mgbachtv".
b. 効果的に割り当てられているDNの左端のDNLは、TCNのラベル（<TMNOTICE：ラベル>）要素と一致します。たとえば、dn "xn - mgbachtv.xn - mgbh0fb"が効果的に割り当てられている場合、左端のdnlは「xn-mgbachtv」になります。
c. The Registrant has acknowledged (expressed their consent with) the TCN.
c. 登録者は、TCNを認めた（同意を表明した）。
5. Record the date and time when the registrant acknowledged the TCN.
5. 登録者がTCNを認めた日付と時刻を記録します。
6. Send the registration to the Registry (via the ry interface; see Section 4.3.5) and include the following information:
6. 登録をレジストリに送信します（RYインターフェイスを介して、セクション4.3.5を参照）。次の情報を含めます。
* TCNID (<tmNotice:id>)
* tcnid（<tmnotice：id>）
* Expiration date of the TCN (<tmNotice:notAfter>)
* TCNの有効期限（<tmnotice：notafter>）
* Acceptance datetime of the TCN
* TCNの受け入れ日
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.
現在、TCNはTMDBによって1日2回生成されています。各TCNの有効期限（<tmnotice：notafter>）は、ICANNポリシーで定義された値に設定する必要があります。2012年のGTLDラウンドでは、TMDBはその時点で定義されたICANNポリシーがなかったため、有効期限の値を将来48時間に設定しました。実装者は、ICANNポリシーが将来この値を定義する可能性があることに注意する必要があります。
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>.
レジストラは、TCNSのキャッシュを実装して、TMDBに送信されるクエリの数を最小限に抑える必要があります。<tmnotice：notafter>で定義されているように、TCNの有効期限後にキャッシュされたTCNをキャッシュから削除する必要があります。
The TMDB MAY implement rate limiting as one of the protection mechanisms to mitigate the risk of performance degradation.
TMDBは、パフォーマンス分解のリスクを軽減するための保護メカニズムの1つとしてレート制限を実装する場合があります。
The TCNs are provided by the TMDB online and are fetched by the Registrar via the dr interface (Section 4.3.6).
TCNSはTMDBオンラインで提供され、DRインターフェイスを介してレジストラによってフェッチされます（セクション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.
TCNSにアクセスするには、レジストラはTMDB（セクション5.1.2.1）によって提供される資格情報と、RYインターフェイスを介してレジストリから受信したルックアップキー（セクション4.3.5）を必要とします。DRインターフェイス（セクション4.3.6）は、基本的なアクセス認証を使用してHTTPSを使用しています。
The dr interface (Section 4.3.6) MAY support up to ten (10) concurrent connections from each Registrar.
DRインターフェイス（セクション4.3.6）は、各レジストラからの最大10（10）の同時接続をサポートできます。
The URL of the dr interface (Section 4.3.6) is:
DRインターフェイスのURL（セクション4.3.6）は次のとおりです。
https://<tmdb-domain-name>/cnis/<lookupkey>.xml
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.
「LookupKey」にはスラッシュ文字（ "/"）が含まれる場合があることに注意してください。スラッシュ文字はURLパスの一部であり、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.
DRインターフェイス（セクション4.3.6）で使用されるTLS証明書（HTTPS）は、よく知られている公共のCAによって署名する必要があります。レジストラは、[RFC5280]のセクション6で説明されている認証パス検証を実行する必要があります。レジストラは、HTTP Basic Access Authenticationを使用してDRインターフェイスで認証されます。DRインターフェイス（セクション4.3.6）は、HTTPSを維持することをサポートする必要があり、最大30分間接続を維持する必要があります。
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.
オプションの資格のある打ち上げプログラム（QLP）期間（[QLP-Addendum]を参照）では、第三者へのDNSの効果的な割り当てが、レジストリとレジストラが日の出および/または商標請求サービスを提供することを要求する場合があります。必要に応じて、レジストリとレジストラは、セクション5.2および5.3で説明されているように、日の出および/または商標請求サービスを提供する必要があります。
The effective allocation scenarios are as follows:
効果的な割り当てシナリオは次のとおりです。
* If the leftmost DNL of the DN being effectively allocated (QLP Name in this section) matches a DNL in the SURL and an SMD is provided, then Registries MUST provide Sunrise Services (see Section 5.2), and the DN MUST be reported in a Sunrise LORDN file during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn--mgbachtv".
* DNの左端のDNLが効果的に割り当てられている（このセクションのQLP名）がSURLのDNLと一致し、SMDが提供される場合、レジストリは日の出サービスを提供する必要があり（セクション5.2を参照）、DNは日の出で報告する必要があります。QLP期間中のlordnファイル。たとえば、dn "xn - mgbachtv.xn-- mgbh0fb"が効果的に割り当てられている場合、左端のdnlは「xn - mgbachtv」になります。
* If the QLP Name matches a DNL in the SURL but does not match a DNL in the DNL List and an SMD is NOT provided (see Section 2.2 of [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN file using the special SMD-id "99999-99999" during the QLP Period.
* QLP名がSURLのDNLと一致しますが、DNLリストのDNLと一致せず、SMDは提供されていません（[QLP-Addendum]のセクション2.2を参照）、DNは日の出Lordnファイルで報告する必要があります。QLP期間中の特別なSMD-ID「99999-99999」。
* If the QLP Name matches a DNL in the SURL and also matches a DNL in the DNL List and an SMD is NOT provided (see Section 2.2 of [QLP-Addendum]), then Registries MUST provide Trademark Claims services (see Section 5.3), and the DN MUST be reported in a Trademark Claims LORDN file during the QLP Period.
* QLP名がSURLのDNLと一致し、DNLリストのDNLと一致し、SMDが提供されていない場合（[QLP-Addendum]のセクション2.2を参照）、レジストリは商標請求サービスを提供する必要があります（セクション5.3を参照）、DNは、QLP期間中に商標請求lordnファイルに報告する必要があります。
* If the QLP Name matches a DNL in the DNL List but does not match a DNL in the SURL, then Registries MUST provide Trademark Claims services (see Section 5.3), and the DN MUST be reported in a Trademark Claims LORDN file during the QLP Period.
* QLP名がDNLリストのDNLと一致しているが、SURLのDNLと一致しない場合、レジストリは商標請求サービスを提供する必要があり（セクション5.3を参照）、QLP期間中にDNはトレードマークの請求lordnファイルで報告する必要があります。。
The following table lists all the effective allocation scenarios during a QLP Period:
次の表には、QLP期間中のすべての効果的な割り当てシナリオを示します。
+========+==========+=================+==============+==============+
| QLP | QLP | SMD Was | Registry | Registry |
| Name | Name | Provided by the | MUST Provide | MUST Report |
| Match | Match | Potential | Sunrise or | DN |
| in the | in the | Registrant | Trademark | Registration |
| SURL | DNL | | Claims | in <type> |
| | List | | Services | LORDN File |
+========+==========+=================+==============+==============+
| Y | Y | Y | Sunrise | Sunrise |
+--------+----------+-----------------+--------------+--------------+
| Y | N | Y | Sunrise | Sunrise |
+--------+----------+-----------------+--------------+--------------+
| N | Y | -- | Trademark | Trademark |
| | | | Claims | Claims |
+--------+----------+-----------------+--------------+--------------+
| N | N | -- | -- | -- |
+--------+----------+-----------------+--------------+--------------+
| Y | Y | N (see | Trademark | Trademark |
| | | Section 2.2 of | Claims | Claims |
| | | [QLP-Addendum]) | | |
+--------+----------+-----------------+--------------+--------------+
| Y | N | N (see | -- | Sunrise |
| | | Section 2.2 of | | (using |
| | | [QLP-Addendum]) | | special SMD- |
| | | | | id) |
+--------+----------+-----------------+--------------+--------------+
Table 1: QLP Effective Allocation Scenarios
表1：QLP効果的な割り当てシナリオ
The TMDB MUST provide the following services to Registries during a QLP Period:
TMDBは、QLP期間中に次のサービスをレジストリに提供する必要があります。
* SMD Revocation List (see Section 5.2.3.1)
* SMD取り消しリスト（セクション5.2.3.1を参照）
* NORDN (see Section 5.2.3.3)
* Nordn（セクション5.2.3.3を参照）
* DNL List (see Section 5.3.3.1)
* DNLリスト（セクション5.3.3.1を参照）
* Sunrise List (SURL) (see Section 5.4.2.1)
* サンライズリスト（SURL）（セクション5.4.2.1を参照）
The TMDB MUST provide the following services to Registrars during a QLP Period:
TMDBは、QLP期間中に次のサービスをレジストラに提供する必要があります。
* SMD Revocation List (see Section 5.2.3.1)
* SMD取り消しリスト（セクション5.2.3.1を参照）
* CNIS (see Section 5.3.5.1)
* CNIS（セクション5.3.5.1を参照）
A new SURL MUST be published by the TMDB twice a day, by 00:00:00 and 12:00:00 UTC.
TMDBから1日2回、00:00:00および12:00:00 UTCまでに新しいSURLを公開する必要があります。
Registries offering the OPTIONAL QLP Period MUST refresh the latest version of the SURL at least once every 24 hours.
オプションのQLP期間を提供するレジストリは、少なくとも24時間に1回は最新バージョンのSURLを更新する必要があります。
.----------. .------.
| Registry | | TMDB |
'----------' '------'
| |
.----------------. |
| Periodically, | |
| at least | |
| every 24 hours | |
'----------------' |
| |
|------------------------------->|
| Download the latest SURL |
|<-------------------------------|
| |
| |
Figure 9: Update of the SURL
図9：SURLの更新
Figure 9 depicts the process of downloading the latest SURL initiated by the Registry.
図9は、レジストリによって開始された最新のSURLをダウンロードするプロセスを示しています。
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.
注：SURLは、TLDに関係なく同じです。バックエンドレジストリオペレーターがいくつかのTLDのインフラストラクチャを管理する場合、バックエンドレジストリオペレーターは24時間に1回サウルを更新でき、バックエンドレジストリオペレーターが管理するすべてのTLDにSURLを使用できます。
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.
このセクションでは、事前に登録されたマーク（PRM）と一致するすべてのDNLを含むリストの形式を定義します。リストはTMDBによって維持され、通常の間隔でレジストリによってダウンロードされます（セクション5.3.3.1を参照）。レジストリは、商標請求期間中にDNLリストを使用して、要求されたDNがPRMのDNLと一致するかどうかを確認します。
The DNL List contains all the DNLs covered by a PRM present in the TMDB at the datetime that the DNL List is generated.
DNLリストには、DNLリストが生成されたDATETIMEでTMDBに存在するPRMでカバーされているすべてのDNLが含まれています。
The DNL List is contained in a CSV-formatted file that has the following structure:
DNLリストは、次の構造を持つCSV形式のファイルに含まれています。
* first line: <version>,<DNL List creation datetime>
* 最初の行：<バージョン>、<DNLリスト作成DateTime>
Where:
どこ：
o <version>: version of the file. This field MUST be 1.
o <バージョン>：ファイルのバージョン。このフィールドは1でなければなりません。
o <DNL List creation datetime>: date and time in UTC that the DNL List was created.
o <DNLリスト作成DATETIME>：DNLリストが作成されたUTCの日付と時刻。
* second line: a header line, as specified in [RFC4180]
* 2行目：[RFC4180]で指定されているヘッダーライン
With the header names as follows:
次のようにヘッダー名があります：
DNL,lookup-key,insertion-datetime
dnl、lookup-key、挿入-dateTime
* One or more lines with: <DNL>,<lookup key>,<DNL insertion datetime>
* 1つ以上の行：<dnl>、<lookup key>、<dnl挿入dateTime>
Where:
どこ：
o <DNL>: a Domain Name Label covered by a PRM.
o <DNL>：PRMでカバーされているドメイン名ラベル。
o <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:
o <lookup key>：レジストリがレジストラに提供する必要があるルックアップキー。ルックアップキーには次の形式があります。<yyyy> <mm> <dd> <vv>/<x>/<x>/<x>/<ランダムビット> <シーケンシャル番号>
+ YYYY: year that the TCN was generated.
+ YYYY：TCNが生成された年。
+ MM: zero-padded month that the TCN was generated.
+ MM：TCNが生成されたゼロパッドの月。
+ DD: zero-padded day that the TCN was generated.
+ DD：TCNが生成されたゼロパッドの日。
+ vv: version of the TCN; possible values are 00 and 01.
+ VV：TCNのバージョン。考えられる値は00および01です。
+ X: one hex character. This is the first, second, and third hex character of encoding the <Random bits> in base16, as specified in [RFC4648].
+ X：1ヘクスの文字。これは、[RFC4648]で指定されているように、base16の<ランダムビット>をエンコードする1番目、2番目、および3番目のヘックス文字です。
+ Random bits: 144 random bits encoded in base64url, as specified in [RFC4648].
+ ランダムビット：[RFC4648]で指定されているように、Base64urlでエンコードされた144ランダムビット。
+ Sequential number: zero-padded natural number in the range 0000000001 to 2147483647.
+ シーケンシャル数：00000001から2147483647の範囲のゼロパッド自然数。
o <DNL insertion datetime>: datetime in UTC that the DNL was first inserted into the DNL List. The possible two values of time for inserting a DNL to the DNL List are 00:00:00 and 12:00:00 UTC.
o <DNL挿入DateTime>：DNLが最初にDNLリストに挿入されたというUTCのDateTime。DNLをDNLリストに挿入するための時間の2つの値の値は、00:00:00および12:00:00 UTCです。
Example of a DNL list:
DNLリストの例：
1,2012-08-16T00:00:00.0Z
DNL,lookup-key,insertion-datetime
example,2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001,\
2010-07-14T00:00:00.0Z
another-example,2013041500/6/A/5/alJAqG2vI2BmCv5PfUvuDkf40000000002,\
2012-08-16T00:00:00.0Z
anotherexample,2013041500/A/C/7/rHdC4wnrWRvPY6nneCVtQhFj0000000003,\
2011-08-16T12:00:00.0Z
Figure 10: Example DNL List
図10：例DNLリストの例
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.
認証と整合性の保護を提供するために、DNLリストはTMDBによって署名されたPGP [RFC4880]になります（セクション5.1.1.4を参照）。DNLリストのPGP署名は、同様のURIで見つけることができますが、以下に示すように、拡張.sigがあります。
The URLs of the dy interface (Section 4.3.3) are:
DYインターフェイスのURL（セクション4.3.3）は次のとおりです。
* https://<tmdb-domain-name>/dnl/dnl-latest.csv
* https：// <tmdb-domain-name> /dnl/dnl-latest.csv
* https://<tmdb-domain-name>/dnl/dnl-latest.sig
* https：// <tmdb-domain-name> /dnl/dnl-latest.sig
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].
このセクションでは、取り消されたSMDのリストの形式を定義します。リストはTMDBによって維持され、レジストリ（およびオプションではレジストラによって）によって通常の間隔でダウンロードされます（セクション5.2.3.1を参照）。SMD取り消しリストは、日の出期間中に使用され、受け取ったSMDを検証します。SMD取り消しリストは、PKI [RFC5280]で使用されるCRLと同様の機能を持っています。
The SMD Revocation List contains all the revoked SMDs present in the TMDB at the datetime it is generated.
SMD Rococationリストには、生成されるDateTimeのTMDBに存在するすべての取り消されたSMDが含まれています。
The SMD Revocation List is contained in a CSV-formatted file that has the following structure:
SMD取り消しリストは、次の構造を持つCSV形式のファイルに含まれています。
* first line: <version>,<SMD Revocation List creation datetime>
* 最初の行：<バージョン>、<smd取り消しリスト作成dateTime>
Where:
どこ：
o <version>: version of the file. This field MUST be 1.
o <バージョン>：ファイルのバージョン。このフィールドは1でなければなりません。
o <SMD Revocation List creation datetime>: datetime in UTC that the SMD Revocation List was created.
o <SMD Rococation List Creation DateTime>：SMD Rococation Listが作成されたUTCのDateTime。
* second line: a header line, as specified in [RFC4180]
* 2行目：[RFC4180]で指定されているヘッダーライン
With the header names as follows:
次のようにヘッダー名があります：
smd-id,insertion-datetime
SMD-ID、挿入摂取
* One or more lines with: <smd-id>,<revoked SMD datetime>
* 1つ以上の行：<smd-id>、<voked smd datetime>
Where:
どこ：
o <smd-id>: identifier of the SMD that was revoked.
o <SMD-ID>：取り消されたSMDの識別子。
o <revoked SMD datetime>: revocation datetime in UTC of the SMD. The possible two values of time for inserting an SMD to the SMD Revocation List are 00:00:00 and 12:00:00 UTC.
o <Reboked Smd Datetime>：SMDのUTCでの取り消しDateTime。SMDをSMD取り消しリストに挿入するための時間の2つの値の値は、00：00：00および12:00:00 UTCです。
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.
整合性保護を提供するために、SMD取り消しリストはTMDBによって署名されたPGPです（セクション5.1.1.4を参照）。SMD取り消しリストは、TMDBによって拡張機能.CSVを備えて提供されます。SMD取り消しリストのPGP署名は、同様のURIで見つけることができますが、以下に示すように、拡張.sigがあります。
The URLs of the sr interface (Section 4.3.12) and sy interface (Section 4.3.11) are:
SRインターフェイス（セクション4.3.12）とSYインターフェイス（セクション4.3.11）のURLは次のとおりです。
* https://<tmdb-domain-name>/smdrl/smdrl-latest.csv
* https：// <tmdb-domain-name>/smdrl/smdrl-latest.csv
* https://<tmdb-domain-name>/smdrl/smdrl-latest.sig
* https：// <tmdb-domain-name>/smdrl/smdrl-latest.sig
Example of an SMD Revocation List:
SMD取り消しリストの例：
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 11: Example SMD Revocation List
図11：SMD取り消しリストの例
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.
このセクションでは、各レジストリによって維持され、少なくとも毎日TMDBにアップロードされる登録ドメイン名（LORDN）のリストの形式を定義します。PRMのDNLに一致するDNがあるたびに、DNは登録に関連するさらなる情報とともにLordnに追加されると述べた。
The URIs of the yd interface (Section 4.3.7) used to upload the LORDN file are:
YDインターフェイスのuris（セクション4.3.7）は、lordnファイルをアップロードするために使用されます。
* Sunrise LORDN file:
* サンライズロードファイル：
* https://<tmdb-domain-name>/LORDN/<TLD>/sunrise
* https：// <tmdb-domain-name>/lordn/<tld>/日のご
* Trademark Claims LORDN file:
* トレードマークはlordnファイルを主張しています：
* https://<tmdb-domain-name>/LORDN/<TLD>/claims
* https：// <tmdb-domain-name>/lordn/<tld>/請求
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:
QLP期間中、日の出またはトレードマークの請求をlordnファイルにアップロードするためにレジストリが必要になる場合があります。QLP期間中にlordnファイルをアップロードするために使用されるYDインターフェイスのurisは次のとおりです。
* Sunrise LORDN file (during QLP Period):
* Sunrise Lordnファイル（QLP期間中）：
* https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/qlp
* https：// <tmdb-domain-name>/lordn/<tld>/sunrise/qlp
* Trademark Claims LORDN file (during a QLP Period):
* トレードマークは、lordnファイルを主張しています（QLP期間中）：
* https://<tmdb-domain-name>/LORDN/<TLD>/claims/qlp
* https：// <tmdb-domain-name>/lordn/<tld>/claik/qlp
The yd interface (Section 4.3.7) returns the following HTTP status codes after an HTTP POST request method is received:
YDインターフェイス（セクション4.3.7）は、HTTP POSTリクエスト方法を受信した後、次のHTTPステータスコードを返します。
* 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.
* インターフェイスがlordnファイルを受信でき、lordnファイルの構文が正しい場合、インターフェイスはHTTP/202ステータスコードを提供します。
* 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.
* このインターフェイスは、registryによって使用されるhttpエンティティボディのlordnトランザクション識別子を提供し、lordnログファイルをダウンロードします。Lordnトランザクション識別子は、範囲00000000000000001〜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.
* TMDBは、Lordnファイルの<Lordn Creation DateTime>要素を一意のクライアント側識別子として使用します。以前に送信されたlordnファイルの同じ<lordn creation datetime>を持つlordnファイルがTMDBによって受信された場合、以前に送信されたlordnファイルのlordnトランザクション識別子をレジストリに提供する必要があります。TMDBは、同じ<Lordn Creation Datetime>を持つLordnファイルが以前に送信された場合、Lordnファイルに存在するDN行を無視する必要があります。
* The HTTP Location header field contains the URI where the LORDN Log file could be retrieved later, for example:
* HTTPロケーションヘッダーフィールドには、Lordnログファイルを後で取得できるURIが含まれています。
202 Accepted
202受け入れられました
Location: https://<tmdb-domain-name>/LORDN/example/sunrise/0000000000000000001/result
場所：https：// <tmdb-domain-name>/lordn/example/sunrise/00000000000000001/result
* The interface provides an HTTP/400 if the request is incorrect or the syntax of the LORDN file is incorrect. The TMDB MUST return a human-readable message in the HTTP Entity-body regarding the incorrect syntax of the LORDN file.
* インターフェイスは、要求が正しくない場合、またはlordnファイルの構文が正しくない場合、HTTP/400を提供します。TMDBは、lordnファイルの誤った構文に関して、HTTPエンティティボディで人間の読み取り可能なメッセージを返す必要があります。
* The interface provides an HTTP/401 status code if the credentials provided do not authorize the Registry Operator to upload a LORDN file.
* インターフェイスは、提供された資格情報がRegistryオペレーターにlordnファイルのアップロードを許可しない場合、HTTP/401ステータスコードを提供します。
* The TMDB MUST return an HTTP/404 status code when trying to upload a LORDN file using the https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/qlp or https://<tmdb-domain-name>/LORDN/<TLD>/claims/qlp interface outside of a QLP Period plus 26 hours.
* TMDBは、https：// <tmdb-domain-name>/lordn/<tld>/sunrise/qlpまたはhttps：// <tmdb-domain-を使用してlordnファイルをアップロードしようとするときに、http/404ステータスコードを返す必要があります。name>/lordn/<tld>/claims/qlpインターフェイスqlp期間と26時間以外のqlpインターフェイス。
* The interface provides an HTTP/500 status code if the system is experiencing a general failure.
* インターフェイスは、システムが一般的な障害が発生している場合、HTTP/500ステータスコードを提供します。
For example, to upload the Sunrise LORDN file for TLD "example", the URI would be:
たとえば、TLD「例」にサンライズロードファイルをアップロードするには、URIは次のとおりです。
https://<tmdb-domain-name>/LORDN/example/sunrise
https：// <tmdb-domain-name>/lordn/example/sunrise
The LORDN is contained in a CSV-formatted file that has the following structure:
Lordnは、次の構造を持つCSV形式のファイルに含まれています。
* For Sunrise Period:
* 日の出の期間：
- first line: <version>,<LORDN creation datetime>,<Number of DN Lines>
- 最初の行：<バージョン>、<lordn creation datetime>、<dn lines>
Where:
どこ：
+ <version>: version of the file. This field MUST be 1.
+ <バージョン>：ファイルのバージョン。このフィールドは1でなければなりません。
+ <LORDN creation datetime>: date and time in UTC that the LORDN was created.
+ <Lordn Creation Datetime>：Lordnが作成されたUTCの日付と時刻。
+ <Number of DN Lines>: number of DN Lines present in the LORDN file.
+ <DNラインの数>：lordnファイルに存在するDNラインの数。
- second line: a header line, as specified in [RFC4180]
- 2行目：[RFC4180]で指定されているヘッダーライン
With the header names as follows:
次のようにヘッダー名があります：
roid,domain-name,SMD-id,registrar-id,registration-datetime,application-datetime
roid、domain-name、smd-id、restional-id、登録-dateTime、application-dateTime
- One or more lines with: <roid>,<DN registered>,<SMD-id>,<IANA Registrar id>,<datetime of registration>,<datetime of application creation>
- 1つ以上の行：<roid>、<dn登録>、<smd-id>、<iana Registrar id>、<DateTime of Registration>、<DateTime of Application Creation>
Where:
どこ：
+ <roid>: DN Repository Object IDentifier (DNROID) in the SRS.
+ <Roid>：SRSのDNリポジトリオブジェクト識別子（DNroid）。
+ <DN registered>: DN that was effectively allocated. For IDNs, the A-label form is used.
+ <DN登録>：効果的に割り当てられたDN。IDNSの場合、A-Labelフォームが使用されます。
+ <SMD-id>: SMD ID used for registration.
+ <SMD-ID>：登録に使用されるSMD ID。
+ <IANA Registrar ID>: IANA Registrar ID.
+ <IANAレジストラID>：IANAレジストラID。
+ <datetime of registration>: date and time in UTC that the domain was effectively allocated.
+ <登録のDateTime>：UTCの日付と時刻は、ドメインが効果的に割り当てられたこと。
+ OPTIONAL <datetime of application creation>: date and time in UTC that the application was created. The <datetime of application creation> MUST be provided in case of a DN effective allocation based on an asynchronous registration (e.g., when using auctions).
+ オプション<アプリケーション作成のDateTime>：アプリケーションが作成されたUTCの日付と時刻。アプリケーション作成の<DateTime>は、非同期登録に基づいたDN効果的な割り当ての場合に提供する必要があります（たとえば、オークションを使用する場合）。
* Example of a Sunrise LORDN file:
* サンライズロードファイルの例：
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 12: Example Sunrise LORDN File
図12：サンライズロードファイルの例
* For the Trademark Claims Period:
* 商標請求期間について：
- first line: <version>,<LORDN creation datetime>,<Number of DN Lines>
- 最初の行：<バージョン>、<lordn creation datetime>、<dn lines>
Where:
どこ：
+ <version>: version of the file. This field MUST be 1.
+ <バージョン>：ファイルのバージョン。このフィールドは1でなければなりません。
+ <LORDN creation datetime>: date and time in UTC that the LORDN was created.
+ <Lordn Creation Datetime>：Lordnが作成されたUTCの日付と時刻。
+ <Number of DN Lines>: number of DN Lines present in the LORDN file.
+ <DNラインの数>：lordnファイルに存在するDNラインの数。
- second line: a header line, as specified in [RFC4180]
- 2行目：[RFC4180]で指定されているヘッダーライン
With the header names as follows:
次のようにヘッダー名があります：
roid,domain-name,notice-id,registrar-id,registration-datetime,ack-datetime,application-datetime
roid、domain-name、notion-id、Registrar-id、Registration-dateTime、ack-dateTime、application-dateTime
- 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>
- 1つ以上の行：<Roid>、<dn登録>、<tcnid>、<iana Registrar id>、<登録のデータタイム>、<tcn>、<アプリケーション作成の受け入れ>の受け入れ>
Where:
どこ：
+ <roid>: DNROID in the SRS.
+ <Roid>：SRSのdnroid。
+ <DN registered>: DN that was effectively allocated. For IDNs, the A-label form is used.
+ <DN登録>：効果的に割り当てられたDN。IDNSの場合、A-Labelフォームが使用されます。
+ <TCNID>: Trademark Claims Notice Identifier, as specified in <tmNotice:id>.
+ <tcnid>：<tmnotice：id>で指定されている商標請求通知識別子。
+ <IANA Registrar ID>: IANA Registrar ID.
+ <IANAレジストラID>：IANAレジストラID。
+ <datetime of registration>: date and time in UTC that the domain was effectively allocated.
+ <登録のDateTime>：UTCの日付と時刻は、ドメインが効果的に割り当てられたこと。
+ <datetime of acceptance of the TCN>: date and time in UTC that the TCN was acknowledged.
+ <TCNの受け入れ>：TCNが認められたUTCの日付と時刻。
+ OPTIONAL <datetime of application creation>: date and time in UTC that the application was created. The <datetime of application creation> MUST be provided in case of a DN effective allocation based on an asynchronous registration (e.g., when using auctions).
+ オプション<アプリケーション作成のDateTime>：アプリケーションが作成されたUTCの日付と時刻。アプリケーション作成の<DateTime>は、非同期登録に基づいたDN効果的な割り当ての場合に提供する必要があります（たとえば、オークションを使用する場合）。
For a DN matching a DNL of a PRM at the moment of registration, created without the TCNID, expiration datetime, and acceptance datetime because DNL was inserted (or reinserted) for the first time into a DNL List less than 24 hours ago, the string "recent-dnl-insertion" MAY be specified in <TCNID> and <datetime of acceptance of the TCN>.
DNLが24時間前にDNLリストに初めて挿入（または再挿入）されたため、登録時にPRMのDNLに一致するDNの場合、TCNID、有効期限の日付、および受け入れデータタイムなしで作成されました。「最近のdnl-Insertion」は、<tcnid>および<tcn>の受け入れの<データタイムで指定できます。
* Example of a Trademark Claims LORDN file:
* 商標の例は、lordnファイルを主張しています：
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 13: Example Trademark Claims LORDN File
図13：トレードマークの例は、lordnファイルを主張しています
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).
Lordnファイルを受信した後、TMDBはコンテンツを構文的および意味的正しさのために検証します。Lordnファイルの検証の出力は、YDインターフェイス（セクション4.3.7）を使用して取得されます。
The URIs of the yd interface (Section 4.3.7) used to retrieve the LORDN Log file are:
YDインターフェイスのuris（セクション4.3.7）は、lordnログファイルを取得するために使用されます。
* Sunrise LORDN Log file:
* Sunrise lordnログファイル：
* https://<tmdb-domain-name>/LORDN/<TLD>/sunrise/<lordn-transaction-identifier>/result
* https：// <tmdb-domain-name>/lordn/<tld>/sunrise/<lordn-transaction-identifier>/result
* Trademark Claims LORDN Log file:
* トレードマークはlordnログファイルを主張しています：
* https://<tmdb-domain-name>/LORDN/<TLD>/claims/<lordn-transaction-identifier>/result
* https：// <tmdb-domain-name>/lordn/<tld>/claiks/<lordn-transaction-identifier>/result
A Registry Operator MUST NOT send more than one request per minute per TLD to download a LORDN Log file.
レジストリオペレーターは、lordnログファイルをダウンロードするために、TLDあたり1分あたり1分間以上のリクエストを送信してはなりません。
The yd interface (Section 4.3.7) returns the following HTTP status codes after an HTTP GET request method is received:
YDインターフェイス（セクション4.3.7）は、HTTP GETリクエストメソッドを受信した後、次のHTTPステータスコードを返します。
* The interface provides an HTTP/200 status code if the interface was able to provide the LORDN Log file. The LORDN Log file is contained in the HTTP Entity-body.
* インターフェイスがLordnログファイルを提供できた場合、インターフェイスはHTTP/200ステータスコードを提供します。Lordnログファイルは、HTTPエンティティボディに含まれています。
* The interface provides an HTTP/204 status code if the LORDN Transaction Identifier is correct but the server has not finalized processing the LORDN file.
* Interfaceは、lordnトランザクション識別子が正しいが、サーバーがlordnファイルの処理を確定していない場合、HTTP/204ステータスコードを提供します。
* The interface provides an HTTP/400 status code if the request is incorrect.
* インターフェイスは、リクエストが正しくない場合、HTTP/400ステータスコードを提供します。
* The interface provides an HTTP/401 status code if the credentials provided do not authorize the Registry Operator to download the LORDN Log file.
* インターフェイスは、提供された資格情報が登録オペレーターにlordnログファイルをダウンロードすることを許可しない場合、HTTP/401ステータスコードを提供します。
* The interface provides an HTTP/404 status code if the LORDN Transaction Identifier is incorrect.
* Interfaceは、Lordnトランザクション識別子が正しくない場合、HTTP/404ステータスコードを提供します。
* The interface provides an HTTP/500 status code if the system is experiencing a general failure.
* インターフェイスは、システムが一般的な障害が発生している場合、HTTP/500ステータスコードを提供します。
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:
たとえば、lordnトランザクション識別子000000000000000000001およびtld "example"を備えた日の出lordnファイルの場合にlordnログファイルを取得するには、URIは次のとおりです。
https://<tmdb-domain-name>/LORDN/example/sunrise/0000000000000000001/result
https：// <tmdb-domain-name>/lordn/example/sunrise/00000000000000001/result
The LORDN Log file is contained in a CSV-formatted file that has the following structure:
Lordnログファイルは、次の構造を持つCSV形式のファイルに含まれています。
* first line: <version>,<LORDN Log creation datetime>,<LORDN file creation datetime>,<LORDN Log Identifier>,<Status flag>,<Warning flag>,<Number of DN Lines>
* 最初の行：<バージョン>、<lordn log recureation datetime>、<lordn file creation datetime>、<lordn log識別子>、<ステータスフラグ>、<警告フラグ>、<dn lines>
Where:
どこ：
o <version>: version of the file. This field MUST be 1.
o <バージョン>：ファイルのバージョン。このフィールドは1でなければなりません。
o <LORDN Log creation datetime>: date and time in UTC that the LORDN Log was created.
o <lordn log wreation datetime>：lordn logが作成されたUTCの日付と時刻。
o <LORDN file creation datetime>: date and time in UTC of creation for the LORDN file that this log file is referring to.
o <lordnファイルの作成dateTime>：このログファイルが言及しているlordnファイルの作成の日付と時刻。
o <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 base64 alphabet.
o <lordn log識別子>：tmdbが提供するlordn logの一意の識別子。この識別子は、登録オペレーターがLordnログを明確に識別するために使用できます。識別されたのは、Base64アルファベットから60文字の最大長の文字列です。
o <Status flag>: whether the LORDN file has been accepted for processing by the TMDB. Possible values are "accepted" or "rejected".
o <ステータスフラグ>：TMDBによる処理のためにLordnファイルが受け入れられているかどうか。考えられる値は「受け入れられた」または「拒否」されます。
o <Warning flag>: whether the LORDN Log has any warning result codes. Possible values are "no-warnings" or "warnings-present".
o <警告フラグ>：Lordnログに警告結果コードがあるかどうか。考えられる値は、「警戒せず」または「警告現象」です。
o <Number of DN Lines>: number of DN effective allocations processed in the LORDN file.
o <DNラインの数>：lordnファイルで処理されたDN効果的な割り当ての数。
A Registry Operator is not required to process a LORDN Log with <Status flag>="accepted" and <Warning flag>="no-warnings".
レジストリオペレーターは、<ステータスフラグ> = "eccuped"および<警告フラグ> = "nowarnings"でlordnログを処理する必要はありません。
* second line: a header line, as specified in [RFC4180]
* 2行目：[RFC4180]で指定されているヘッダーライン
With the header names as follows:
次のようにヘッダー名があります：
roid,result-code
Roid、結果コード
* One or more lines with: <roid>,<result code>
* 1つ以上の行：<Roid>、<結果コード>
Where:
どこ：
o <roid>: DNROID in the SRS.
o <Roid>：SRSのdnroid。
o <result code>: result code, as described in Section 6.3.1.1.
o <結果コード>：セクション6.3.1.1で説明されている結果コード。
Example of a LORDN Log file:
lordnログファイルの例：
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 14: Example LORDN Log File
図14：lordnログファイルの例
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:
結果コードのクラス（RC）を以下に示します。正方形の括弧内のクラスは現時点では使用されていませんが、後の段階で使用される可能性があります。結果コードの最初の2桁は、TMDBの結果を定義する結果コードクラスを示します。
* ok: Success. The DN Line is accepted by the TMDB.
* OK：成功。DNラインはTMDBによって受け入れられます。
* warn: A warning is issued. The DN Line is accepted by the TMDB.
* 警告：警告が発行されます。DNラインはTMDBによって受け入れられます。
* err: An error is issued. The LORDN file is rejected by the TMDB.
* ERR：エラーが発行されます。Lordnファイルは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.
DNラインが処理され、エラー結果コードが45xxまたは46xxの場合、lordnファイルはTMDBによって拒否されなければなりません。Lordnファイルが拒否された場合、構文的に有効なDN行は2001年の結果コードで報告されます。2001年の結果コードは、DNラインが構文的に有効であることを意味します。ただし、Lordnファイルが拒否されたため、DNラインは処理されませんでした。拒否されたlordnファイルで報告されたすべてのDNSは、lordnファイルに存在するDNラインはTMDBによって処理されていないため、レジストリによって再度報告する必要があります。
LORDN Log Result Code Classes:
lordnログ結果コードクラス：
+======+============================+=========+
| 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 |
+------+----------------------------+---------+
Table 2: LORDN Log Result Code Classes
表2：lordnログ結果コードクラス
In Table 3, the LORDN Log result codes used by the TMDB are described.
表3では、TMDBで使用されるLordnログ結果コードについて説明します。
+======+===================================================+
| 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. |
+------+---------------------------------------------------+
Table 3: LORDN Log Result Codes
表3：lordnログ結果コード
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.
このセクションでは、SMDファイルの形式を定義します。マークの登録が成功した後、TMVはSMDファイルをTMHに返します。SMDファイルは、TLDの日の出期間中にPRMでカバーされている1つ以上のDNSの登録に使用できます。
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.
カプセル化されたbase64エンコードSMDを区切るために、2つのカプセル化境界が定義されています： "----- begin encoded smd -----"および "----- endエンコードSMD -----"。検証目的では、レジストリとレジストラがカプセル化境界内のデータのみを使用する必要があります。つまり、これらの境界外のデータと境界自体は、検証目的で無視する必要があります。
The structure of the SMD File is as follows. All the elements are REQUIRED and MUST appear in the specified order.
SMDファイルの構造は次のとおりです。すべての要素が必要であり、指定された順序で表示する必要があります。
1. Marks: <marks>
1. マーク：<マーク>
2. smdID: <SMD-ID>
2. SMDID：<SMD-ID>
3. U-labels: <comma separated list of U-label or NR-LDH labels (see [RFC5890])>
3. u-labels：<u-labelまたはnr-ldhラベルのコンマ分離リスト（[rfc5890]を参照）>
4. notBefore: <begin validity>
4. それ以前：<妥当性を開始>
5. notAfter: <end validity>
5. Notafter：<終了妥当性>
6. -----BEGIN ENCODED SMD-----
6. ----- Encoded SMDを開始-----
7. <encoded SMD (see [RFC7848])>
7. <エンコードされたSMD（[rfc7848]を参照）>
8. -----END ENCODED SMD-----
8. -----エンコードされたsmd -----
Example of an SMD file:
SMDファイルの例：
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
... (base64 data elided for brevity) ...
dXJlPgo8L3NtZDpzaWduZWRNYXJrPgo=
-----END ENCODED SMD-----
Figure 15: Example SMD File
図15：SMDファイルの例
The TMDB MUST provide the TCN to Registrars in XML format, as specified below.
TMDBは、以下に指定するように、XML形式のレジストラにTCNを提供する必要があります。
The enclosing element <tmNotice:notice> describes the Trademark Notice to a given label.
囲まれた要素<tmnotice：nocation>特定のラベルへの商標通知について説明します。
The child elements of the <tmNotice:notice> element include:
<tmnotice：nocation>要素の子要素は次のとおりです。
* A <tmNotice:id> element that contains the unique identifier of the Trademark Notice. This element contains the TCNID.
* a <tmnotice：id>商標通知の一意の識別子を含む要素。この要素にはtcnidが含まれています。
The TCNID is a string concatenation of a TCN Checksum and the TMDB Notice Identifier. The first 8 characters of the TCNID is a TCN Checksum. The rest is the TMDB Notice Identifier, which is a zero-padded natural number in the range of 0000000000000000001 to 9223372036854775807.
TCNIDは、TCNチェックサムとTMDB通知識別子の文字列連結です。TCNIDの最初の8文字はTCNチェックサムです。残りはTMDB通知識別子です。これは、0000000000000000001〜9223372036854775807の範囲のゼロパッドの自然数です。
Example of a TCNID:
tcnidの例：
370d0b7c9223372036854775807.
370D0B7C9223372036854775807。
Where:
どこ：
o TCN Checksum=370d0b7c
o TCN Checksum = 370D0B7C
o TMDB Notice Identifier=9223372036854775807
o TMDB通知識別子= 9223372036854775807
The TCN Checksum is an 8-character-long base16-encoded output of computing the CRC32 of the string concatenation of: label + unix_timestamp(<tmNotice:notAfter>) + TMDB Notice Identifier.
TCNチェックサムは、次のような文字列のcrc32を計算する8文字長ベース16エンコード出力です。
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:
TMDBは、UTCの<TMnotice：notafter>のUnix時間変換を使用して、TCNチェックサムを計算する必要があります。UNIX時間は、1970-01-01T00：00：00Z以降に経過した秒数として定義され、左秒をカウントしません。たとえば、2010-08-16T09：00：00.0zからUNIX時間への変換は次のとおりです。
unix_time(2010-08-16T09:00:00.0Z)=1281949200
UNIX_TIME（2010-08-16T09：00：00.0Z）= 1281949200
The TMDB uses the <tmNotice:label> and <tmNotice:notAfter> elements from the TCN along with the TMDB Notice Identifier to compute the TCN Checksum.
TMDBは、TCNチェックサムを計算するためにTMDB通知識別子とともに、TCNからの<TMNotice：label>および<tmnotice：notafter>要素を使用します。
A Registry MUST use the leftmost DNL of the DN being effectively allocated, the expiration datetime of the TCN (provided by the Registrar), and the TMDB Notice Identifier extracted from the TCNID (provided by the Registrar) to compute the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- mgbh0fb" is being effectively allocated, the leftmost DNL would be "xn--mgbachtv".
レジストリは、効果的に割り当てられているDNの左端DNL、TCNの有効期限データ（レジストラが提供）、およびTCNIDから抽出されたTMDB通知識別子（レジストラが提供）からTCNチェックサムを計算する必要があります。たとえば、dn "xn - mgbachtv.xn-- mgbh0fb"が効果的に割り当てられている場合、左端のdnlは「xn - mgbachtv」になります。
An example computation of the TCN Checksum is:
TCNチェックサムの計算の例は次のとおりです。
CRC32(example-one12819492009223372036854775807)=370d0b7c
CRC32（例1128194920092237203685475807）= 370D0B7C
* A <tmNotice:notBefore> element that contains the start of the valid date and time of the TCN.
* a <tmnotice：tcnの有効な日付と時刻の開始を含むnotbefore>要素。
* A <tmNotice:notAfter> element that contains the expiration date and time of the TCN.
* a <tmnotice：notafter> TCNの有効期限と時刻を含む要素。
* A <tmNotice:label> element that contains the DNL covered by a PRM.
* a <tmnotice：label> prmで覆われたDNLを含む要素。
* One or more <tmNotice:claim> elements that contain the Trademark Claims. The <tmNotice:claim> element contains the following child elements:
* 1つ以上の<tmnotice：クレーム>商標請求を含む要素。<tmnotice：クレーム>要素には、次の子要素が含まれています。
- A <tmNotice:markName> element that contains the mark text string.
- a <tmnotice：markname>マークテキスト文字列を含む要素。
- 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:
- 1つ以上の<tmnotice：Holder>マークの保有者の情報を含む要素。「資格」属性を使用して、所有者の資格を識別します。考えられる値は、所有者、譲受人、またはライセンシーです。<tmnotice：Holder>の子要素> include：
o An OPTIONAL <tmNotice:name> element that contains the name of the holder. <tmNotice:name> MUST be specified if <tmNotice:org> is not specified.
o オプション<tmnotice：name> Holderの名前を含む要素。<tmnotice：name> <tmnotice：org>が指定されていない場合は指定する必要があります。
o An OPTIONAL <tmNotice:org> element that contains the name of the organization holder of the mark. <tmNotice:org> MUST be specified if <tmNotice:name> is not specified.
o マークの組織保有者の名前を含むオプション<tmnotice：org>要素。<tmnotice：org> <tmnotice：name>が指定されていない場合は指定する必要があります。
o A <tmNotice:addr> element that contains the address information of the holder of a mark. <tmNotice:addr> contains the following child elements:
o a <tmnotice：addr>マークの所有者のアドレス情報を含む要素。<tmnotice：addr>には、次の子要素が含まれています。
+ One, two, or three OPTIONAL <tmNotice:street> elements that contain the organization's street address.
+ 1つ、2つ、または3つのオプション<tmnotice：Street>組織の通りの住所を含む要素。
+ A <tmNotice:city> element that contains the organization's city.
+ <tmnotice：city>組織の都市を含む要素。
+ An OPTIONAL <tmNotice:sp> element that contains the organization's state or province.
+ 組織の州または州を含むオプション<tmnotice：sp>要素。
+ An OPTIONAL <tmNotice:pc> element that contains the organization's postal code.
+ 組織の郵便番号を含むオプション<tmnotice：pc>要素。
+ A <tmNotice:cc> element that contains the organization's country code. This a two-character code from [ISO3166-2].
+ <tmnotice：cc>組織の国コードを含む要素。これは[ISO3166-2]の2文字のコードです。
o An OPTIONAL <tmNotice:voice> element that contains the organization's voice telephone number.
o オプションの<tmnotice：Voice>組織の音声電話番号を含む要素。
o An OPTIONAL <tmNotice:fax> element that contains the organization's facsimile telephone number.
o 組織のファクシミリの電話番号を含むオプションの<tmnotice：fax>要素。
o An OPTIONAL <tmNotice:email> element that contains the email address of the holder.
o オプション<tmnotice：電子メール>ホルダーの電子メールアドレスを含む要素。
- 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:
- ゼロ以上オプション<tmnotice：連絡先>マーク登録の代表者の情報を含む要素。「タイプ」属性を使用して、連絡先のタイプを識別します。考えられる値は次のとおりです。所有者、エージェント、またはサードパーティ。<tmnotice：連絡先の子要素> include：
o A <tmNotice:name> element that contains the name of the responsible person.
o <tmnotice：name>責任者の名前を含む要素。
o An OPTIONAL <tmNotice:org> element that contains the name of the organization of the contact.
o 連絡先の組織の名前を含むオプション<tmnotice：org>要素。
o A <tmNotice:addr> element that contains the address information of the contact. <tmNotice:addr> contains the following child elements:
o a <tmnotice：addr>連絡先のアドレス情報を含む要素。<tmnotice：addr>には、次の子要素が含まれています。
+ One, two, or three OPTIONAL <tmNotice:street> elements that contain the contact's street address.
+ 1つ、2つ、または3つのオプション<tmnotice：Street>連絡先の通りの住所を含む要素。
+ A <tmNotice:city> element that contains the contact's city.
+ <tmnotice：city>連絡先の都市を含む要素。
+ An OPTIONAL <tmNotice:sp> element that contains the contact's state or province.
+ オプションの<tmnotice：sp>連絡先の状態を含む要素。
+ An OPTIONAL <tmNotice:pc> element that contains the contact's postal code.
+ オプション<TMNOTICE：PC>連絡先の郵便番号を含む要素。
+ A <tmNotice:cc> element that contains the contact's country code. This a two-character code from [ISO3166-2].
+ a <tmnotice：CC>連絡先の国コードを含む要素。これは[ISO3166-2]の2文字のコードです。
o A <tmNotice:voice> element that contains the contact's voice telephone number.
o a <tmnotice：Voice>連絡先の音声電話番号を含む要素。
o An OPTIONAL <tmNotice:fax> element that contains the contact's facsimile telephone number.
o 連絡先のファクシミリの電話番号を含むオプションの<tmnotice：fax>要素。
o A <tmNotice:email> element that contains the contact's email address.
o a <tmnotice：電子メール>連絡先のメールアドレスを含む要素。
- A <tmNotice:jurDesc> element that contains the name (in English) of the jurisdiction where the mark is protected. A jurCC attribute contains the two-character code of the jurisdiction where the mark was registered. This is a two-character code from [WIPO.ST3].
- a <tmnotice：Jurdesc>マークが保護されている管轄区域の名前（英語）を含む要素。JURCC属性には、マークが登録された管轄区域の2文字のコードが含まれています。これは[wipo.st3]の2文字のコードです。
- Zero or more OPTIONAL <tmNotice:classDesc> elements that contain the description (in English) of the Nice Classification, as defined in [WIPO-NICE-CLASSES]. A classNum attribute contains the class number.
- ゼロ以上のオプション<TMNOTICE：classDesc> [Wipo-nice-classes]で定義されているように、素敵な分類の説明（英語）を含む要素。ClassNum属性にはクラス番号が含まれます。
- A <tmNotice:goodsAndServices> element that contains the full description of the goods and services mentioned in the mark registration document.
- a <tmnotice：goodsandservices>マーク登録文書に記載されている商品とサービスの完全な説明を含む要素。
- 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:
- オプションの<tmnotice：notexactmatch>要素は、正確な一致（[matchingrules]で定義）以外のルール（[請求50]など）に基づいてTCNに請求通知が追加されたことを示しています。<tmnotice：notexactmatch>には、次の1つ以上が含まれています。
o 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:
o オプション<TMNOTICE：UDRP>要素は、均一なドメイン名紛争解決ポリシー（UDRP）ケースに以前に乱用された名前が含まれているためにクレーム通知が追加されたことを示しています。<tmnotice：udrp> contas：
+ A <tmNotice:caseNo> element that contains the UDRP case number used to validate the previously abused name.
+ a <tmnotice：caseno>以前に乱用された名前の検証に使用されるUDRPケース番号を含む要素。
+ A <tmNotice:udrpProvider> element that contains the name of the UDRP provider.
+ a <tmnotice：udrpprovider> UDRPプロバイダーの名前を含む要素。
o 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:
o オプション<tmnotice：court> court> court> court> court> court> court> court> court> court> court> court> courtは、裁判所の決議に含まれていた以前に虐待されていた名前のために追加されたことを示しています。<tmnotice：court> contains：
+ A <tmNotice:refNum> element that contains the reference number of the court's resolution used to validate the previously abused name.
+ <tmnotice：refnum>以前に乱用された名前を検証するために使用された裁判所の決議の参照番号を含む要素。
+ A <tmNotice:cc> element that contains the two-character code from [ISO3166-2] of the jurisdiction of the court.
+ <tmnotice：cc>裁判所の管轄権の[ISO3166-2]の2文字コードを含む要素。
+ A <tmNotice:courtName> element that contains the name of the court.
+ A <tmnotice：裁判所の名前を含むcourtname>要素。
Example of a <tmNotice:notice> object:
<tmnoticeの例：nocation> object：
<?xml version="1.0" encoding="UTF-8"?>
<tmNotice:notice
xmlns:tmNotice="urn:ietf:params:xml:ns:tmNotice-1.0">
<tmNotice:id>370d0b7c9223372036854775807</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">USA</tmNotice:jurDesc>
<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.
</tmNotice:goodsAndServices>
</tmNotice:claim>
<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.
</tmNotice:goodsAndServices>
</tmNotice:claim>
<tmNotice:claim>
<tmNotice:markName>One</tmNotice:markName>
<tmNotice:holder entitlement="owner">
<tmNotice:org>One Corporation</tmNotice:org>
<tmNotice:addr>
<tmNotice:street>Otra calle</tmNotice:street>
<tmNotice:city>Otra ciudad</tmNotice:city>
<tmNotice:sp>OT</tmNotice:sp>
<tmNotice:pc>383742</tmNotice:pc>
<tmNotice:cc>CR</tmNotice:cc>
</tmNotice:addr>
</tmNotice:holder>
<tmNotice:jurDesc jurCC="CR">COSTA RICA</tmNotice:jurDesc>
<tmNotice:goodsAndServices>
Bardus populorum circumdabit se cum captiosus populum.
Smert populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices>
<tmNotice:notExactMatch>
<tmNotice:court>
<tmNotice:refNum>234235</tmNotice:refNum>
<tmNotice:cc>CR</tmNotice:cc>
<tmNotice:courtName>Supreme Court of Spain</tmNotice:courtName>
</tmNotice:court>
</tmNotice:notExactMatch>
</tmNotice:claim>
<tmNotice:claim>
<tmNotice:markName>One Inc</tmNotice:markName>
<tmNotice:holder entitlement="owner">
<tmNotice:org>One SA de CV</tmNotice:org>
<tmNotice:addr>
<tmNotice:street>La calle</tmNotice:street>
<tmNotice:city>La ciudad</tmNotice:city>
<tmNotice:sp>CD</tmNotice:sp>
<tmNotice:pc>34323</tmNotice:pc>
<tmNotice:cc>AR</tmNotice:cc>
</tmNotice:addr>
</tmNotice:holder>
<tmNotice:jurDesc jurCC="AR">ARGENTINA</tmNotice:jurDesc>
<tmNotice:goodsAndServices>
Bardus populorum circumdabit se cum captiosus populum.
Smert populorum circumdabit se cum captiosus populum.
</tmNotice:goodsAndServices>
<tmNotice:notExactMatch>
<tmNotice:udrp>
<tmNotice:caseNo>D2003-0499</tmNotice:caseNo>
<tmNotice:udrpProvider>WIPO</tmNotice:udrpProvider>
</tmNotice:udrp>
</tmNotice:notExactMatch>
</tmNotice:claim>
</tmNotice:notice>
Figure 16: Example <tmNotice:notice> Object
図16：例<tmnotice：nocation>オブジェクト
For the formal syntax of the TCN, please refer to Section 7.1.
TCNの正式な構文については、セクション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.
このセクションでは、日の出の対象となるPRMに一致するすべてのDNLを含むリストの形式を定義します。リストはTMDBによって維持され、レジストリによって通常の間隔でダウンロードされます（セクション5.4.2.1を参照）。レジストリは、QLP期間中にサンライズリストを使用して、要求されたDNが日の出の対象となるPRMのDNLと一致するかどうかを確認します。
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.
サンライズリストには、生成されたデータタイム時にTMDBに存在する日の出の対象となるPRMで覆われたすべてのDNLが含まれています。
The Sunrise List is contained in a CSV-formatted file that has the following structure:
サンライズリストは、次の構造を持つCSV形式のファイルに含まれています。
* first line: <version>,<Sunrise List creation datetime>
* 最初の行：<バージョン>、<サンライズリスト作成DATETIME>
Where:
どこ：
o <version>: version of the file. This field MUST be 1.
o <バージョン>：ファイルのバージョン。このフィールドは1でなければなりません。
o <Sunrise List creation datetime>: date and time in UTC that the Sunrise List was created.
o <Sunrise List Creation DateTime>：日の出リストが作成されたUTCの日付と時刻。
* second line: a header line, as specified in [RFC4180]
* 2行目：[RFC4180]で指定されているヘッダーライン
With the header names as follows:
次のようにヘッダー名があります：
DNL,insertion-datetime
dnl、挿入-dateTime
* One or more lines with: <DNL>,<DNL insertion datetime>
* 1つ以上の行：<dnl>、<dnl挿入dateTime>
Where:
どこ：
o <DNL>: a Domain Name Label covered by a PRM eligible for Sunrise.
o <DNL>：日の出の対象となるPRMでカバーされているドメイン名ラベル。
o <DNL insertion datetime>: datetime in UTC that the DNL was first inserted into the Sunrise List. The possible two values of time for inserting a DNL to the Sunrise List are 00:00:00 and 12:00:00 UTC.
o <DNL挿入DateTime>：DNLが最初に日の出リストに挿入されたというUTCのDateTime。DNLを日の出リストに挿入するための時間の2つの値は、00:00:00および12:00:00 UTCです。
Example of a Sunrise List:
日の出リストの例：
1,2012-08-16T00:00:00.0Z
DNL,insertion-datetime
example,2010-07-14T00:00:00.0Z
another-example,2012-08-16T00:00:00.0Z
anotherexample,2011-08-16T12:00:00.0Z
Figure 17: Example Sunrise List
図17：サンプルリストの例
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.
認証と整合性の保護を提供するために、日の出リストはTMDBによって署名されます（セクション5.1.1.4を参照）。日の出リストのPGP署名は、同様のURIで見つけることができますが、以下に示すように、拡張子sigを使用します。
The URLs of the dy interface (Section 4.3.3) are:
DYインターフェイスのURL（セクション4.3.3）は次のとおりです。
* https://<tmdb-domain-name>/dnl/surl-latest.csv
* https：// <tmdb-domain-name> /dnl/surl-latest.csv
* https://<tmdb-domain-name>/dnl/surl-latest.sig
* https：// <tmdb-domain-name> /dnl/surl-latest.sig
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.
コードが開始され、コードエンドタグはスキーマの一部ではありません。それらは、URI登録目的でスキーマの開始と終了に注意するために使用されます。
<?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>
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.
このドキュメントでは、URNSを使用して、[RFC3688]に記載されているレジストリメカニズムに準拠したXMLネームスペースとXMLスキーマを記述します。IANAは次のように2つのURI割り当てを登録しています。
Trademark Claims Notice namespace:
商標請求通知の名前空間：
URI:
URI：
urn:ietf:params:xml:ns:tmNotice-1.0
urn：ietf：params：xml：ns：tmnotice-1.0
Registrant Contact:
登録者の連絡先：
IETF <iesg@ietf.org> and ICANN <globalsupport@icann.org>
ietf <iesg@ietf.org>およびicann <globalsupport@icann.org>
XML:
XML：
None. Namespace URIs do not represent an XML specification.
なし。名前空間URIはXML仕様を表していません。
Note:
注記：
Note that this assignment is made from the wrong point in the tree in order to be consistent with deployed implementations.
この割り当ては、展開された実装と一致するために、ツリーの間違ったポイントから行われることに注意してください。
Trademark Claims Notice XML schema:
商標請求XMLスキーマは請求します：
URI:
URI：
urn:ietf:params:xml:schema:tmNotice-1.0
urn：ietf：params：xml：schema：tmnotice-1.0
Registrant Contact:
登録者の連絡先：
IETF <iesg@ietf.org> and ICANN <globalsupport@icann.org>
ietf <iesg@ietf.org>およびicann <globalsupport@icann.org>
XML:
XML：
See Section 7.1 of RFC 9361.
RFC 9361のセクション7.1を参照してください。
Note:
注記：
Note that this assignment is made from the wrong point in the tree in order to be consistent with deployed implementations.
この割り当ては、展開された実装と一致するために、ツリーの間違ったポイントから行われることに注意してください。
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.
この仕様では、HTTP基本認証を使用して、簡単なアプリケーション層認証サービスを提供します。HTTPSは、最も一般的な攻撃から保護するために、すべてのインターフェイスで使用されます。さらに、クライアント識別子は、このドキュメントで説明されているインターフェイスに接続できるIPアドレスのセットに関連付けられており、追加のセキュリティ尺度を提供します。
The TMDB MUST provide credentials to the appropriate Registries and Registrars.
TMDBは、適切なレジストリとレジストラに資格情報を提供する必要があります。
The TMDB MUST require the use of strong passwords by Registries and Registrars.
TMDBは、レジストリとレジストラによって強力なパスワードを使用する必要があります。
The TMDB, Registries, and Registrars MUST use the best practices described in [RFC9325] or its successors.
TMDB、レジストリ、およびレジストラは、[RFC9325]またはその後継者に記載されているベストプラクティスを使用する必要があります。
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.
この仕様では、[RPM要約]をサポートするインターフェイスを定義します。法的文書は、さまざまな当事者間の相互作用を管理しており、そのような法的文書は、プライバシーに敏感なおよび/または個人データが必要な保護を受けることを保証する必要があります。
[Claims50] ICANN, "Implementation Notes: Trademark Claims Protection
for Previously Abused Names", July 2013,
<https://newgtlds.icann.org/en/about/trademark-
clearinghouse/previously-abused-16jul13-en.pdf>.
[MatchingRules]
ICANN, "Explanatory Memorandum: Implementing the Matching
Rules", July 2016, <https://newgtlds.icann.org/en/about/
trademark-clearinghouse/matching-rules-14jul16-en.pdf>.
[QLP-Addendum]
ICANN, "Trademark Clearinghouse Rights Protection
Mechanism Requirements: Qualified Launch Program
Addendum", April 2014,
<https://newgtlds.icann.org/en/about/trademark-
clearinghouse/rpm-requirements-qlp-addendum-
10apr14-en.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping",
RFC 7848, DOI 10.17487/RFC7848, June 2016,
<https://www.rfc-editor.org/info/rfc7848>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RPM-Requirements]
ICANN, "Trademark Clearinghouse Rights Protection
Mechanism Requirements", September 2013,
<https://newgtlds.icann.org/en/about/trademark-
clearinghouse/rpm-requirements-30sep13-en.pdf>.
[W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Fifth Edition)", W3C Recommendation REC-xml-20081126,
November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>.
[W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", W3C
Recommendation REC-xmlschema-1-20041028, October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation REC-xmlschema-
2-20041028, October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
[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>.
[ISO3166-2]
ISO, "International Standard for country codes and codes
for their subdivisions",
<http://www.iso.org/iso/home/standards/country_codes.htm>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/info/rfc4180>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>.
[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, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[WIPO-NICE-CLASSES]
WIPO, "Nice Classification",
<http://www.wipo.int/classifications/nice/en>.
[WIPO.ST3] WIPO, "Recommended standard on two-letter codes for the
representation of states, other entities and
intergovernmental organizations", November 2022,
<https://www.wipo.int/export/sites/www/standards/en/
pdf/03-03-01.pdf>.
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.
この仕様は、ICANNコミュニティの数人の参加者からの共同作業です。Bernie Hoeneisenは、このドキュメントの最初のドラフトバージョンの共著者として参加し、非常に貴重なサポートを提供しました。この仕様は、クリス・ライト、ジェフ・ノイマン、ジェフ・エッカウスが主導するモデルに基づいており、短くなります。著者はまた、TMCH-Techのメーリングリストで多くの人が提供した思慮深いフィードバックに感謝したいが、特にジェームズ・グールド、ジェームズ・ミッチェル、フランシスコ・アリアスが提供する広範なヘルプ。このドキュメントには、Paul Hoffmanから受け取ったフィードバックが含まれています。
Gustavo Lozano
ICANN
12025 Waterfront Drive
Suite 300
Los Angeles, 90292
United States of America
Phone: +1.310.301.5800
Email: gustavo.lozano@icann.org