< draft-loffredo-regext-rdap-reverse-search-03.txt | draft-loffredo-regext-rdap-reverse-search-04.txt > | |||
---|---|---|---|---|
Registration Protocols Extensions M. Loffredo | Registration Protocols Extensions M. Loffredo | |||
Internet-Draft M. Martinelli | Internet-Draft M. Martinelli | |||
Intended status: Standards Track IIT-CNR/Registro.it | Intended status: Standards Track IIT-CNR/Registro.it | |||
Expires: April 19, 2019 October 16, 2018 | Expires: August 4, 2019 January 31, 2019 | |||
Registration Data Access Protocol (RDAP) Reverse search capabilities | Registration Data Access Protocol (RDAP) Reverse search capabilities | |||
draft-loffredo-regext-rdap-reverse-search-03 | draft-loffredo-regext-rdap-reverse-search-04 | |||
Abstract | Abstract | |||
The Registration Data Access Protocol (RDAP) does not include query | The Registration Data Access Protocol (RDAP) does not include query | |||
capabilities to find the list of domains related to a set of entities | capabilities to find the list of domains related to a set of entities | |||
matching a given search pattern. Even if such capabilities, commonly | matching a given search pattern. Even if such capabilities, commonly | |||
referred to as reverse search, respond to some needs not yet readily | referred as reverse search, respond to some needs not yet readily | |||
fulfilled by the current Whois protocol, they have raised concern | fulfilled by the current Whois protocol, they have raised concerns | |||
from two perspectives: server processing impact and data privacy. | from two perspectives: server processing impact and data privacy. | |||
Anyway, the impact of the reverse queries on RDAP servers processing | Anyway, the impact of the reverse queries on RDAP servers processing | |||
is the same of the standard searches and it can be reduced by | is the same as the standard searches and it can be reduced by | |||
implementing policies to deal with big result sets, while data | implementing policies to deal with large result sets, while data | |||
privacy risks can be mitigated by RDAP access control | privacy risks can be prevented by RDAP access control | |||
functionalities. This document describes RDAP query extensions that | functionalities. This document describes RDAP query extensions that | |||
allows clients to request a reverse search based on the domains- | allow clients to request a reverse search based on the domains- | |||
entities relationship. | entities relationship. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on April 19, 2019. | This Internet-Draft will expire on August 4, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 | 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 | |||
2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 3 | 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 4 | |||
3. Implementation Considerations . . . . . . . . . . . . . . . . 5 | 3. Implementation Considerations . . . . . . . . . . . . . . . . 5 | |||
3.1. JSON in URLs . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. JSON in URLs . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 | 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 | |||
4.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 6 | 4.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 7 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 8 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 | |||
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 | 9.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
1. Introduction | 1. Introduction | |||
Reverse Whois is a service provided by many web applications that | Reverse Whois is a service provided by many web applications that | |||
allows users to find domain names owned by an individual person or | allow users to find domain names owned by an individual or a company | |||
company starting from the owner details (like name, email). Even if | starting from the owner details, such as name and email. Even if it | |||
the availability of this service might raise some objections due to | has been considered useful for some legal purposes (e.g. uncovering | |||
potential privacy risks, ICANN itself, in its report about Next-Gen | trademark infringements, detecting cybercrime cases), its | |||
Registration Directory Service (RDS) [ICANN-RDS], states that it is | availability as a standardised Whois capability has been objected for | |||
allowed when driven by some permissible purposes (e.g. legal actions, | two main reasons, which now don't seem to conflict with an RDAP | |||
criminal investigations) and if it provides adequate policies to | implementation. | |||
enforce the requestor accreditation, authentication, authorization, | ||||
and terms and conditions of data use. | ||||
It is well known that such policies are not implemented in Whois | The first objection has been caused by the potential risks of privacy | |||
[RFC3912], while they are in RDAP. In fact, RDAP relies on security | violation. However, TLDs community is considering a new generation | |||
features, available in the HTTP protocol, to support access control | of Registration Directory Services ([ICANN-RDS1],[ICANN-RDS2]), which | |||
based on local policy [RFC7481]. | provide access to sensitive data under some permissible purposes and | |||
according to adequate policies to enforce the requestor | ||||
accreditation, authentication, authorization, and terms and | ||||
conditions of data use. It is well known that such security policies | ||||
are not implemented in Whois ([RFC3912]), while they are in RDAP | ||||
([RFC7481]). Therefore, RDAP permits a reverse search implementation | ||||
complying with privacy protection principles. | ||||
Another objection to the implementation of Reverse Whois is connected | Another objection to the implementation of a reverse search | |||
with its impact on server processing. Since RDAP supports search | capability has been connected with its impact on server processing. | |||
queries, the impact of both standard and reverse searches can be | Since RDAP supports search queries, the impact of both standard and | |||
mitigated by servers adopting ad hoc strategies. Furthermore, | reverse searches is equivalent and can be mitigated by servers | |||
reverse search is almost always performed by specifying an entity | adopting ad hoc strategies. Furthermore, reverse search is almost | |||
role (e.g. registrant, technical contact) and this can contribute to | always performed by specifying an entity role (e.g. registrant, | |||
restrict the result set. | technical contact) and this can contribute to restricting the result | |||
set. | ||||
Reverse searches, such as finding the list of domain names associated | Reverse searches, such as finding the list of domain names associated | |||
to contacts, nameservers or DNSSEC keys, may be useful to registrars | with contacts, nameservers or DNSSEC keys, may be useful to | |||
as well. Usually, registries adopt out-of-band mechanisms to provide | registrars as well. Usually, registries adopt out-of-band mechanisms | |||
results to registrars asking for reverse searches on their domains. | to provide results to registrars asking for reverse searches on their | |||
Possible reasons of such requests are: | domains. Possible reasons of such requests are: | |||
o the loss of synchronization between the registrar database and the | o the loss of synchronization between the registrar database and the | |||
registry database; | registry database; | |||
o the need of such data to perform massive EPP updates (i.e. | o the need of such data to perform massive EPP ([RFC5730]) updates | |||
changing the contacts of a set of domains, etc.). | (e.g. changing the contacts of a set of domains, etc.). | |||
Currently, RDAP does not provide any way for a client to search for | Currently, RDAP does not provide any way for a client to search for | |||
the collection of domains associated to an entity [RFC7482]. A query | the collection of domains associated with an entity ([RFC7482]). A | |||
(lookup or search) on domains can return the array of entities | query (lookup or search) on domains can return the array of entities | |||
related to a domain with different roles (registrant, registrar, | related to a domain with different roles (registrant, registrar, | |||
administrative, technical, reseller, etc.), but the reverse operation | administrative, technical, reseller, etc.), but the reverse operation | |||
is not allowed. Only reverse searches to find the collection of | is not allowed. Only reverse searches to find the collection of | |||
domains related to a nameserver (ldhName or ip) can be requested. | domains related to a nameserver (ldhName or ip) can be requested. | |||
Since entities can be in relationship with all RDAP objects | Since entities can be in relation with all RDAP objects ([RFC7483]), | |||
[RFC7483], the availability of a reverse search can be common to all | the availability of a reverse search can be common to all RDAP query | |||
RDAP query paths. | paths. | |||
The protocol described in this specification aims to extend the RDAP | The protocol described in this specification aims to extend the RDAP | |||
query capabilities to enable reverse search based on the domains- | query capabilities to enable reverse search based on the domains- | |||
entities relationship (the classic Reverse Whois scenario). The | entities relationship (the classic Reverse Whois scenario). The | |||
extension is implemented by adding new path segments (i.e. search | extension is implemented by adding new path segments (i.e. search | |||
paths) and using a RESTful web service [REST]. The service is | paths) and using a RESTful web service ([REST]). The service is | |||
implemented using the Hypertext Transfer Protocol (HTTP) [RFC7230] | implemented using the Hypertext Transfer Protocol (HTTP) ([RFC7230]) | |||
and the conventions described in RFC 7480 [RFC7480]. | and the conventions described in RFC 7480 ([RFC7480]). | |||
1.1. Conventions Used in This Document | 1.1. Conventions Used in This Document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
2. RDAP Path Segment Specification | 2. RDAP Path Segment Specification | |||
The new search paths are OPTIONAL extensions of path segments defined | The new search paths are OPTIONAL extensions of path segments defined | |||
in RFC 7482 [RFC7482]. The search paths are: | in RFC 7482 ([RFC7482]). The search paths are: | |||
Syntax: domains?entityHandle=<reverse search pattern> | Syntax: domains?entityHandle=<reverse search pattern> | |||
Syntax: domains?entityFn=<reverse search pattern> | Syntax: domains?entityFn=<reverse search pattern> | |||
Syntax: domains?entityEmail=<reverse search pattern> | Syntax: domains?entityEmail=<reverse search pattern> | |||
Syntax: domains?entityAddr=<reverse search pattern> | Syntax: domains?entityAddr=<reverse search pattern> | |||
The reverse search pattern is a JSON [RFC8259] object including two | The reverse search pattern is a JSON ([RFC8259]) object including two | |||
members: "value" and "role". The "value" member represents the | members: "value" and "role". The "value" member represents the | |||
search pattern to be applied to the corresponding entity field and | search pattern to be applied to the corresponding entity field and | |||
can be a JSON type primitive or object. The "role" member is a | can be a JSON type primitive or object. The "role" member is a | |||
string whose possible values are those detailed in Section 10.2.4 of | string whose possible values are those detailed in Section 10.2.4 of | |||
RFC 7483 [RFC7483]. The former is REQUIRED while the latter is | RFC 7483 ([RFC7483]). The former is REQUIRED while the latter is | |||
OPTIONAL to allow RDAP servers to provide reverse search capabilities | OPTIONAL to allow RDAP servers to provide reverse search capabilities | |||
without specifying any role. | without specifying any role. | |||
The search patterns corresponding to the "value" in the first two | The search patterns corresponding to the "value" in the first two | |||
cases are the same as specified in paragraph Section 3.2.3 of RFC | cases (Figure 1) are the same as specified in paragraph Section 3.2.3 | |||
7482 [RFC7482] (Figure 1). | of RFC 7482 ([RFC7482]). | |||
domains?entityHandle={"value":"CID-40*","role":"registrant"} | domains?entityHandle={"value":"CID-40*","role":"registrant"} | |||
domains?entityFn={"value":"Bobby*","role":"registrant"} | domains?entityFn={"value":"Bobby*","role":"registrant"} | |||
Figure 1: Examples of RDAP queries to find all domains related to a | Figure 1: Examples of RDAP queries to find all domains related to a | |||
registrant whose handle matches "CID-40*" and whose formatted name | registrant whose handle matches "CID-40*" and whose formatted name | |||
matches "Bobby*" | matches "Bobby*" | |||
The last two reverse searches are considered by ICANN very useful to | The last two reverse searches are considered by gTLD stakeholders | |||
improve searchability capabilities of the Registry Directory Services | very useful to improve RDS searchability ([ICANN-RDS1], [ICANN-RA]). | |||
([ICANN-RDS], [ICANN-RA]). | ||||
Searches for domains by related entity email are specified using this | Searches for domains by related entity email are specified using this | |||
form: | form: | |||
domains?entityEmail={"value":"XXXX","role":"ZZZZ"} | domains?entityEmail={"value":"XXXX","role":"ZZZZ"} | |||
where XXXX is a search pattern representing an email address as | where XXXX is a search pattern representing an email address as | |||
defined in RFC 5322 [RFC5322]. | defined in RFC 5322 ([RFC5322]). | |||
Searches for domains by related entity postal address are specified | Searches for domains by related entity postal address are specified | |||
using this form: | using this form: | |||
domains?entityAddr={"value":YYYY,"role":"ZZZZ"} | domains?entityAddr={"value":YYYY,"role":"ZZZZ"} | |||
where YYYY is a JSON object containing the information described in | where YYYY is a JSON object containing the information described in | |||
Section 2.4 of RFC 5733 [RFC5733], respectively: "street", "city", | Section 2.4 of RFC 5733 ([RFC5733]), respectively: "street", "city", | |||
"sp", "pc" and "cc" (Figure 2). All the members of the postal | "sp", "pc" and "cc" (Figure 2). All the members of the postal | |||
address object are OPTIONAL but at least one is REQUIRED. The | address object are OPTIONAL but at least one is REQUIRED. The | |||
constraints on the members are implicitly joined by AND. | constraints on the members are implicitly joined by AND. | |||
domains?entityAddr={"value":{"cc":"CA","city":"Sydney"},"role":"registrant"} | domains?entityAddr={"value":{"cc":"CA","city":"Sydney"},"role":"registrant"} | |||
Figure 2: Example of a RDAP query to find all domains related to a | Figure 2: Example of a RDAP query to find all domains related to a | |||
registrant whose postal address contains the country code equals to | registrant whose postal address contains the country code equals to | |||
"CA" and the city equals to "Sydney" | "CA" and the city equals to "Sydney" | |||
3. Implementation Considerations | 3. Implementation Considerations | |||
The implementation of the proposed extension is technically feasible. | The implementation of the proposed extension is technically feasible. | |||
The search paths "handle" and "fn" are used as standard paths to | The search paths "handle" and "fn" are used as standard paths to | |||
search for entities. With regards to the last two reverse searches, | search for entities. With regards to the last two reverse searches, | |||
both email and postal address information are usually required by the | both email and postal address information are usually required by the | |||
registries but, while the former is usually mapped on a DBMS indexed | registries but, while the former is usually mapped onto a DBMS | |||
field, the latter is mapped on a combination of non-indexed fields. | indexed field, the latter is mapped onto a combination of non-indexed | |||
As a consequence while the former should not significantly decrease | fields. As a consequence while the former should not significantly | |||
the performance, the latter might have an impact on server | decrease the performance, the latter might have an impact on server | |||
processing. Anyway, this impact is evaluated to be the same as other | processing. Anyway, this impact is evaluated to be the same as other | |||
query capabilities already presented in RDAP (e.g. wildcard prefixed | query capabilities already presented in RDAP (e.g. wildcard prefixed | |||
search pattern) so the risks to generate huge result sets are the | search pattern) so the risks to generate huge result sets are the | |||
same existing for the other standard searches and can be mitigated by | same as those related to other standard searches and can be mitigated | |||
adopting the same policies (e.g. restricting search functionalities, | by adopting the same policies (e.g. restricting search | |||
limiting the rate of search requests according to the user profile, | functionalities, limiting the rate of search requests according to | |||
truncating and paging the results, returning partial responses). | the user profile, truncating and paging the results, returning | |||
partial responses). | ||||
3.1. JSON in URLs | 3.1. JSON in URLs | |||
Many web services, including RDAP, rely on the HTTP GET method to | Many web services, including RDAP, rely on the HTTP GET method to | |||
take advantage from some of its features: | take advantage from some of its features: | |||
o GET requests can be cached; | o GET requests can be cached; | |||
o GET requests remain in the browser history; | o GET requests remain in the browser history; | |||
o GET requests can be bookmarked. | o GET requests can be bookmarked. | |||
Sometimes it happens that such advantages should be combined with the | Sometimes, it happens that such advantages should be combined with | |||
requirement to pass objects and arrays in the query string. JSON is | the requirement to pass objects and arrays in the query string. JSON | |||
the best candidate as data interchange format but it contains some | is the best candidate as data interchange format, but it contains | |||
characters that are forbidden from appearing in a URL. Anyway, | some characters that are forbidden from appearing in a URL. Anyway, | |||
escaping the invalid characters is not an issue because, on client | escaping the invalid characters is not an issue because, on the | |||
side, modern browsers automatically encode URLs and, on server side, | client side, modern browsers automatically encode URLs and, on the | |||
a lot of URL encoding/decoding libraries for all web development | server side, several URL encoding/decoding libraries for all web | |||
programming languages are available. The downside of URL encoding is | development programming languages are available. The downside of URL | |||
that it can make a URL rather long which, depending on the initial | encoding is that it can make a pretty long URL, which, depending on | |||
length and the number of invalid characters, might exceed the | the initial length and the number of invalid characters, might exceed | |||
practical limit of web browsers (i.e. 2,000 characters). | the practical limit of web browsers (i.e. 2,000 characters). | |||
Other solutions to pass a JSON expression in a URL could be: | Other solutions to pass a JSON expression in a URL could be: | |||
o converting JSON to Base64 ([RFC4648]) but binary data are | o converting JSON to Base64 ([RFC4648]), but binary data are | |||
unreadable; | unreadable; | |||
o using a JSON variation that complies with URL specifications and | o using a JSON variation that complies with URL specifications and | |||
mantains readability like Rison ([RISON]), URLON ([URLON]) or | maintains readability like Rison ([RISON]), URLON ([URLON]) or | |||
JSURL ([JSURL]). | JSURL ([JSURL]). | |||
The extensions proposed in this document rely on URL encoding because | The extensions proposed in this document rely on URL encoding because | |||
it is widely supported and the risk to exceed the maximum URL length | it is widely supported and the risk to exceed the maximum URL length | |||
is considered to be very unlikely in RDAP. | is considered to be very unlikely in RDAP. | |||
4. Implementation Status | 4. Implementation Status | |||
NOTE: Please remove this section and the reference to RFC 7942 prior | NOTE: Please remove this section and the reference to RFC 7942 prior | |||
to publication as an RFC. | to publication as an RFC. | |||
This section records the status of known implementations of the | This section records the status of known implementations of the | |||
protocol defined by this specification at the time of posting of this | protocol defined by this specification at the time of posting of this | |||
Internet-Draft, and is based on a proposal described in RFC 7942 | Internet-Draft, and is based on a proposal described in RFC 7942 | |||
[RFC7942]. The description of implementations in this section is | ([RFC7942]). The description of implementations in this section is | |||
intended to assist the IETF in its decision processes in progressing | intended to assist the IETF in its decision processes in progressing | |||
drafts to RFCs. Please note that the listing of any individual | drafts to RFCs. Please note that the listing of any individual | |||
implementation here does not imply endorsement by the IETF. | implementation here does not imply endorsement by the IETF. | |||
Furthermore, no effort has been spent to verify the information | Furthermore, no effort has been spent to verify the information | |||
presented here that was supplied by IETF contributors. This is not | presented here that was supplied by IETF contributors. This is not | |||
intended as, and must not be construed to be, a catalog of available | intended as, and must not be construed to be, a catalog of available | |||
implementations or their features. Readers are advised to note that | implementations or their features. Readers are advised to note that | |||
other implementations may exist. | other implementations may exist. | |||
According to RFC 7942, "this will allow reviewers and working groups | According to RFC 7942, "this will allow reviewers and working groups | |||
skipping to change at page 7, line 5 ¶ | skipping to change at page 7, line 11 ¶ | |||
and feedback that have made the implemented protocols more mature. | and feedback that have made the implemented protocols more mature. | |||
It is up to the individual working groups to use this information as | It is up to the individual working groups to use this information as | |||
they see fit". | they see fit". | |||
4.1. IIT-CNR/Registro.it | 4.1. IIT-CNR/Registro.it | |||
Responsible Organization: Institute of Informatics and Telematics | Responsible Organization: Institute of Informatics and Telematics | |||
of National Research Council (IIT-CNR)/Registro.it | of National Research Council (IIT-CNR)/Registro.it | |||
Location: https://rdap.pubtest.nic.it/ | Location: https://rdap.pubtest.nic.it/ | |||
Description: This implementation includes support for RDAP queries | Description: This implementation includes support for RDAP queries | |||
using data from the public test environment of .it ccTLD. The | using data from the public test environment of .it ccTLD. | |||
RDAP server does not implement any security policy because data | ||||
returned by this server are only for experimental testing | ||||
purposes. | ||||
Level of Maturity: This is a "proof of concept" research | Level of Maturity: This is a "proof of concept" research | |||
implementation. | implementation. | |||
Coverage: This implementation includes all of the features | Coverage: This implementation includes all of the features | |||
described in this specification. | described in this specification. | |||
Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it | Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it | |||
5. Security Considerations | 5. Privacy Considerations | |||
Security services for the operations specified in this document are | The use of the capability described in this document SHOULD be | |||
described in RFC 7481 [RFC7481]. It is quite easy to imagine that, | compliant with the rules about privacy protection each RDAP provider | |||
in order to be compliant with ICANN recommendations about its use, | is subject to. Sensitive registration data SHOULD be protected and | |||
RDAP servers will provide reverse search, like other query | accessible for permissible purposes only. Therefore, it is | |||
capabilities, only to restricted communities. One realistic scenario | recommended that RDAP servers provide reverse search only to those | |||
for servers is to provide reverse search only for registrars | requestors who are authorized according to a lawful basis. Some | |||
searching for their own domains. Another one is to prevent users to | potential users of this capability include registrars searching for | |||
start a reverse search from a registrant detail, by removing | their own domains and operators in the exercise of an official | |||
"registrant" from the possible "role" values. | authority or performing a specific task in the public interest that | |||
is set out in law. Another scenario consists of permitting reverse | ||||
searches, which take into account only those entities that have | ||||
previously given the explicit consent for publishing and processing | ||||
their personal data. | ||||
6. IANA Considerations | 6. Security Considerations | |||
Security services required to provide controlled access to the | ||||
operations specified in this document are described in RFC 7481 | ||||
([RFC7481]). | ||||
7. IANA Considerations | ||||
This document has no actions for IANA. | This document has no actions for IANA. | |||
7. Acknowledgements | 8. Acknowledgements | |||
The authors would like to acknowledge Scott Hollenbeck, Francisco | The authors would like to acknowledge Scott Hollenbeck, Francisco | |||
Arias, Gustavo Lozano and Eduardo Alvarez for their contribution to | Arias, Gustavo Lozano and Eduardo Alvarez for their contribution to | |||
this document. | this document. | |||
8. References | 9. References | |||
8.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, | [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, | |||
DOI 10.17487/RFC3912, September 2004, | DOI 10.17487/RFC3912, September 2004, | |||
<https://www.rfc-editor.org/info/rfc3912>. | <https://www.rfc-editor.org/info/rfc3912>. | |||
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | ||||
DOI 10.17487/RFC5322, October 2008, | ||||
<https://www.rfc-editor.org/info/rfc5322>. | ||||
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", | ||||
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, | ||||
<https://www.rfc-editor.org/info/rfc5730>. | ||||
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) | [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) | |||
Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, | Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, | |||
August 2009, <https://www.rfc-editor.org/info/rfc5733>. | August 2009, <https://www.rfc-editor.org/info/rfc5733>. | |||
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Message Syntax and Routing", | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
RFC 7230, DOI 10.17487/RFC7230, June 2014, | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7230>. | <https://www.rfc-editor.org/info/rfc7230>. | |||
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the | [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the | |||
skipping to change at page 8, line 39 ¶ | skipping to change at page 9, line 15 ¶ | |||
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the | [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the | |||
Registration Data Access Protocol (RDAP)", RFC 7483, | Registration Data Access Protocol (RDAP)", RFC 7483, | |||
DOI 10.17487/RFC7483, March 2015, | DOI 10.17487/RFC7483, March 2015, | |||
<https://www.rfc-editor.org/info/rfc7483>. | <https://www.rfc-editor.org/info/rfc7483>. | |||
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | |||
Interchange Format", STD 90, RFC 8259, | Interchange Format", STD 90, RFC 8259, | |||
DOI 10.17487/RFC8259, December 2017, | DOI 10.17487/RFC8259, December 2017, | |||
<https://www.rfc-editor.org/info/rfc8259>. | <https://www.rfc-editor.org/info/rfc8259>. | |||
8.2. Informative References | 9.2. Informative References | |||
[ICANN-RA] | [ICANN-RA] | |||
Internet Corporation For Assigned Names and Numbers, | Internet Corporation For Assigned Names and Numbers, | |||
"Registry Agreement", July 2017, | "Registry Agreement", July 2017, | |||
<https://newgtlds.icann.org/sites/default/files/ | <https://newgtlds.icann.org/sites/default/files/ | |||
agreements/agreement-approved-31jul17-en.pdf>. | agreements/agreement-approved-31jul17-en.pdf>. | |||
[ICANN-RDS] | [ICANN-RDS1] | |||
Internet Corporation For Assigned Names and Numbers, | Internet Corporation For Assigned Names and Numbers, | |||
"Final Report from the Expert Working Group on gTLD | "Final Report from the Expert Working Group on gTLD | |||
Directory Services: A Next-Generation Registration | Directory Services: A Next-Generation Registration | |||
Directory Service (RDS)", June 2014, | Directory Service (RDS)", June 2014, | |||
<https://www.icann.org/en/system/files/files/ | <https://www.icann.org/en/system/files/files/ | |||
final-report-06jun14-en.pdf>. | final-report-06jun14-en.pdf>. | |||
[JSURL] "JSURL", 2016, <https://github.com/Sage/jsurl>. | [ICANN-RDS2] | |||
Internet Corporation For Assigned Names and Numbers, | ||||
"Final Issue Report on a Next-Generation gTLD RDS to | ||||
Replace WHOIS", October 2015, | ||||
<http://whois.icann.org/sites/default/files/files/ | ||||
final-issue-report-next-generation-rds-07oct15-en.pdf>. | ||||
[JSURL] github.com, "JSURL", 2016, | ||||
<https://github.com/Sage/jsurl>. | ||||
[REST] Fielding, R., "Architectural Styles and the Design of | [REST] Fielding, R., "Architectural Styles and the Design of | |||
Network-based Software Architectures", 2000, | Network-based Software Architectures", 2000, | |||
<http://www.restapitutorial.com/media/ | <http://www.restapitutorial.com/media/ | |||
RESTful_Best_Practices-v1_1.pdf>. | RESTful_Best_Practices-v1_1.pdf>. | |||
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | |||
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | |||
<https://www.rfc-editor.org/info/rfc4648>. | <https://www.rfc-editor.org/info/rfc4648>. | |||
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | |||
Code: The Implementation Status Section", BCP 205, | Code: The Implementation Status Section", BCP 205, | |||
RFC 7942, DOI 10.17487/RFC7942, July 2016, | RFC 7942, DOI 10.17487/RFC7942, July 2016, | |||
<https://www.rfc-editor.org/info/rfc7942>. | <https://www.rfc-editor.org/info/rfc7942>. | |||
[RISON] "Rison - Compact Data in URIs", 2017, | [RISON] github.com, "Rison - Compact Data in URIs", 2017, | |||
<https://github.com/Nanonid/rison>. | <https://github.com/Nanonid/rison>. | |||
[URLON] "URL Object Notation", 2017, | [URLON] github.com, "URL Object Notation", 2017, | |||
<https://github.com/cerebral/urlon>. | <https://github.com/cerebral/urlon>. | |||
Appendix A. Change Log | Appendix A. Change Log | |||
00: Initial version. | 00: Initial version. | |||
01: Revised some sentences and references. | 01: Revised some sentences and references. | |||
02: Added "entityEmail" and "entityAddr" path segments. Removed | 02: Added "entityEmail" and "entityAddr" path segments. Removed | |||
"entityRole" path segment. Revised "Acknowledgements" section | "entityRole" path segment. Revised "Acknowledgements" section. | |||
03: Added "JSON in URLs" section | 03: Added "JSON in URLs" section. | |||
04: Revised some sentences in "Introduction" section. Added | ||||
"Privacy Considerations" section. | ||||
Authors' Addresses | Authors' Addresses | |||
Mario Loffredo | Mario Loffredo | |||
IIT-CNR/Registro.it | IIT-CNR/Registro.it | |||
Via Moruzzi,1 | Via Moruzzi,1 | |||
Pisa 56124 | Pisa 56124 | |||
IT | IT | |||
Email: mario.loffredo@iit.cnr.it | Email: mario.loffredo@iit.cnr.it | |||
End of changes. 46 change blocks. | ||||
113 lines changed or deleted | 144 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |