Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from https://www.icann.org?

If you want to sign out from both https://www.icann.org and ICANN Account, click here.

Contracted Parties

ICANN’s contracted parties consist of generic top-level domain (gTLD) registry operators and accredited registrars.

In addition to the ICANN Languages, this content is also available in

アドバイザリ：レジストリ契約および2013年レジストラ認定契約（RAA）に適用される登録データディレクトリサービス（WHOIS）の仕様に関する説明

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

発行日2015年4月27日 – 注：このアドバイザリは、2014年9月12日に公表された以下のアドバイザリよりも優先されます。 https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014-09-12-en

このアドバイザリは、それぞれレジストリ契約およびレジストラ認定契約を遵守するために必要となる適切な登録データディレクトリサービス（WhoisまたはRDDS）の仕様をレジストリとレジストラの明確に伝えることを目的としています。

セクションIの説明は、レジストリとレジストラの両方に適用されます。セクションIIはレジストリにのみ適用されます。セクションIIIはレジストラにのみ適用されます。レジストリおよびレジストラが現在利用しているシステムに、これらの説明を取り入れるのに十分な時間を確保するため、2016年1月31日からこの施行が開始されます。

これらの説明の目的の1つは、出力を簡単に解析できるようにすることです。この問題について関心のあるユーザーは、RDDS出力のパーサーを開発する際に、以下の説明について検討することを推奨します。

「～することができる」、「～する必要がある」、「～してはならない」、「～することが必要である」、「～する必要はない」、「～するべきである」という用語は、RFC 2119に準拠する要件レベルを示すために使用されます。RFC 2119 [TXT, 5 KB]は、http://www.ietf.org/rfc/rfc2119.txt [TXT, 5 KB]で参照できます。

  1. 以下の説明は、レジストリおよびレジストラ登録データディレクトリサービス仕様の両方に適用されます。

    1. 2013 RAA（レジストラに適用）のRDDS仕様のセクション1.4.2、またはレジストリ契約（レジストリに適用）の仕様4のセクション1.5、1.6、および1.7に記載されているすべてのフィールド（例、行）は、特に明記しない限り、存在している必要があります。

      オブジェクトクエリーの各タイプ（ドメイン名、レジストラ、またはネームサーバー）について、このアドバイザリでは、いくつかのフィールドがオプションとして特定されています。契約当事者の登録システム（SRS）にデータが存在しないオプションフィールドの場合、契約当事者は以下のいずれかのように指定する必要があります。1）フィールドの値セクション（つまり、コロンの右側）に情報がないキー（つまり、コロンの左側の文字列）を表示する。または、2）フィールドを1つも表示しない。指定されたオプションのフィールドにデータが存在する場合は、キーとデータの値を表示する必要があります。

    2. ドメイン名オブジェクトクエリーに対する応答では、以下のフィールドはオプションと見なされ、説明1のように取り扱う必要があります。

      • 更新日（ドメイン名が作成されてから更新されていない場合）
      • レジストラント/管理担当者/技術担当者の組織
      • レジストラント/管理担当者/技術担当者の州名
      • レジストラント/管理担当者/技術担当者の郵便番号
      • レジストラント/管理担当者/技術担当者の内線電話
      • レジストラント/管理担当者/技術担当者のファックス
      • レジストラント/管理担当者/技術担当者の内線ファックス
      • ネームサーバー

      たとえば、ネームサーバーがないドメイン名クエリーでは、次の2つの出力のいずれかを生成できます。

      …
      技術担当者の電子メール: [email protected]
      ネームサーバー:
      DNSSEC: unsigned
      …

      または

      …
      技術担当者の電子メール:[email protected]
      DNSSEC: unsigned
      …

    3. RFC 3912で説明されているように、WHOISプロトコル（ポート43）は国際化されていません。代替プロトコルの開発がIETFで進められていますが、レジストリとレジストラは、WHOIS（ポート43）出力にUS-ASCIIのエンコードと文字レパートリーのみを使用することを推奨します。レジストリ運用者/レジストラがUS-ASCIIレパートリー以外の文字を使用する場合には、相互運用性を最大限に確保するため、出力をUTF-8でエンコードする必要があります。

    4. Whoisの出力で、他の言語のキーの名前が翻訳されて表示される場合がありますが、キーの最初の項目は、契約書に表示されているように指定する必要があり、翻訳は括弧（U+0028とU+0029）で囲み、フィールドのキー（場合に応じて、2013 RAAまたはレジストリ契約で指定されているもの）と開き括弧（U+0028）の間にスペース（U+0020）を入れる必要があります。異なる翻訳は、斜線（U+002F）で区切る必要があります。閉じ括弧（U+0029）はコロンの直前に配置する必要があります。キーの名前の翻訳と括弧（U+0028とU+0029）の間にスペースを入れることはできません。斜線（U+002F）の間にスペースを入れることはできません。

      たとえば、「ドメイン名:」はスペイン語とポルトガル語では以下のように表示される場合があります。

      ドメイン名 （Nombre de Dominio/Nome de Domínio）: foo.example

    5. 2013 RAAのセクション1.4.2およびレジストリ契約の仕様4のセクション1.5、1.6、1.7に記載されているフィールドの値にあるすべてのドメイン名ラベル（例、ドメイン名、ネームサーバー、電子メール）は、ASCIIと互換性のある形式（A-Label）で表示する必要があります。

      たとえば、IDNラベルがあるネームサーバーは、次のように表示されます。

      ネームサーバー: ns1.xn--caf-dma.example

    6. ドメイン名がIDNである場合、レジストリ運用者/レジストラは、「国際化されたドメイン名:」キーを使用してIDNをU-Labelの形式で表示できます。表示される場合、フィールドは、説明11で定義される追加のフィールドとして、またはフィールド「ドメイン名」の直後に表示されなければなりません。例：

      ドメイン名: xn--caf-dma.example
      国際化されたドメイン名: café.example
      …

      または

      …
      DNSSEC: signedDelegation
      国際化されたドメイン名: café.example

    7. ドメインのステータスは、EPP RFC 5730-5734および3915で指定されるマッピングに準拠する必要があります。AWIP（https://www.icann.org/resources/pages/policy-awip-2014-07-02-en）に従って、EPPのステータスの直後には、少なくとも1個以上で9個以下のスペース（U+0020）が続く必要があり、その後にICANN Webサイトのステータスの説明に対応するURLが続く必要があります。例については、説明11を参照してください。

    8. フッターに表示される日付と時刻「>>> Whoisデータベースの最終更新日: <日付と時刻> <<<」は、RDDSデータベースがSRSデータベースから更新された日時（RFC 3339の形式）を示します。2013 RAAのセクション1.4.2およびレジストリ契約の仕様10に記載されているサービスレベルの要件に従って、RDDSサービスは変更後60分以内に更新する必要があります。契約当事者がSRSデータベースを直接クエリーしている場合には、リアルタイムデータを使用して、この日時にクエリーに対する応答のタイムスタンプが表示されます。

    9. ネームサーバーのIPアドレスは、ドメイン名のWhoisクエリーの出力には表示しないようにしてください。表示される場合、ネームサーバーオブジェクトの応答のために使用されるため、対応するネームサーバーの直後にIPアドレスを表示する必要があります。

    10. クエリーされているドメイン名のSRSに1つ以上のDSまたはDNSKEYレコードがある場合に、「DNSSEC: signedDelegation」が表示される必要があります。それ以外の場合は、「DNSSEC: unsigned」を表示する必要があります。

    11. データフィールドは、2013 RAA（レジストラの場合）またはレジストリ契約（レジストリの場合）で指定された形式（キーの順序を含む）で表示する必要があります。追加のデータフィールドがWHOISの出力に含まれている場合、追加のデータフィールドは、このアドバイザリに別段の記載がある場合を除いて、レジストリ契約または2013 RAAに記載されているテキスト形式の最後に配置する必要があります。たとえば、ドメイン名オブジェクトの応答では、レジストリの場合、DNSSECフィールドの後、レジストラの場合、「ICANN WHOISデータ問題報告システムのURL」フィールドの後ろになります。（注：レジストリ契約の仕様4のセクション1.4で規定されているように、レジストリ運用者は、Whois出力にフィールドを追加する前にICANNから承認を得る必要があります（つまり、RSEPプロセスを使用してこの要求を行います）。

      たとえば、ドメイン名をクエリーする場合は次のようになります。

      ドメイン名: xn--caf-dma.example
      ドメインID: D1234567-TLD
      WHOISサーバー: whois.nic.example
      参照URL: http://www.nic.example
      更新日: 2009-05-29T20:13:00Z
      作成日: 2000-10-08T00:45:00Z
      レジストリの有効期限日: 2010-10-08T00:44:59Z
      スポンサーレジストラ: EXAMPLE REGISTRAR LLC
      スポンサーレジストラIANA ID: 5555555
      ドメインステータス: clientDeleteProhibited
      https://icann.org/epp#clientDeleteProhibited
      ドメインステータス: clientRenewProhibited
      https://icann.org/epp#clientRenewProhibited
      ドメインステータス: clientTransferProhibited
      https://icann.org/epp#clientTransferProhibited
      ドメインステータス: serverUpdateProhibited
      https://icann.org/epp#serverUpdateProhibited
      レジストラントID: 5372808-ERL
      レジストラント名: EXAMPLE REGISTRANT
      レジストラントの組織名: EXAMPLE ORGANIZATION
      レジストラントの番地: 123 EXAMPLE STREET
      レジストラントの都市名: ANYTOWN
      …
      ネームサーバー: NS01.EXAMPLEREGISTRAR.TLD
      ネームサーバー: NS02.EXAMPLEREGISTRAR.TLD
      DNSSEC: signedDelegation
      正準名: café.example

    12. JavaScriptやその他のクライアントサイドのスクリプトコードを、WHOIS（ポート43）の出力に追加してはなりません。誤ってマークアップ言語として解釈される可能性のあるオブジェクトのデータは、WebベースのWhoisで適切にエスケープする必要があります。

    13. WebベースのWhoisの出力は、2013 RAAのRDDS仕様のセクション1.4.2とレジストリ契約の仕様4のセクション1.5,1.6、および1.7で定義されている同じ規則に従う必要があります。

    14. 各フィールド（キーと値のペア）はASCII CR、そして次にASCII LF <U+000D、U+000A>で終了させる必要があります（RFC 3912のセクション2、WHOISプロトコル仕様を参照）。これは、法的免責事項やWhois出力に表示されるその他の行に使用される段落に適用されます。

    15. キーと値は、「: 」 <U+003A、U+0020> のように、コロンとその後に続く1つのスペース文字で区切る必要があります。

      たとえば、ネームサーバーは、次のように表示されます。

      ネームサーバー: ns1.xn--caf-dma.example

    16. 先頭にあるスペースは、Whois出力に表示させることはできません。表示される場合、先頭にあるスペース文字は9個以下にする必要があります。末尾にあるスペースは表示させることはできません。

    17. 応答の最後のデータフィールドとフッター「>>> Whoisデータベースの最終更新日: <日付と時刻> <<<」の間に空白行を入れることはできません。応答の最後のデータフィールドと「最終更新日」フッターの間には、3行以上の空行を表示することはできません。

    18. ドメイン名オブジェクトのWHOIS（ポート43）クエリーは、クエリーごとに1つのレコードのみを返す必要があります（つまり、部分一致または他の検索機能はなく、完全一致検索のみの結果を返す必要があります）。

    19. 2013 RAA（レジストラ）のRDDS仕様のセクション1.4.2、またはレジストリ契約の仕様4のセクション1.5,1.6、および1.7（レジストリ）に記載されているすべてのフィールド（例、行）は、大文字小文字が区別されます。キー（つまり、コロンの左側の文字列）では大文字小文字が区別され、2013 RAA（レジストラの場合）のRDDS仕様のセクション1.4.2、およびレジストリ契約（レジストリの場合）のセクション1.5、1.6、および1.7で定義されているように表示する必要があります。

    20. ASCII CRおよびASCII LF <U+000D、U+000A>は、フィールドの最後にのみ表示する必要があります。

    21. レジストリ運用者とレジストラは、完全修飾ドメイン名を使用する必要があります。レジストリ運用者は、ドメイン名を表示するときに末尾にドットを含めることはできません。

    22. レジストリ運用者とレジストラは、ドメイン名の請求連絡先情報を表示することができます。表示されている場合、連絡先フィールドは、この文書の説明11で定義された追加フィールドとして、または技術連絡先データフィールドの直後に表示する必要があります。

    23. AWIP（https://www.icann.org/resources/pages/policy-awip-2014-07-02-en）に従って、Whoisの出力には、「Whoisステータスコードの詳細については、https://icann.org/eppを参照してください。」のようにフッターを追加する必要があります。説明17に記載されている最終更新日のフッターの後にAWIPフッターを表示する必要があります。AWIPフッターの前には少なくとも1行以上3行以内の行を入れる必要があります。法的免責事項は、AWIPフッターの後に置き、少なくとも1行以上で3行以内の行を入れる必要があります。例：

      ドメイン名: foobar.example
      レジストリドメインID: D1234567-example
      …
      DNSSEC: signedDelegation
      ICANNのWHOISデータ問題レポーティングシステムのURL: http://wdprs.internic.net/
      >>> WHOISデータベースの最終更新: 2009-05-29T20:15:00Z <<<

      Whoisステータスコードの詳細については、https://icann.org/epp を参照してください。

      利用規約: このWhoisサービスのユーザー …

    24. 他に明示的に指定されていない限り、Whois出力のフィールドを複数回表示されることはできません。

    25. ドメイン名オブジェクトのクエリーへの応答では、次のフィールドは複数の値を持つことがあるため、複数回表示される場合があります。

      • ドメインステータス

      • ネームサーバー

      • レジストラント/管理担当者/技術担当者/請求担当者の住所（つまり、EPP RFC5733の使用方法に従う）

    26. SRSに存在しないオブジェクトのクエリーを受信した場合、契約当事者はキー「クエリーされたオブジェクトは存在しません」を返す必要があり、必要に応じて、そのキーの後にオブジェクトが存在しないことに関する詳細の説明であるレジストリが定義するテキストメッセージ（値）を追加できます。他のフィールドはしてはいけません。「最終更新日」のフッター、空白行、および法的免責事項は、他のWhoisのクエリーと同様に、その後に表示する必要があります。

  2. 以下の説明はレジストリにのみ適用されます。

    1. ネームサーバークエリーに対する応答では、以下のフィールドはオプションと見なされ、説明1のように扱う必要があります。

      • レジストラ
      • WHOISサーバー
      • 参照URL

    2. ネームサーバオブジェクトのWHOIS（ポート43）クエリーでは、部分一致または他の検索機能を提供することはできません。

    3. ネームサーバーオブジェクトのクエリーで、ネームサーバー名またはIPアドレスをクエリー文字列として使用すると、複数のオブジェクトと一致する場合があります。そのような場合、レジストリは、「クエリーの結果、複数のネームサーバーに一致しました:」という行を返す必要があり、その後に1行につき1つ、一致するネームサーバー名を括弧で囲み、一致するROIDを表示する必要があります。たとえば、IP「203.0.113.7」のネームサーバーをクエリーして、3つのオブジェクトと一致する場合は、次のように返されます。

      クエリーの結果、複数のネームサーバーに一致しました:
      roid1abc-examplerep (ns1.foo.example)
      roid5jkl-examplerep (ns2.example.com)
      roid9mno-examplerep (ns1.example.net)
      >>> WHOISデータベースの最終更新日: 2009-05-29T20:15:00Z <<<

    4. 説明29の要件を満たすレジストリは、ネームサーバーオブジェクトのROIDを使用して、ネームサーバオブジェクトに対するクエリーをサポートする必要があります（たとえば、クエリ-の形式は、whois roid <roid>となります。<roid>はネームサーバーのROIDです）。

    5. レジストリは、レジストラオブジェクトクエリーの部分一致機能を提供できます。複数のオブジェクトと一致するレジストラオブジェクトのクエリーを受け取った場合、レジストリはいくつかのレコードを返す必要があります。すべてのレジストラオブジェクトは空白行で区切られなければならず、新しいレコードの開始を示す「レジストラ名：」のキーがその後に続く必要があります。たとえば、レジストラ「Example」をクエリーして2つのオブジェクトが一致した場合、以下のように返されます（検索機能を提供する場合）。

      レジストラ名: Example Registrar, Inc.
      …
      参照URL: http://www.example-registrar.example
      管理担当の連絡先: Joe Registrar
      電話番号: +1.5553101213
      ファックス番号: +1.5553101213
      電子メール: [email protected]
      管理担当の連絡先: Jane Registrar
      電話番号: +1.5553101214
      ファックス番号: +1.5553101213
      電子メール: [email protected]
      技術担当の連絡先: John Geek
      …

      レジストラ名: Example Registrar Two, Inc.
      …
      参照URL: http://www.example-registrar-two.example
      管理担当の連絡先: Joe Registrar Two
      電話番号: +1.5553101213
      ファックス番号: +1.5553101213
      電子メール: [email protected]
      管理担当の連絡先: Jane Registrar
      電話番号: +1.5553101214
      ファックス番号: +1.5553101213
      電子メール: [email protected]
      技術担当の連絡先: John Geek
      …
      >>> WHOISデータベースの最終更新: 2009-05-29T20:15:00Z <<<

    6. 複数のオブジェクトと一致するネームサーバーのクエリーを受け取った場合、本文書の説明29の条件を満たしていないと、レジストリはいくつかのレコードを返す必要があります。すべてのネームサーバーオブジェクトは空白行で区切られなければならず、新しいレコードの開始を示す「サーバー名：」のキーがその後に続く必要があります。たとえば、ネームサーバー「203.0.113.7」のネームサーバーをクエリーして、2つのオブジェクトと一致する場合は、次のように返されます。

      ネームサーバー: ns1.foo.example
      IPアドレス: 203.0.113.7
      レジストラ: Example Registrar, Inc.
      WHOISサーバー: whois.example-registrar.example
      参照URL: http://www.example-registrar.example

      ネームサーバー: ns3.bar.example
      IPアドレス: 203.0.113.7
      レジストラ: Example Registrar 2, Inc.
      WHOISサーバー: whois.example-registrar2.example
      参照URL: http://www.example-registrar2.example
      >>> WHOISデータベースの最終更新: 2009-05-29T20:15:00Z <<<

    7. レジストリ運用者は、レジストラデータの連絡先に電話番号または内線ファックスの要素を表示できます。表示されている場合、各フィールドは、この文書の説明11で定義される追加データフィールドとして、または連絡先の電話番号またはファックスフィールドの直後に表示する必要があります。

    8. レジストリは、レジストラのIANA IDを使用するレジストラオブジェクトに対するクエリーをサポートする必要があります。例、クエリーの形式：whois registrar-id <IANA ID>。

    9. ネームサーバーオブジェクトのクエリーへの応答では、「IPアドレス」フィールドは複数の値を持つことがあるため、複数回表示することができます。

    10. DNSにグルーデータを必要とするアクティブなドメイン名が少なくとも1つあるネームサーバーのクエリーの場合（RFC 1034を参照）で、レジストリにそのデータがある場合、レジストリはそのSRSの応答データ（たとえば、サーバー名、IPアドレス）に、少なくとも、DNS内のグルーデータを必要とするドメイン名の関連IPアドレスを含める必要があります。他の場合には、レジストリは、SRSのデータで応答を提供することができます。

      たとえば、ドメイン名「foo.example」がDNS内でアクティブで、ネームサーバー「ns.foo.example」がある場合、ネームサーバ「ns.foo.example」のクエリのWhois出力で、ネームサーバーのSRSのIPアドレスと関連データが表示されます。

    11. レジストラオブジェクトのクエリーへの応答では、次のフィールドは複数の値を持つことがあるため、複数回表示される場合があります。

      • 管理担当の連絡先
      • 技術担当の連絡先
      • 電子メール
      • ファックス番号
      • 電話番号
      • 内線電話
      • 内線ファックス

      レジストラオブジェクトクエリーが複数の管理担当または技術担当の連絡先を返す場合、関連するフィールド（電子メール、ファックス番号、および電話番号）は連絡先名（管理担当の連絡先または技術担当の連絡先）のフィールドの後に続く必要があります。たとえば、2つの管理担当の連絡先があるレジストラをクエリーすると、以下のように返されます。

      レジストラ名: Example Registrar, Inc.
      …
      参照URL: http://www.example-registrar.example
      管理担当の連絡先: Joe Registrar
      電話番号: +1.5553101213
      ファックス番号: +1.5553101213
      電子メール: [email protected]
      管理担当の連絡先: Jane Registrar
      電話番号: +1.5553101214
      ファックス番号: +1.5553101213
      電子メール: [email protected]
      技術担当の連絡先: John Geek
      …
      >>> WHOISデータベースの最終更新: 2009-05-29T20:15:00Z <<<

    12. 「必要な条件を満たしていないクエリー」（つまり、「nameserver」や「registrar」パラメーターが含まれないクエリー）を受け取った場合、レジストリはドメイン名オブジェクトの情報を返す必要があります。

    13. レジストラオブジェクトクエリーに対する応答では、以下のフィールドはオプションと見なされ、説明1のように取り扱う必要があります。

      • 都道府県
      • 郵便番号
      • ファックス番号

    14. レジストラオブジェクトクエリーへの応答では、少なくとも1つの管理担当の連絡先と技術担当の連絡先が表示される必要があります。

    15. フィールドの値セクション（つまり、コロンの右側）は、 EPP RFC：5730-5734および3915で指定される形式に準拠する必要があります。次のフィールドは、EPP RFC：5730-5734、または3915で指定されていません。これらのフィールドは、次の形式の仕様に従う必要があります。

      1. 「WHOISサーバー」値は、ホスト名として定義され（RFC952およびRFC1123を参照）され、レジストラがクエリーされているオブジェクトについて（ポート43）WHOISサービスを提供している場合、スポンサー/参照されているレジストラの（ポート43）WHOISサーバーのサーバー名を表示する必要があり、そうでなければ、説明1のようにオプションとして扱う必要があります。

      2. 「参照URL」値は、URLとして定義されます（RFC3986を参照）。この値が、スポンサーレジストラのWebサイトを表示する必要があります。このURLは、クエリーされているオブジェクトのWeb-WhoisのURL、レジストラのWeb-Whoisサービス、またはスポンサーレジストラのメインのWebページのいずれかである必要があります。

      3. 「スポンサーレジストラのIANA ID」値は、正の10進整数として定義されます。

      4. 「スポンサーレジストラセラー」の値はトークンとして定義（拡張マークアップ言語1.1を参照）

      5. レジストラオブジェクトの連絡先オブジェクトエレメントは、EPP連絡先オブジェクトエレメントとして定義されます。

    16. ドメイン名、レジストラ、またはネームサーバーオブジェクトクエリーに対する応答では、以下のフィールドはオプションと見なされ、説明1のように取り扱う必要があります。

      • WHOISサーバー（スポンサー/参照レジストラが、クエリーされているオブジェクトについて（ポート43）WHOISserviceを提供していない場合）

    17. セクションIとセクションIIの要件が次のようにレジストリによって正しく実装されていることを検証するために、これらの説明を組み入れるように移譲前テスト（PDT）仕様は更新されます。

      1. このアドバイザリの発効日の前に、PDTの仕様は更新され、レジストリ契約の仕様4の要件がこれらの説明と一致することを検証するために更新されます。

      2. このアドバイザリを考慮して更新されるPDT仕様の公開日と、このアドバイザリの発効日との間の期間は、RDDS出力仕様の非遵守は（このアドバイザリと一致しない場合）、レジストリへの警告として扱われます。

      3. このアドバイザリの発効日からは、RDDS出力仕様の非遵守は（このアドバイザリと一致しない場合）、非遵守状態として扱われ、レジストリは不一致の状況が解決されるまでPDTをパスすることが許可されなくなります。

  3. 以下の説明はレジストラにのみ適用されます。

    1. レジストラがスポンサーレジストラになっているドメイン名についてのみ、レジストラはWhois情報を表示することが求められます。

    2. 「レジストリドメインID:」のフィールドは、RFC5730で規定されるドメイン名オブジェクトのリポジトリオブジェクト識別子（ROID）を示します（レジストリ契約の仕様4ではドメインIDと呼ばれています）。たとえば、レジストラは、EPPからレジストリのROIDを取得し、移転によってドメイン名を作成または取得した後に、情報をローカルでキャッシュすることができます。

    3. 「管理担当者/技術担当者/請求担当者/レジストラントID:」のフィールドは、RFC5733で規定される連絡先オブジェクトのリポジトリオブジェクト識別子（ROID）を示します（レジストリ契約の仕様4では管理担当者/技術担当者//レジストラントIDと呼ばれています）。たとえば、レジストラは、EPPからレジストリのROIDを取得し、情報をローカルでキャッシュすることができます。RAA 2013では、レジストリからこの情報を入手できる場合には、表示する必要があると定義しています。この情報がレジストリから入手できない場合（例、「Thin」レジストリ）、「レジストリから入手できません」という文字列を代わりに表示する必要があります。

    4. 「更新日:」フィールドは、最後に適切に更新され、レジストラが把握している日付と時刻を反映する必要があります。レジストラは、この「更新日:」をレジストリに確認して定期的に更新する必要はありません。

    5. 登録データディレクトリサービス（WHOIS）の仕様のセクション2.2に記載されているサービスレベル要件「RDDS更新時間」は、レジストリによって開始された変更のみを示します。

    6. Whois出力のEPPステータスは、レジストリの認識されている最新のEPPステータスを反映する必要があります。レジストラは、このEPPステータスをレジストリに確認して定期的に更新する必要はありません。

    7. フィールドの値セクション（つまり、コロンの右側）は、EPP RFC：5730-5734および3915で指定される形式に準拠する必要があります。次のフィールドは、EPP RFC：5730-5734、または3915で指定されていません。これらのフィールドは、次の形式の仕様に従う必要があります。

      1. 「レジストラの悪用対応担当者の電子メール」（電子メールフィールドに関するEPP RFCで定義）
      2. 「レジストラの悪用対応担当者の電話」（電話フィールドに関するEPP RFCで定義）
      3. 「リセラー」はトークンとして定義（拡張マークアップ言語1.1を参照）
      4. 「レジストラWHOISサーバー」の値は、ホスト名として定義され（RFC952およびRFC1123を参照）、スポンサーレジストラの（ポート43）WHOISサーバーのサーバー名になります。
      5. 「レジストラURL」値は、URLとして定義され（RFC3986を参照）、スポンサーレジストラのWebサイト、さらに具体的には、クエリーされたオブジェクトのWeb-WhoisのURL、または少なくともレジストラのWeb-WhoisサービスのURLを表示する必要があります。
      6. 「レジストラのIANA ID」値は、正の10進整数として定義されます。
      7. 「レジストラセラー」の値はトークンとして定義されます（拡張マークアップ言語1.1を参照）。

    8. 「Reseller（リセラー）」フィールドの値セクションは表示される必要がありますが、空白のままだったり、フィールド全体を全く表示させないこともできます。表示される場合、このフィールドの値は、組織の名前を指定する必要があります。リセラーの場合、法人、人名、またはそれ以外になります。

    9. 以下のフィールドは、次の「レジストラIANA ID」フィールドの後ではなく、最後のフィールド（「ICANN WHOISデータ問題報告システムのURL」）の直前に表示されることがあります。

      • レジストラの悪用対応担当者の電子メール

      • レジストラの悪用対応担当者の電話