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