draft-ietf-regext-rfc7482bis-00.txt   draft-ietf-regext-rfc7482bis-01.txt 
REGEXT Working Group S. Hollenbeck REGEXT Working Group S. Hollenbeck
Internet-Draft Verisign Labs Internet-Draft Verisign Labs
Intended status: Standards Track A. Newton Intended status: Standards Track A. Newton
Expires: December 7, 2020 AWS Expires: December 31, 2020 AWS
June 5, 2020 June 29, 2020
Registration Data Access Protocol (RDAP) Query Format Registration Data Access Protocol (RDAP) Query Format
draft-ietf-regext-rfc7482bis-00 draft-ietf-regext-rfc7482bis-01
Abstract Abstract
This document describes uniform patterns to construct HTTP URLs that This document describes uniform patterns to construct HTTP URLs that
may be used to retrieve registration information from registries may be used to retrieve registration information from registries
(including both Regional Internet Registries (RIRs) and Domain Name (including both Regional Internet Registries (RIRs) and Domain Name
Registries (DNRs)) using "RESTful" web access patterns. These Registries (DNRs)) using "RESTful" web access patterns. These
uniform patterns define the query syntax for the Registration Data uniform patterns define the query syntax for the Registration Data
Access Protocol (RDAP). Access Protocol (RDAP).
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 7, 2020. This Internet-Draft will expire on December 31, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
o lack of standardized output and error structures; o lack of standardized output and error structures;
o lack of support for internationalization and localization; and o lack of support for internationalization and localization; and
o lack of support for user identification, authentication, and o lack of support for user identification, authentication, and
access control. access control.
The patterns described in this document purposefully do not encompass The patterns described in this document purposefully do not encompass
all of the methods employed in the WHOIS and other RESTful web all of the methods employed in the WHOIS and other RESTful web
services used by the RIRs and DNRs. The intent of the patterns services used by the RIRs and DNRs. The intent of the patterns
described here are to enable queries of: described here is to enable queries of:
o networks by IP address; o networks by IP address;
o Autonomous System (AS) numbers by number; o Autonomous System (AS) numbers by number;
o reverse DNS metadata by domain; o reverse DNS metadata by domain;
o nameservers by name; and o nameservers by name; and
o entities (such as registrars and contacts) by identifier. o entities (such as registrars and contacts) by identifier.
skipping to change at page 4, line 11 skipping to change at page 4, line 11
described in Section 5 to accommodate custom extensions that will not described in Section 5 to accommodate custom extensions that will not
interfere with the patterns defined in this document or patterns interfere with the patterns defined in this document or patterns
defined in future IETF standards. defined in future IETF standards.
WHOIS services, in general, are read-only services. Therefore, URL WHOIS services, in general, are read-only services. Therefore, URL
[RFC3986] patterns specified in this document are only applicable to [RFC3986] patterns specified in this document are only applicable to
the HTTP [RFC7231] GET and HEAD methods. the HTTP [RFC7231] GET and HEAD methods.
This document does not describe the results or entities returned from This document does not describe the results or entities returned from
issuing the described URLs with an HTTP GET. The specification of issuing the described URLs with an HTTP GET. The specification of
these entities is described in [I-D.hollenbeck-regext-rfc7483bis]. these entities is described in [I-D.ietf-regext-rfc7483bis].
Additionally, resource management, provisioning, and update functions Additionally, resource management, provisioning, and update functions
are out of scope for this document. Registries have various and are out of scope for this document. Registries have various and
divergent methods covering these functions, and it is unlikely a divergent methods covering these functions, and it is unlikely a
uniform approach is needed for interoperability. uniform approach is needed for interoperability.
HTTP contains mechanisms for servers to authenticate clients and for HTTP contains mechanisms for servers to authenticate clients and for
clients to authenticate servers (from which authorization schemes may clients to authenticate servers (from which authorization schemes may
be built), so such mechanisms are not described in this document. be built), so such mechanisms are not described in this document.
Policy, provisioning, and processing of authentication and Policy, provisioning, and processing of authentication and
skipping to change at page 6, line 44 skipping to change at page 6, line 44
The IPv4 and IPv6 address formats supported in this query are The IPv4 and IPv6 address formats supported in this query are
described in Section 3.2.2 of RFC 3986 [RFC3986] as IPv4address and described in Section 3.2.2 of RFC 3986 [RFC3986] as IPv4address and
IPv6address ABNF definitions. Any valid IPv6 text address format IPv6address ABNF definitions. Any valid IPv6 text address format
[RFC4291] can be used. This includes IPv6 addresses written using [RFC4291] can be used. This includes IPv6 addresses written using
with or without compressed zeros and IPv6 addresses containing with or without compressed zeros and IPv6 addresses containing
embedded IPv4 addresses. The rules to write a text representation of embedded IPv4 addresses. The rules to write a text representation of
an IPv6 address [RFC5952] are RECOMMENDED. However, the zone_id an IPv6 address [RFC5952] are RECOMMENDED. However, the zone_id
[RFC4007] is not appropriate in this context; therefore, the [RFC4007] is not appropriate in this context; therefore, the
corresponding syntax extension in RFC 6874 [RFC6874] MUST NOT be corresponding syntax extension in RFC 6874 [RFC6874] MUST NOT be
used, and servers are to ignore it if possible. used, and servers SHOULD ignore it.
For example, the following URL would be used to find information for For example, the following URL would be used to find information for
the most specific network containing 192.0.2.0: the most specific network containing 192.0.2.0:
https://example.com/rdap/ip/192.0.2.0 https://example.com/rdap/ip/192.0.2.0
The following URL would be used to find information for the most The following URL would be used to find information for the most
specific network containing 192.0.2.0/24: specific network containing 192.0.2.0/24:
https://example.com/rdap/ip/192.0.2.0/24 https://example.com/rdap/ip/192.0.2.0/24
skipping to change at page 12, line 23 skipping to change at page 12, line 23
Syntax: entities?handle=<entity handle search pattern> Syntax: entities?handle=<entity handle search pattern>
Searches for entity information by name are specified using this Searches for entity information by name are specified using this
form: form:
entities?fn=XXXX entities?fn=XXXX
XXXX is a search pattern representing the "fn" property of an entity XXXX is a search pattern representing the "fn" property of an entity
(such as a contact, registrant, or registrar) name as described in (such as a contact, registrant, or registrar) name as described in
Section 5.1 of [I-D.hollenbeck-regext-rfc7483bis]. The following URL Section 5.1 of [I-D.ietf-regext-rfc7483bis]. The following URL would
would be used to find information for entity names matching the be used to find information for entity names matching the "Bobby
"Bobby Joe*" pattern: Joe*" pattern:
https://example.com/rdap/entities?fn=Bobby%20Joe* https://example.com/rdap/entities?fn=Bobby%20Joe*
Searches for entity information by handle are specified using this Searches for entity information by handle are specified using this
form: form:
entities?handle=XXXX entities?handle=XXXX
XXXX is a search pattern representing an entity (such as a contact, XXXX is a search pattern representing an entity (such as a contact,
registrant, or registrar) identifier whose syntax is specific to the registrant, or registrar) identifier whose syntax is specific to the
skipping to change at page 13, line 16 skipping to change at page 13, line 16
Partial string searching uses the asterisk ('*', US-ASCII value Partial string searching uses the asterisk ('*', US-ASCII value
0x002A) character to match zero or more trailing characters. A 0x002A) character to match zero or more trailing characters. A
character string representing a domain label suffix MAY be character string representing a domain label suffix MAY be
concatenated to the end of the search pattern to limit the scope of concatenated to the end of the search pattern to limit the scope of
the search. For example, the search pattern "exam*" will match the search. For example, the search pattern "exam*" will match
"example.com" and "example.net". The search pattern "exam*.com" will "example.com" and "example.net". The search pattern "exam*.com" will
match "example.com". If an asterisk appears in a search string, any match "example.com". If an asterisk appears in a search string, any
label that contains the non-asterisk characters in sequence plus zero label that contains the non-asterisk characters in sequence plus zero
or more characters in sequence in place of the asterisk would match. or more characters in sequence in place of the asterisk would match.
Only a single asterisk is allowed for a partial string search. A partial string search MUST NOT include more than one asterisk.
Additional pattern matching processing is beyond the scope of this Additional pattern matching processing is beyond the scope of this
specification. specification.
If a server receives a search request but cannot process the request If a server receives a search request but cannot process the request
because it does not support a particular style of partial match because it does not support a particular style of partial match
searching, it SHOULD return an HTTP 422 (Unprocessable Entity) searching, it SHOULD return an HTTP 422 (Unprocessable Entity)
[RFC4918] response. When returning a 422 error, the server MAY also [RFC4918] response. When returning a 422 error, the server MAY also
return an error response body as specified in Section 6 of return an error response body as specified in Section 6 of
[I-D.hollenbeck-regext-rfc7483bis] if the requested media type is one [I-D.ietf-regext-rfc7483bis] if the requested media type is one that
that is specified in [RFC7480]. is specified in [RFC7480].
Partial matching is not feasible across combinations of Unicode Partial matching is not feasible across combinations of Unicode
characters because Unicode characters can be combined with each characters because Unicode characters can be combined with each
other. Servers SHOULD NOT partially match combinations of Unicode other. Servers SHOULD NOT partially match combinations of Unicode
characters where a legal combination is possible. It should be characters where a legal combination is possible. It should be
noted, though, that it may not always be possible to detect cases noted, though, that it may not always be possible to detect cases
where a character could have been combined with another character, where a character could have been combined with another character,
but was not, because characters can be combined in many different but was not, because characters can be combined in many different
ways. ways.
Clients should avoid submitting a partial match search of Unicode Clients SHOULD NOT submit a partial match search of Unicode
characters where a Unicode character may be legally combined with characters where a Unicode character may be legally combined with
another Unicode character or characters. Partial match searches with another Unicode character or characters. Partial match searches with
incomplete combinations of characters where a character must be incomplete combinations of characters where a character must be
combined with another character or characters are invalid. Partial combined with another character or characters are invalid. Partial
match searches with characters that may be combined with another match searches with characters that may be combined with another
character or characters are to be considered non-combined characters character or characters are to be considered non-combined characters
(that is, if character x may be combined with character y but (that is, if character x may be combined with character y but
character y is not submitted in the search string, then character x character y is not submitted in the search string, then character x
is a complete character and no combinations of character x are to be is a complete character and no combinations of character x are to be
searched). searched).
skipping to change at page 15, line 21 skipping to change at page 15, line 21
more visually recognizable and familiar than A-label strings, but more visually recognizable and familiar than A-label strings, but
clients using programmatic interfaces might find it easier to submit clients using programmatic interfaces might find it easier to submit
and display A-labels if they are unable to input U-labels with their and display A-labels if they are unable to input U-labels with their
keyboard configuration. Both query forms are acceptable. keyboard configuration. Both query forms are acceptable.
Internationalized domain and nameserver names can contain character Internationalized domain and nameserver names can contain character
variants and variant labels as described in [RFC4290]. Clients that variants and variant labels as described in [RFC4290]. Clients that
support queries for internationalized domain and nameserver names support queries for internationalized domain and nameserver names
MUST accept service provider responses that describe variants as MUST accept service provider responses that describe variants as
specified in "JSON Responses for the Registration Data Access specified in "JSON Responses for the Registration Data Access
Protocol (RDAP)" [I-D.hollenbeck-regext-rfc7483bis]. Protocol (RDAP)" [I-D.ietf-regext-rfc7483bis].
6.1. Character Encoding Considerations 6.1. Character Encoding Considerations
Servers can expect to receive search patterns from clients that Servers can expect to receive search patterns from clients that
contain character strings encoded in different forms supported by contain character strings encoded in different forms supported by
HTTP. It is entirely possible to apply filters and normalization HTTP. It is entirely possible to apply filters and normalization
rules to search patterns prior to making character comparisons, but rules to search patterns prior to making character comparisons, but
this type of processing is more typically needed to determine the this type of processing is more typically needed to determine the
validity of registered strings than to match patterns. validity of registered strings than to match patterns.
skipping to change at page 23, line 7 skipping to change at page 23, line 7
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
2015, <https://www.rfc-editor.org/info/rfc7484>. 2015, <https://www.rfc-editor.org/info/rfc7484>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[I-D.ietf-regext-rfc7483bis] [I-D.ietf-regext-rfc7483bis]
Hollenbeck, S. and A. Newton, "JSON Responses for the Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", draft- Registration Data Access Protocol (RDAP)", draft-ietf-
ietf-regext-rfc7483bis-00 (work in progress), June regext-rfc7483bis-00 (work in progress), June 2020.
2020.
[Unicode-UAX15] [Unicode-UAX15]
The Unicode Consortium, "Unicode Standard Annex #15: The Unicode Consortium, "Unicode Standard Annex #15:
Unicode Normalization Forms", September 2013, Unicode Normalization Forms", September 2013,
<https://www.unicode.org/reports/tr15/>. <https://www.unicode.org/reports/tr15/>.
10.2. Informative References 10.2. Informative References
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Network-based Software Architectures", Ph.D.
skipping to change at page 25, line 9 skipping to change at page 25, line 9
NicInfo implementation status into two sections. NicInfo implementation status into two sections.
06: Changed "XXXX is a search pattern representing the "FN" property 06: Changed "XXXX is a search pattern representing the "FN" property
of an entity (such as a contact, registrant, or registrar) name as of an entity (such as a contact, registrant, or registrar) name as
specified in Section 5.1" to "Changed "XXXX is a search pattern specified in Section 5.1" to "Changed "XXXX is a search pattern
representing the "fn" property of an entity (such as a contact, representing the "fn" property of an entity (such as a contact,
registrant, or registrar) name as described in Section 5.1". registrant, or registrar) name as described in Section 5.1".
00: Initial working group version. Added acknowledgements. 00: Initial working group version. Added acknowledgements.
01: Changed "The intent of the patterns described here are to enable
queries" to "The intent of the patterns described here is to
enable queries". Changed "the corresponding syntax extension in
RFC 6874 [RFC6874] MUST NOT be used, and servers are to ignore it
if possible" to "the corresponding syntax extension in RFC 6874
[RFC6874] MUST NOT be used, and servers SHOULD ignore it".
Changed "Only a single asterisk is allowed for a partial string
search" to "A partial string search MUST NOT include more than one
asterisk". Changed "Clients should avoid submitting a partial
match search of Unicode characters where a Unicode character may
be legally combined with another Unicode character or characters"
to "Clients SHOULD NOT submit a partial match search of Unicode
characters where a Unicode character may be legally combined with
another Unicode character or characters".
Authors' Addresses Authors' Addresses
Scott Hollenbeck Scott Hollenbeck
Verisign Labs Verisign Labs
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States of America United States of America
Email: shollenbeck@verisign.com Email: shollenbeck@verisign.com
URI: https://www.verisignlabs.com/ URI: https://www.verisignlabs.com/
 End of changes. 13 change blocks. 
18 lines changed or deleted 32 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/