Internet Engineering Task Force (IETF) M. Loffredo
Request for Comments: 9536 M. Martinelli
Category: Standards Track IIT-CNR/Registro.it
ISSN: 2070-1721 April 2024
The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case.
登録データアクセスプロトコル（RDAP）には、特定の検索パターンに一致するエンティティのセットに関連するドメインのリストを見つけるためのクエリ機能は含まれていません。RDAPエンティティを定義されたオブジェクトクラスとRDAPオブジェクトクラス間のその他の関係に関連付けることができることを考慮すると、古典的なドメインエンティティシナリオ以外のユースケースに逆検索を適用できます。このドキュメントでは、サーバーが検索用のオブジェクトクラスと関連するオブジェクトクラスの間でRDAPで定義された関係に基づいて、サーバーが逆検索機能を提供できるようにするRDAP拡張機能について説明します。ドメインエンティティ関係に基づく逆検索は、特定のケースとして扱われます。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc9536.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9536で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Background
1.2. Conventions Used in This Document
2. Reverse Search Path Segment Specification
3. Reverse Search Definition
4. Reverse Search Properties Discovery
5. Reverse Search Properties Mapping
6. Reverse Search Response Specification
7. Reverse Search Query Processing
8. Reverse Searches Based on Entity Details
9. RDAP Conformance
10. Implementation Considerations
11. IANA Considerations
11.1. RDAP Extensions Registry
11.2. RDAP Reverse Search Registries
11.2.1. Creation of the RDAP Reverse Search Registries
11.2.2. Submit Requests to IANA
11.2.3. RDAP Reverse Search Registry
11.2.3.1. Template
11.2.3.2. Initial Content
11.2.4. RDAP Reverse Search Mapping Registry
11.2.4.1. Template
11.2.4.2. Initial Content
12. Privacy Considerations
13. Security Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. Paradigms to Enforce Access Control on Reverse Search
in RDAP
Acknowledgements
Authors' Addresses
The protocol described in this specification aims to extend the RDAP query capabilities and response to enable reverse search based on the relationships defined in RDAP between an object class for search and a related object class. The reverse search based on the domain-entity relationship is treated as a particular case of such a generic model.
この仕様で説明されているプロトコルは、RDAPクエリ機能と応答を拡張して、検索用のオブジェクトクラスと関連するオブジェクトクラスの間のRDAPで定義された関係に基づいて逆検索を有効にすることを目的としています。ドメインエンティティ関係に基づく逆検索は、そのような一般的なモデルの特定のケースとして扱われます。
RDAP providers willing to implement this specification should carefully consider its implications on the efficiency (see Section 10), the security (see Section 13), and the compliance with privacy regulations (see Section 12) of their RDAP service.
この仕様を実装する意思のあるRDAPプロバイダーは、RDAPサービスの効率性（セクション10を参照）、セキュリティ（セクション13を参照）、およびプライバシー規則（セクション12を参照）に順応することに慎重に検討する必要があります。
Reverse WHOIS is a service provided by many web applications that allows users to find domain names owned by an individual or a company starting from the owner's details, such as name and email. Even if it has been considered useful for some legal purposes (e.g., uncovering trademark infringements and detecting cybercrimes), its availability as a standardized WHOIS [RFC3912] capability has been objected to for two main reasons, which now don't seem to conflict with an RDAP implementation.
Reverse Whoisは、ユーザーが名前や電子メールなどの所有者の詳細から始まる個人または会社が所有するドメイン名を見つけることができる多くのWebアプリケーションが提供するサービスです。いくつかの法的目的で有用であると考えられていたとしても（たとえば、商標侵害を明らかにし、サイバー犯罪を検出する）、標準化されたWHOIS [RFC3912]能力としての入手可能性は、2つの主な理由で反対されています。RDAP実装。
The first objection concerns the potential risks of privacy violation. However, the domain name community is considering a new generation of Registration Directory Services [ICANN-RDS] [ICANN-RA] that provide access to sensitive data under some permissible purposes and in accordance with appropriate policies for requestor accreditation, authentication, and authorization. RDAP's reliance on HTTP means that it can make use of common HTTP-based approaches to authentication and authorization, making it more useful than WHOIS in the context of such directory services. Since RDAP consequently permits a reverse search implementation complying with privacy protection principles, this first objection is not well-founded.
最初の異議は、プライバシー違反の潜在的なリスクに関するものです。ただし、ドメイン名コミュニティは、許容される目的の下で、要求者の認定、認証、および承認の適切なポリシーに従って、機密データへのアクセスを提供する新世代の登録ディレクトリサービス[ICANN-RDS] [ICANN-RA]を検討しています。RDAPのHTTPへの依存は、認証と承認に対する一般的なHTTPベースのアプローチを利用できることを意味し、そのようなディレクトリサービスのコンテキストではWHOIよりも有用です。その結果、RDAPはプライバシー保護の原則に準拠した逆検索実装を許可しているため、この最初の異議は十分に発見されていません。
The second objection to the implementation of a reverse search capability has been connected with its impact on server processing. However, the core RDAP specifications already define search queries, with similar processing requirements, so the basis of this objection is not clear.
リバース検索機能の実装に対する2番目の異議は、サーバー処理への影響と関連しています。ただし、Core RDAP仕様は、同様の処理要件を備えた検索クエリをすでに定義しているため、この異議の基礎は明確ではありません。
Reverse searches, such as finding the list of domain names associated with contacts or nameservers, may be useful to registrars as well. Usually, registries adopt out-of-band solutions to provide results to registrars asking for reverse searches on their domains. Possible reasons for such requests are:
連絡先や名前サーバーに関連付けられたドメイン名のリストを見つけるなどの逆検索は、レジストラにとっても役立つ場合があります。通常、レジストリは帯域外ソリューションを採用して、ドメインの逆検索を要求するレジストラに結果を提供します。そのような要求の考えられる理由は次のとおりです。
* the loss of synchronization between the registrar database and the registry database and
* レジストラデータベースとレジストリデータベースとの間の同期の喪失と
* the need for such data to perform bulk Extensible Provisioning Protocol (EPP) [RFC5730] updates (e.g., changing the contacts of a set of domains, etc.).
* このようなデータがバルク拡張可能なプロビジョニングプロトコル（EPP）[RFC5730]の更新（ドメインのセットなどの連絡先の変更など）を実行する必要があります。
Currently, RDAP does not provide any means for a client to search for the collection of domains associated with an entity [RFC9082]. A query (lookup or search) on domains can return the array of entities related to a domain with different roles (registrant, registrar, administrative, technical, reseller, etc.), but the reverse operation is not allowed. Only reverse searches to find the collection of domains related to a nameserver (ldhName or ip) can be requested. Since an entity can be in relationship with any RDAP object [RFC9083], the availability of a reverse search as largely intended can be common to all the object classes allowed for search. Through a further step of generalization, the meaning of reverse search in the RDAP context can be extended to include any query for retrieving all the objects that relates to another query matching a given search pattern.
現在、RDAPは、クライアントがエンティティに関連するドメインの収集を検索する手段を提供していません[RFC9082]。ドメインのクエリ（ルックアップまたは検索）は、異なる役割（登録者、登録官、管理、技術、再販業者など）のドメインに関連するエンティティの配列を返すことができますが、逆操作は許可されていません。NameServer（ldhnameまたはIP）に関連するドメインのコレクションを見つけるための逆検索のみを要求できます。エンティティは任意のRDAPオブジェクト[RFC9083]と関係があるため、主に意図された逆検索の可用性は、検索に許可されているすべてのオブジェクトクラスに共通することができます。一般化のさらなるステップにより、RDAPコンテキストでの逆検索の意味を拡張して、特定の検索パターンに一致する別のクエリに関連するすべてのオブジェクトを取得するためのクエリを含めることができます。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
A generic reverse search path is described by the syntax:
一般的な逆検索パスは、構文によって説明されています。
{searchable-resource-type}/reverse_search/{related-resource-type}?<search-condition>
{searchable-resource-type}/reverse_search/{related-resource-type}？<search-condition>
The path segments are defined as follows:
パスセグメントは次のように定義されています。
"searchable-resource-type":
「検索可能なリソースタイプ」：
It MUST be one of the resource types for search defined in Section 3.2 of [RFC9082] (i.e., "domains", "nameservers", and "entities") or a resource type extension.
[RFC9082]（つまり、「ドメイン」、「名前サーバー」、および「エンティティ」）のセクション3.2で定義されている検索のリソースタイプの1つでなければなりません。
"related-resource-type":
「関連リソースタイプ」：
It MUST be one of the resource types for lookup defined in Section 3.1 of [RFC9082] (i.e., "domain", "nameserver", "entity", "ip", and "autnum") or a resource type extension.
[RFC9082]のセクション3.1で定義されているルックアップのリソースタイプの1つでなければなりません（つまり、「ドメイン」、「名前サーバー」、「エンティティ」、「IP」、「Autnum」）またはリソースタイプの拡張機能です。
"search-condition":
「検索条件」：
A sequence of "property=search pattern" predicates separated by the ampersand character ('&', US-ASCII value 0x0026).
Ampersand Character（ '＆'、us-ascii値0x0026）で区切られた「プロパティ=検索パターン」のシーケンス。
While related-resource-type is defined as having one of a number of different values, the only reverse searches defined in this document are for a related-resource-type of "entity". Reverse searches for the other resource types specified in [RFC9082] and resource type extensions may be defined by future documents.
関連するリソースタイプは、さまざまな値のいずれかを持っていると定義されていますが、このドキュメントで定義されている唯一の逆検索は、関連するリソースタイプの「エンティティ」です。[RFC9082]で指定された他のリソースタイプの逆検索とリソースタイプの拡張は、将来のドキュメントで定義される場合があります。
Based on the content of Section 2, defining a reverse search means to define the triple <searchable resource type, related resource type, property> and the mapping with the corresponding RDAP object member. The mapping is done through the use of a JSONPath expression [RFC9535]. Reverse searches are registered in the "RDAP Reverse Search" registry (see Section 11.2.3), whereas reverse search mappings are registered in the "RDAP Reverse Search Mapping" registry (see Section 11.2.4). The reason for having two registries is that it may be possible for a single type of reverse search to rely on different members, depending on the server's configuration (see Section 5).
セクション2の内容に基づいて、逆検索を定義することは、トリプル<検索可能なリソースタイプ、関連するリソースタイプ、プロパティ>、および対応するRDAPオブジェクトメンバーとのマッピングを定義することを意味します。マッピングは、JSONPATH式[RFC9535]を使用して行われます。逆検索は「RDAP逆検索」レジストリ（セクション11.2.3を参照）に登録されますが、逆検索マッピングは「RDAPリバース検索マッピング」レジストリに登録されます（セクション11.2.4を参照）。2つのレジストリを持っている理由は、サーバーの構成に応じて、単一のタイプの逆検索が異なるメンバーに依存する可能性があるためです（セクション5を参照）。
All of the reverse searches defined by this document (see Section 8) have property names that are the same as the name of the RDAP object member that is the subject of the search. For example, the reverse search with the property name "fn" relies on the value of the "fn" member inside the jCard of an entity object. However, it is not necessary that these two names be the same. In particular, remapping of searches as part of the deprecation of an existing member (see Section 5) will typically lead to a member with a different name being used for the search.
このドキュメントで定義されたすべての逆検索（セクション8を参照）には、検索の主題であるRDAPオブジェクトメンバーの名前と同じプロパティ名があります。たとえば、プロパティ名「FN」を使用した逆検索は、エンティティオブジェクトのJCard内の「FN」メンバーの値に依存しています。ただし、これらの2つの名前が同じであることは必要ありません。特に、既存のメンバー（セクション5を参照）の非推奨の一部としての検索の再マッピングは、通常、検索に使用される別の名前を持つメンバーにつながります。
Servers MUST NOT provide or implement reverse searches or reverse search mappings that are not registered with IANA.
サーバーは、IANAに登録されていないリバース検索または逆検索マッピングを提供または実装してはなりません。
Servers complying with this specification MUST extend the help response [RFC9083] with the "reverse_search_properties" member that contains an array of objects with the following mandatory child members:
この仕様に準拠するサーバーは、次の必須子メンバーを持つオブジェクトの配列を含む「reverse_search_properties」メンバーでヘルプ応答[RFC9083]を拡張する必要があります。
"searchableResourceType":
「検索可能なResourceType」：
the searchable resource type of the reverse search query, as defined in Section 2
セクション2で定義されているように、逆検索クエリの検索可能なリソースタイプ
"relatedResourceType":
「関連ResourceType」：
the related resource type of the reverse search query, as defined in Section 2
セクション2で定義されているリバース検索クエリの関連リソースタイプ
"property":
"財産"：
the reverse search property used in the predicate of the reverse search query, as defined in Section 2
セクション2で定義されているように、逆検索クエリの述語で使用される逆検索プロパティ
An example of the help response including the "reverse_search_properties" member is shown in Figure 2
「reverse_search_properties」メンバーを含むヘルプ応答の例を図2に示します
To permit clients to determine the member used by the server for a reverse search, servers MUST detail the mapping that is occurring by adding the "reverse_search_properties_mapping" member to the topmost object of a reverse search response. This data structure is included in the search response, rather than in the help response, because it may differ depending on the query that is sent to the server.
クライアントがサーバーが逆検索に使用するメンバーを決定できるようにするために、サーバーは「reverse_search_properties_mapping」メンバーをリバース検索応答の最上位オブジェクトに追加することにより発生するマッピングを詳細に詳細にする必要があります。このデータ構造は、サーバーに送信されるクエリによって異なる場合があるため、ヘルプ応答ではなく検索応答に含まれています。
Documents that deprecate or restructure RDAP responses such that a registered reverse search is no longer able to be used MUST either note that the relevant reverse search is no longer available (in the case of deprecation) or describe how to continue supporting the relevant search by adding another mapping for the reverse search property (in the case of restructuring).
RDAP応答を廃止または再構築するドキュメントは、登録された逆検索を使用できなくなるようにします。関連する逆検索が使用できなくなったこと（非推奨の場合）または追加の検索を追加することで関連する検索をサポートする方法を説明する必要があります。逆検索プロパティの別のマッピング（再構築の場合）。
The "reverse_search_properties_mapping" member contains an array of objects with the following mandatory child members:
「Reverse_search_properties_mapping」メンバーには、次の必須の子メンバーを持つオブジェクトの配列が含まれています。
"property":
"財産"：
the reverse search property used in the predicate of the current query, as defined in Section 2
セクション2で定義されているように、現在のクエリの述語で使用される逆検索プロパティ
"propertyPath":
「PropertyPath」：
the JSONPath expression of the object member (or members) corresponding to the reverse search property
逆検索プロパティに対応するオブジェクトメンバー（またはメンバー）のjsonpath式
The searchable and the related resource types are derived from the query, so there is no need to include them in addition to the property in this member.
検索可能なリソースタイプと関連リソースタイプはクエリから派生しているため、このメンバーのプロパティに加えてそれらを含める必要はありません。
This member MUST be included for all properties used in the search, regardless of whether that property has multiple registered mappings as at the time of the search, because new mappings may be registered at any time.
このメンバーは、新しいマッピングがいつでも登録される可能性があるため、検索時に複数の登録マッピングがあるかどうかに関係なく、検索で使用されるすべてのプロパティに含める必要があります。
When applied to an object, the JSONPath expression MUST produce a list of values, each of which is a JSON number or string.
オブジェクトに適用する場合、JSONPATH式は値のリストを作成する必要があります。それぞれがJSON番号または文字列です。
An example of a reverse search response including the "reverse_search_properties_mapping" member is shown in Figure 3.
「reverse_search_properties_mapping」メンバーを含む逆検索応答の例を図3に示します。
Reverse search responses use the formats defined in Section 8 of [RFC9083], which correspond to the searchable resource types defined in Section 2.
逆検索応答は、[RFC9083]のセクション8で定義されている形式を使用します。これは、セクション2で定義されている検索可能なリソースタイプに対応しています。
To process a reverse search, the server returns the objects from its data store that are of type searchable-resource-type and that match each of the predicates from the search conditions. To determine whether an object matches a predicate, the server:
逆検索を処理するために、サーバーは、検索可能なリソースタイプのタイプであり、検索条件の各述語に一致するデータストアからオブジェクトを返します。オブジェクトが述語と一致するかどうかを判断するには、サーバー：
* applies the mapping it uses for the reverse search property to the object in order to generate a list of values, each of which MUST be a JSON number or string and
* 逆検索プロパティに使用するマッピングをオブジェクトに適用して、それぞれがJSON番号または文字列である必要があります。
* checks whether the search pattern matches one or more of those values.
* 検索パターンがこれらの値の1つ以上と一致するかどうかを確認します。
A search pattern matches a value where it equals the string representation of the value or where it is a match for the value in accordance with the partial string matching behavior defined in Section 4.1 of [RFC9082].
検索パターンは、[RFC9082]のセクション4.1で定義されている部分的な文字列マッチング動作に従って、値の文字列表現または値と一致する値と一致します。
Objects are only included in the search results if they satisfy all included predicates. This includes predicates that are for the same property; in such a case, it is necessary for the related object to match against each of those predicates.
オブジェクトは、すべての述語を満たす場合にのみ検索結果に含まれます。これには、同じプロパティ用の述語が含まれます。そのような場合、関連するオブジェクトがこれらの述語のそれぞれと一致する必要があります。
Servers MUST return an HTTP 501 (Not Implemented) [RFC9110] response to inform clients of unsupported reverse searches.
サーバーは、サポートされていない逆検索をクライアントに通知するために、HTTP 501（実装されていない）[RFC9110]応答を返す必要があります。
Based on their policy, servers MAY restrict how predicates are used to make a valid search condition by returning a 400 (Bad Request) response when a problematic request is received.
ポリシーに基づいて、サーバーは、問題のある要求を受信したときに400（悪い要求）応答を返すことにより、有効な検索条件を作成するために述語を使用する方法を制限する場合があります。
A given reverse search or reverse search mapping MAY define additional or alternative search behavior past that set out in this section.
特定の逆検索または逆検索マッピングは、このセクションに記載されている追加または代替の検索動作を定義する場合があります。
Since an entity can be associated with any other object class in RDAP, the most common kind of reverse search is one based on an entity's details. Such reverse searches arise from the query model by setting the related resource type to "entity".
エンティティはRDAPの他のオブジェクトクラスに関連付けることができるため、最も一般的な種類の逆検索は、エンティティの詳細に基づいています。このような逆検索は、関連するリソースタイプを「エンティティ」に設定することにより、クエリモデルから生じます。
By selecting a specific searchable resource type, the resulting reverse search aims at retrieving all the objects (e.g., all the domains) that are related to any entity object matching the search conditions.
特定の検索可能なリソースタイプを選択することにより、結果の逆検索は、検索条件に一致するエンティティオブジェクトに関連するすべてのオブジェクト（例えば、すべてのドメイン）を取得することを目的としています。
This section defines the reverse search properties servers SHOULD support for the domain, nameserver, entity-searchable resource types, and entity-related resource type:
このセクションでは、ドメイン、名前サーバー、エンティティ検索可能なリソースタイプ、およびエンティティ関連のリソースタイプをサポートする逆検索プロパティサーバーを定義します。
Reverse search property:
逆検索プロパティ：
role
役割役役柄
RDAP member path:
RDAPメンバーパス：
$.entities[*].roles
$ .entities [*]。役割
Reference:
参照：
Section 10.2.4 of [RFC9083]
[RFC9083]のセクション10.2.4
Reverse search property:
逆検索プロパティ：
handle
ハンドル扱う取り扱う柄把手手掛ける使いこなす使う握り捌く引手あしらうつまみ商う切掛け把っ手弦しじる仕向る仕向ける引き手膚触り
RDAP member path:
RDAPメンバーパス：
$.entities[*].handle
$ .entities [*]。ハンドル
Reference:
参照：
Section 5.1 of [RFC9083]
[RFC9083]のセクション5.1
Reverse search property:
逆検索プロパティ：
fn
fn
RDAP member path:
RDAPメンバーパス：
$.entities[*].vcardArray[1][?(@[0]=='fn')][3]
$ .entities [*]。vcardarray[1] [？（@[0] == 'fn'）] [3]
Reference:
参照：
Section 6.2.1 of [RFC6350]
[RFC6350]のセクション6.2.1
Reverse search property:
逆検索プロパティ：
Eメール
RDAP member path:
RDAPメンバーパス：
$.entities[*].vcardArray[1][?(@[0]=='email')][3]
$ .entities [*]。vcardarray[1] [？（@[0] == 'email'）] [3]
Reference:
参照：
Section 6.4.2 of [RFC6350]
[RFC6350]のセクション6.4.2
The presence of a predicate on the reverse search property "role" means that the RDAP response property "roles" MUST contain at least the specified role.
逆検索プロパティ「役割」に述語が存在することは、RDAP応答プロパティ「役割」に少なくとも指定された役割が含まれている必要があることを意味します。
The last two properties are related to jCard elements [RFC7095], but the field references are to vCard [RFC6350], since jCard is the JSON format for vCard.
最後の2つのプロパティはJCARD要素[RFC7095]に関連していますが、JCARDはVCardのJSON形式であるため、フィールド参照はVCard [RFC6350]に関連しています。
Examples of reverse search paths based on the domain-entity relationship are presented in Figure 1.
ドメインエンティティの関係に基づいた逆検索パスの例を図1に示します。
/domains/reverse_search/entity?handle=CID-40*&role=technical
/domains/reverse_search/entity?fn=Bobby*&role=registrant
/domains/reverse_search/entity?handle=RegistrarX&role=registrar
Figure 1: Examples of Reverse Search Queries
図1：逆検索クエリの例
An example of the help response including the supported reverse search properties is shown in Figure 2.
サポートされている逆検索プロパティを含むヘルプ応答の例を図2に示します。
{
"rdapConformance": [
"rdap_level_0",
"reverse_search"
],
...
"reverse_search_properties": [
{
"searchableResourceType": "domains",
"relatedResourceType": "entity",
"property": "fn"
},
{
"searchableResourceType": "domains",
"relatedResourceType": "entity",
"property": "handle"
},
{
"searchableResourceType": "domains",
"relatedResourceType": "entity",
"property": "email"
},
{
"searchableResourceType": "domains",
"relatedResourceType": "entity",
"property": "role"
}
],
...
}
Figure 2: An Example of the Help Response including the "reverse_search_properties" Member
図2：「reverse_search_properties」メンバーを含むヘルプ応答の例
An example of a response including the mapping that is occurring for the first reverse search in Figure 1 is shown below.
図1の最初の逆検索で発生するマッピングを含む応答の例を以下に示します。
{
"rdapConformance": [
"rdap_level_0",
"reverse_search"
],
...
"reverse_search_properties_mapping": [
{
"property": "handle",
"propertyPath": "$.entities[*].handle"
},
{
"property": "role",
"propertyPath": "$.entities[*].roles"
}
],
...
}
Figure 3: An Example of an RDAP Response including the "reverse_search_properties_mapping" Member
図3：「reverse_search_properties_mapping」メンバーを含むRDAP応答の例
Servers complying with this specification MUST include the value "reverse_search" in the rdapConformance property of the help response [RFC9083] and any other response including the "reverse_search_properties_mapping" member. The information needed to register this value in the "RDAP Extensions" registry is described in Section 11.1.
この仕様に準拠するサーバーには、ヘルプ応答[RFC9083]のRDAPCONFORMANCEプロパティに値「Reverse_Search」と、「Reverse_Search_Properties_Mapping」メンバーを含むその他の応答を含める必要があります。この値を「RDAP拡張機能」レジストリに登録するために必要な情報は、セクション11.1で説明されています。
To limit the impact of processing the search predicates, servers are RECOMMENDED to make use of techniques to speed up the data retrieval in their underlying data store, such as indexes or similar. In addition, risks with respect to performance degradation or result set generation can be mitigated by adopting practices used for standard searches, e.g., restricting the search functionality, limiting the rate of search requests according to the user's authorization, truncating and paging the results [RFC8977], and returning partial responses [RFC8982].
検索述語の処理の影響を制限するために、インデックスなどの基礎となるデータストアのデータ検索をスピードアップするための手法を使用するためにサーバーが推奨されます。さらに、パフォーマンスの劣化または結果セット生成に関するリスクは、標準検索に使用されるプラクティスを採用することで軽減できます。]、および部分的な応答を返す[RFC8982]。
IANA has registered the following value in the "RDAP Extensions" registry:
IANAは、「RDAP拡張機能」レジストリに次の値を登録しています。
Extension Identifier:
拡張識別子：
reverse_search
Reverse_search
Registry Operator:
レジストリオペレーター：
Any
どれでも
Specification:
仕様：
RFC 9536
RFC 9536
Contact:
接触：
IETF <iesg@ietf.org>
ietf <iesg@ietf.org>
Intended Usage:
意図された使用法：
This extension identifier is used for both URI path segments and response extensions related to the reverse search in RDAP.
この拡張識別子は、RDAPの逆検索に関連するURIパスセグメントと応答拡張機能の両方に使用されます。
IANA has created the "RDAP Reverse Search" and "RDAP Reverse Search Mapping" registries within the "Registration Data Access Protocol (RDAP)" category in the protocol registries.
IANAは、プロトコルレジストリに「登録データアクセスプロトコル（RDAP）」カテゴリ内に「RDAPリバース検索」および「RDAPリバース検索マッピング」レジストリを作成しました。
These registries follow the Specification Required registration policy, as defined in Section 4.6 of [RFC8126].
これらのレジストリは、[RFC8126]のセクション4.6で定義されているように、仕様が必要な登録ポリシーに従います。
The designated expert should prevent collisions and confirm that suitable documentation, as described in Section 4.5 of [RFC8126], is available to ensure interoperability.
指定された専門家は、[RFC8126]のセクション4.5で説明されているように、衝突を防ぎ、相互運用性を確保するために利用可能であることを確認する必要があります。
Creators of either new RDAP reverse searches or new mappings for registered reverse searches SHOULD NOT replicate functionality already available by way of other documents referenced in these registries. Creators MAY register additional reverse search mappings for existing properties, but they SHOULD NOT map a registered reverse search property to a response field with a meaning other than that of the response fields referenced by the mappings already registered for that property. In other words, all the mappings for a reverse search property MUST point to response fields with the same meaning.
新しいRDAPリバース検索または登録された逆の検索の新しいマッピングの作成者は、これらのレジストリで参照されている他のドキュメントによって既に利用可能な機能を再現してはなりません。クリエイターは、既存のプロパティの追加の逆検索マッピングを登録することができますが、登録された逆検索プロパティを、そのプロパティに既に登録されているマッピングが参照する応答フィールドの意味以外の意味を持つ応答フィールドにマッピングしないでください。言い換えれば、逆検索プロパティのすべてのマッピングは、同じ意味のある対応フィールドを指す必要があります。
Registration requests can be sent to <iana@iana.org>.
登録リクエストは<iana@iana.org>に送信できます。
Property:
財産：
The name of the reverse search property.
逆検索プロパティの名前。
Description:
説明：
A brief human-readable text describing the reverse search property.
逆検索プロパティを説明する簡単な人間読み取り可能なテキスト。
Searchable Resource Type:
検索可能なリソースタイプ：
The searchable resource type of the reverse search query (Section 2) including the reverse search property. Multiple reverse search properties differing only by this field can be grouped together by listing all the searchable resource types separated by comma (see Section 11.2.3.2).
逆検索プロパティを含む、逆検索クエリ（セクション2）の検索可能なリソースタイプ。このフィールドによってのみ異なる複数の逆検索プロパティは、コンマで区切られたすべての検索可能なリソースタイプをリストすることにより、グループ化できます（セクション11.2.3.2を参照）。
Related Resource Type:
関連リソースタイプ：
The related resource type of the reverse search query (Section 2) including the reverse search property.
リバース検索プロパティを含む、リバース検索クエリ（セクション2）の関連リソースタイプ。
Registrant:
登録者：
The name of the person registering the reverse search property.
逆検索プロパティを登録する人の名前。
Contact Information:
連絡先：
An email address, postal address, or some other information to be used to contact the registrant.
登録者に連絡するために使用されるメールアドレス、郵便アドレス、またはその他の情報。
Reference:
参照：
Document (e.g., the RFC number) and section reference where the reverse search property is specified.
逆検索プロパティが指定されている場合、ドキュメント（RFC番号など）とセクション参照。
The combination of Searchable Resource Type, Related Resource Type, and Property MUST be unique across the registry entries.
検索可能なリソースタイプ、関連リソースタイプ、およびプロパティの組み合わせは、レジストリエントリ全体で一意でなければなりません。
IANA has registered the following entries in the "RDAP Reverse Search" registry. For all entries, the common values are shown in Table 1, whereas the specific values are shown in Table 2.
IANAは、「RDAP逆検索」レジストリに次のエントリを登録しています。すべてのエントリについて、共通の値を表1に示しますが、特定の値を表2に示します。
+==========================+================================+
| Registry Property | Value |
+==========================+================================+
| Searchable Resource Type | domains, nameservers, entities |
+--------------------------+--------------------------------+
| Related Resource Type | entity |
+--------------------------+--------------------------------+
| Registrant | IETF |
+--------------------------+--------------------------------+
| Contact Information | iesg@ietf.org |
+--------------------------+--------------------------------+
| Reference | RFC 9536 |
+--------------------------+--------------------------------+
Table 1: Common Values for All Entries in the RDAP Reverse Search Registry
表1：RDAPリバース検索レジストリのすべてのエントリの共通値
+==========+==============================================+
| Property | Description |
+==========+==============================================+
| fn | The server supports the domain/nameserver/ |
| | entity search based on the full name (a.k.a. |
| | formatted name) of an associated entity |
+----------+----------------------------------------------+
| handle | The server supports the domain/nameserver/ |
| | entity search based on the handle of an |
| | associated entity |
+----------+----------------------------------------------+
| email | The server supports the domain/nameserver/ |
| | entity search based on the email address of |
| | an associated entity |
+----------+----------------------------------------------+
| role | The server supports the domain/nameserver/ |
| | entity search based on the role of an |
| | associated entity |
+----------+----------------------------------------------+
Table 2: Specific Values for Entries in the RDAP Reverse Search Registry
表2：RDAPリバース検索レジストリのエントリの特定の値
Property:
財産：
The same as defined in the "RDAP Reverse Search" registry.
「RDAP逆検索」レジストリで定義されているのと同じ。
Property Path:
プロパティパス：
The JSONPath of the RDAP property this reverse search property maps to.
RDAPプロパティのJSONPATHこのリバース検索プロパティマップ。
Searchable Resource Type:
検索可能なリソースタイプ：
The same as defined in the "RDAP Reverse Search" registry.
「RDAP逆検索」レジストリで定義されているのと同じ。
Related Resource Type:
関連リソースタイプ：
The same as defined in the "RDAP Reverse Search" registry.
「RDAP逆検索」レジストリで定義されているのと同じ。
Registrant:
登録者：
The name of the person registering this reverse search property mapping.
この逆検索プロパティマッピングを登録する人の名前。
Contact Information:
連絡先：
The same as defined in the "RDAP Reverse Search" registry.
「RDAP逆検索」レジストリで定義されているのと同じ。
Reference:
参照：
Document (e.g., the RFC number) and section reference where this reverse search property mapping is specified.
この逆検索プロパティマッピングが指定されているドキュメント（RFC番号など）とセクション参照。
The combination of Searchable Resource Type, Related Resource Type, Property, and Property Path MUST be unique across the registry entries.
検索可能なリソースタイプ、関連するリソースタイプ、プロパティ、およびプロパティパスの組み合わせは、レジストリエントリ全体で一意でなければなりません。
IANA has registered the following entries in the "RDAP Reverse Search Mapping" registry. For all entries, the common values are the same as defined in the "RDAP Reverse Search" registry (see Table 1), whereas the specific values are shown below (see Table 3).
IANAは、「RDAPリバース検索マッピング」レジストリに次のエントリを登録しています。すべてのエントリについて、共通の値は「RDAP逆検索」レジストリ（表1を参照）で定義されているのと同じですが、特定の値は以下に示されています（表3を参照）。
+==========+==================================================+
| Property | Property Path |
+==========+==================================================+
| fn | $.entities[*].vcardArray[1][?(@[0]=='fn')][3] |
+----------+--------------------------------------------------+
| handle | $.entities[*].handle |
+----------+--------------------------------------------------+
| email | $.entities[*].vcardArray[1][?(@[0]=='email')][3] |
+----------+--------------------------------------------------+
| role | $.entities[*].roles |
+----------+--------------------------------------------------+
Table 3: Specific Values for Entries in the RDAP Reverse Search Mapping Registry
表3：RDAPのエントリの特定の値逆検索マッピングレジストリ
The search functionality defined in this document may affect the privacy of entities in the registry (and elsewhere) in various ways; see [RFC6973] for a general treatment of privacy in protocol specifications. Registry operators should be aware of the trade-offs that result from implementing this functionality.
このドキュメントで定義されている検索機能は、さまざまな方法でレジストリ（および他の場所）のエンティティのプライバシーに影響を与える可能性があります。プロトコル仕様におけるプライバシーの一般的な扱いについては、[RFC6973]を参照してください。レジストリオペレーターは、この機能を実装したことから生じるトレードオフを認識する必要があります。
Many jurisdictions have laws or regulations that restrict the use of "personal data", per the definition in [RFC6973]. Given that, registry operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.
[RFC6973]の定義に従って、多くの管轄区域には、「個人データ」の使用を制限する法律または規制があります。それを考えると、レジストリ演算子は、運用する規制環境がこのドキュメントで定義されている機能の実装を許可するかどうかを確認する必要があります。
In those cases where this functionality makes use of sensitive information, the information MUST only be accessible to authorized users under a lawful basis.
この機能が機密情報を利用している場合、合法的な基準の下で認可されたユーザーが情報にのみアクセスできる必要があります。
Since reverse search requests and responses could contain Personally Identifiable Information (PII), reverse search functionality MUST be available over HTTPS only.
逆検索リクエストと応答には、個人識別可能な情報（PII）が含まれる可能性があるため、HTTPSでのみ逆検索機能を使用する必要があります。
Providing reverse search in RDAP carries the following threats as described in [RFC6973]:
RDAPで逆検索を提供するには、[RFC6973]に記載されているように、次の脅威があります。
* Correlation
* 相関
* Disclosure
* 開示
* Misuse of data
* データの誤用
Therefore, RDAP providers need to mitigate the risk of those threats by implementing appropriate measures supported by security services (see Section 13).
したがって、RDAPプロバイダーは、セキュリティサービスによってサポートされている適切な対策を実装することにより、これらの脅威のリスクを軽減する必要があります（セクション13を参照）。
Security services that are required to provide controlled access to the operations specified in this document are described in [RFC7481]. A non-exhaustive list of access control paradigms an RDAP provider can implement is presented in Appendix A.
このドキュメントで指定された操作への制御アクセスを提供するために必要なセキュリティサービスは、[RFC7481]で説明されています。RDAPプロバイダーが実装できるアクセス制御パラダイムの網羅的ではないリストは、付録Aに示されています。
As an additional measure to enforce security by preventing reverse searches to be accessed from unauthorized users, the RDAP providers may consider physically separating the reverse search endpoints from the other ones by configuring a proxy routing the reverse searches to a dedicated backend server and leveraging further security services offered by other protocol layers, such as digital certificates and IP allow-listing.
不正なユーザーから逆検索にアクセスできるようにすることでセキュリティを実施するための追加の尺度として、RDAPプロバイダーは、逆検索を専用のバックエンドサーバーにルーティングし、さらなるセキュリティを活用するプロキシを構成することにより、逆検索エンドポイントを他の検索エンドポイントから物理的に分離することを検討する場合があります。デジタル証明書やIP Allow-Listingなど、他のプロトコル層が提供するサービス。
Finally, the specification of the relationship within the reverse search path allows the RDAP servers to implement different authorization policies on a per-relationship basis.
最後に、リバース検索パス内の関係の指定により、RDAPサーバーは、関係ごとに異なる認証ポリシーを実装できます。
[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>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[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>.
[RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann,
Ed., "JSONPath: Query Expressions for JSON", RFC 9535,
DOI 10.17487/RFC9535, February 2024,
<https://www.rfc-editor.org/info/rfc9535>.
[ICANN-RA] ICANN, "Base Registry Agreement", January 2024,
<https://www.icann.org/en/registry-agreements/base-
agreement>.
[ICANN-RDS]
ICANN, "Final Report from the Expert Working Group on gTLD
Directory Services: A Next-Generation Registration
Directory Service (RDS)", June 2014,
<https://www.icann.org/en/system/files/files/final-report-
06jun14-en.pdf>.
[OIDCC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", December 2023,
<http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC8977] Loffredo, M., Martinelli, M., and S. Hollenbeck,
"Registration Data Access Protocol (RDAP) Query Parameters
for Result Sorting and Paging", RFC 8977,
DOI 10.17487/RFC8977, January 2021,
<https://www.rfc-editor.org/info/rfc8977>.
[RFC8982] Loffredo, M. and M. Martinelli, "Registration Data Access
Protocol (RDAP) Partial Response", RFC 8982,
DOI 10.17487/RFC8982, February 2021,
<https://www.rfc-editor.org/info/rfc8982>.
Access control can be implemented according to different paradigms introducing increasingly stringent rules. The paradigms listed below leverage the capabilities that are either built in or provided as extensions by the OpenID Connect [OIDCC]:
アクセス制御は、ますます厳しいルールを導入するさまざまなパラダイムに従って実装できます。以下にリストされているパラダイムは、OpenID Connect [OIDCC]によって拡張機能として組み込まれている、または提供されている機能を活用しています。
Role-Based Access Control (RBAC):
ロールベースのアクセス制御（RBAC）：
Access rights are granted depending on roles. Generally, this is done by grouping users into fixed categories and assigning static grants to each category. A more dynamic approach can be implemented by using the OpenID Connect "scope" claim.
アクセス権は役割に応じて付与されます。一般に、これはユーザーを固定カテゴリにグループ化し、各カテゴリに静的助成金を割り当てることによって行われます。OpenID Connectの「スコープ」クレームを使用して、より動的なアプローチを実装できます。
Purpose-Based Access Control (PBAC):
目的ベースのアクセス制御（PBAC）：
Access rules are based on the notion of purpose, being the intended use of some data by a user. It can be implemented by tagging a request with the usage purpose and making the RDAP server check the compliance between the given purpose and the control rules applied to the data to be returned.
アクセスルールは目的の概念に基づいており、ユーザーによる一部のデータの使用を目的としています。使用目的でリクエストをタグ付けし、RDAPサーバーに、返されるデータに適用される制御ルールとのコンプライアンスをチェックすることで実装できます。
Attribute-Based Access Control (ABAC):
属性ベースのアクセス制御（ABAC）：
Rules to manage access rights are evaluated and applied according to specific attributes describing the context within which data are requested. It can be implemented within an out-of-band process by setting additional OpenID Connect claims that describe the request context and make the RDAP server check for compliance between the given context and the control rules that are applied to the data to be returned.
アクセス権を管理するためのルールは、データが要求されるコンテキストを説明する特定の属性に従って評価および適用されます。リクエストコンテキストを説明する追加のOpenID Connectクレームを設定し、指定されたコンテキストと、返されるデータに適用される制御ルールとの間のコンプライアンスをRDAPサーバーにチェックすることにより、バンド外のプロセス内で実装できます。
Time-Based Access Control (TBAC):
時間ベースのアクセス制御（TBAC）：
Data access is allowed for a limited time only. It can be implemented by assigning users temporary credentials linked to access grants with limited scopes.
データアクセスは限られた時間のみが許可されます。限られたスコープのアクセス助成金にリンクされた一時的な資格情報をユーザーに割り当てることで実装できます。
With regard to the privacy threats reported in Section 12, correlation and disclosure can be mitigated by minimizing both the request features and the response data based on user roles (i.e., RBAC). Misuse can be mitigated by checking for the purpose of the request (i.e., PBAC). It can be accomplished according to the following approaches:
セクション12で報告されているプライバシーの脅威に関して、ユーザーの役割（つまり、RBAC）に基づいてリクエスト機能と応答データの両方を最小化することにより、相関と開示を軽減できます。誤用は、リクエスト（つまり、PBAC）の目的をチェックすることで緩和できます。次のアプローチに従って達成できます。
Full Trust:
完全な信頼：
The registry trusts the fairness of an accredited user. The requestor is always legitimized to submit their requests under a lawful basis. Additionally, they can be required to specify the purpose as either a claim of their account or a query parameter. In the former case, the purpose is assumed to be the same for every request. In the latter case, the purpose must be one of those associated to the user.
レジストリは、認定されたユーザーの公平性を信頼しています。要求者は、合法的な根拠の下でリクエストを提出するために常に正当化されます。さらに、目的をアカウントのクレームまたはクエリパラメーターのいずれかとして指定する必要があります。前者の場合、目的はすべての要求に対して同じであると想定されています。後者の場合、目的はユーザーに関連付けられているものの1つでなければなりません。
Zero Trust:
ゼロトラスト：
The registry requires documents that assess whether the requestor is legitimized to submit a given request. It can be implemented by assigning the requestor a temporary OpenID account linked to the given request (i.e., TBAC) and describing the request through a set of claims (i.e., ABAC). The association between the temporary account and the claims about the request is made by an out-of-band application. In so doing, the RDAP server is able to check that the incoming request is consistent with the request claims linked to the temporary account.
レジストリには、特定の要求を送信するために要求者が合法化されているかどうかを評価するドキュメントが必要です。指定された要求（つまり、TBAC）にリンクされた一時的なOpenIDアカウントをリクエスターに割り当て、一連のクレーム（つまり、ABAC）を介してリクエストを説明することで実装できます。一時的なアカウントとリクエストに関する請求との関連は、バンド外の申請によって行われます。そうすることで、RDAPサーバーは、着信要求が一時的なアカウントにリンクされた要求請求と一致していることを確認できます。
The two approaches can be used together:
2つのアプローチを一緒に使用できます。
* The former is suitable for users carrying out a task in the public interest or exercising their official authority (e.g., an officer of a cybercrime agency). Similarly, registrars can submit reverse searches on their domains and contacts based on their contractual relationship with the domain holders. In this case, the query results can be restricted to those pertaining to a registrar by adding an implicit predicate to the search condition.
* 前者は、公益のためにタスクを実行したり、公式の権限を行使したりするユーザー（サイバー犯罪機関の役員など）に適しています。同様に、レジストラは、ドメインホルダーとの契約上の関係に基づいて、ドメインと連絡先の逆検索を送信できます。この場合、クエリの結果は、検索条件に暗黙の述語を追加することにより、レジストラに関連する結果に制限される可能性があります。
* The latter can be taken to allow domain name dispute resolution service providers to request information in defense of the legitimate interests of complainants.
* 後者は、ドメイン名紛争解決サービスプロバイダーが、申立人の正当な利益を守るための情報を要求できるようにすることができます。
The authors would like to acknowledge the following individuals for their contributions to this document: Francesco Donini, Scott Hollenbeck, Francisco Arias, Gustavo Lozano, Eduardo Alvarez, Ulrich Wisser, James Gould, and Pawel Kowalik.
著者は、この文書への貢献について次の個人に認めたいと考えています：フランチェスコ・ドニニ、スコット・ホレンベック、フランシスコ・アリアス、グスタボ・ロザノ、エドゥアルド・アルバレス、ウルリッヒ・ウィザー、ジェームズ・グールド、ペイル・コワリク。
Tom Harrison and Jasdip Singh provided relevant feedback and constant support to the implementation of this proposal. Their contributions have been greatly appreciated.
Tom HarrisonとJasdip Singhは、この提案の実施に関連するフィードバックと絶え間ないサポートを提供しました。彼らの貢献は大歓迎です。
Mario Loffredo
IIT-CNR/Registro.it
Via Moruzzi,1
56124 Pisa
Italy
Email: mario.loffredo@iit.cnr.it
URI: http://www.iit.cnr.it
Maurizio Martinelli
IIT-CNR/Registro.it
Via Moruzzi,1
56124 Pisa
Italy
Email: maurizio.martinelli@iit.cnr.it
URI: http://www.iit.cnr.it