Skip to main content
Resources

追加の登録データディレクトリサービス(RDDS)情報ポリシー

このページは以下の言語でもご覧いただけます。

すべての翻訳されたコンテンツおよび文書の英語版が公式版であり、英語以外の言語の翻訳版は情報提供のみを目的として作成されたものです。

登録データポリシーの実施に必要な変更を反映するため、2024年2月21日に更新。このポリシーは、以前は追加Whois情報ポリシーと呼ばれていました。契約当事者は2024年8月21日から更新された本ポリシーを実施することが可能であり、遅くとも2025年8月21日までには実施する必要があります。

本ドキュメントのキーワード「必要があります」、「禁止されています」、「必要になります」、「するものとします」、「するものではない」、「すべき」、「すべきではない」、「推奨される」、「推奨されない」、「できます」、および「任意の」は、BCP14 [RFC2119] [RFC8174]の規定どおりに解釈されます。

本ポリシーのセクション1では、すべての登録データディレクトリサービスに適用される、技術的および非技術的な要件の詳細を説明します。

本ポリシーのセクション2では、WHOIS(ポート43を介して利用可能)およびWebベースのWhoisディレクトリサービスのみに関する実装要件の詳細を説明します。

ICANN認定レジストラおよびジェネリックトップレベルドメイン(gTLD)レジストリは、特定の登録データにクエリーベースのアクセスできるようにするため、ICANNとのそれぞれの契約内容に準拠する必要があります。この追加のRDDS情報ポリシーにより、レジストラおよびレジストリはそれぞれのRDDS出力情報に追加情報を含めることが求められます。これにより、RDDSユーザーは登録のスポンサーとなるレジストラを識別し、レジストリおよびレジストラが使用するステータスコードを理解しやすくなります。

  1. レジストリオペレータおよびレジストラは、以下の要件を実装するものとします。

    1.1 以下のメッセージをRDDS出力に含めます。「ドメインステータスコードの詳細は、https://icann.org/eppを参照してください。」*‬

    * 以前にセクション1(c)に含まれていた上記リンクの長い形式、つまりhttps://www.icann.org/resources/pages/epp-status-codes-2014-06-16-enもこのポリシーに準拠しています。

    1.2 レジストリはICANNが発行したGURID(Globally Unique Registrar Identification)番号(一般にIANA IDとして知られる)をRDDS出力で使用する必要があります。

  2. レジストリオペレータおよびレジストラは、WHOIS(ポート43を介して利用可能)およびWebベースのWHOISディレクトリサービスについて、以下の要件を実装するものとします。

    2.1 ステータスは、それぞれのEPPステータスコードを使用して表示する必要があります。

    2.2 各EPPステータスコードについて説明および定義しているICANNのWebページへのリンクまたはURLをEPPステータスの横に表示する必要があります。URLのリストは、https://www.icann.org/resources/pages/epp-status-codes-list-2014-06-18-enで参照できます。

    2.3 レジストラは自身または別のレジストラまたはレジストリのWhoisサービスからWhoisデータを提供するとき、上記のリンクおよびメッセージを削除しないものとします。

注:追加のWhois情報ポリシー(AWIP)は、追加の登録データディレクトリサービス(ARIP)に名前が変更され、2012年5月6日にICANNのコンセンサスポリシーとして採択されました。このポリシーは2016年1月31日に有効になります。ICANN認定レジストラおよびgTLDレジストリは、有効日を以って、認定されたか、または管理するすべてのgTLDで、自身がスポンサーとなる登録について、ARIPに準拠する必要があります。

このポリシーの目的は、EPPステータスコードの意味をRDDSデータで明確にし、RDDSでGURIDによるレジストラの一貫性のある識別を求めることです。

背景:2009年6月24日、PDP(ポリシー策定プロセス:Policy Development Process)がIRTP(Inter-Registrar Transfer Policy:レジストラ間の移転ポリシー)に関連して立ち上げた立ち上げたGNSO評議会(http://gnso.icann.org/en/council/resolutions#200906 – 決議 20090624-2)およびPDPワーキンググループ(IRTPワーキンググループB)が、勧告#8:「レジストラロック」ステータスに関するRDDSステータスメッセージの標準化および明瞭化を含む最終報告書を勧告事項一式と共に2011年5月30日に提出しました(http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf [PDF、971 KB])。2011年6月22日、GNSO評議会は、「レジストラロック」ステータスに関するRDDSステータスメッセージの標準化および明瞭化に関する勧告の承認について考慮する前に、ICANNのスタッフにこの勧告を満たすために技術的に実現可能な方策を確実に開発できるような提案を提供するように要求することを決議しました。この要求に対して、ICANNのスタッフはワーキンググループと相談して提案を作成し、パブリックコメント向けに投稿し、最終的に2012年2月16日にGNSO評議会にて採択されました(http://gnso.icann.org/en/council/resolutions#20120216-1)。勧告および提案に関する別のパブリックコメントフォーラムにの後に(http://www.icann.org/en/news/public-comment/irtp-b-rec8-21feb12-en.htm)、ICANN理事会はこれらを2012年5月6日に採択しました。(https://www.icann.org/en/groups/board/documents/resolutions-06may12-en.htm#1.5

‭別のGNSOワーキンググループ(IRTPワーキンググループC)には、2011年9月22日に、レジストリがレジストリに独自のIDではなくIANA IDを使用する要件によりプロセスを合理化できるかどうかなど、IRTPに関する3つの疑問について検討しました(https://community.icann.org/display/gnsoirtppdpwg/3.+WG+Charter)。このワーキンググループはパブリックコメントの対象となる一次報告書を発表し、続く最終報告書は2012年10月17日にGNSO評議会に採択されました。別のパブリックコメントフォーラムの後、ICANN取締役会は最終報告書の勧告を2012年12月20日付で採択しました(http://www.icann.org/en/groups/board/documents/minutes-20dec12-en.htm#2.a)。

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."