draft-ietf-weirds-rdap-query-13.txt   draft-ietf-weirds-rdap-query-14.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track S. Hollenbeck Intended status: Standards Track S. Hollenbeck
Expires: February 26, 2015 Verisign Labs Expires: March 26, 2015 Verisign Labs
August 25, 2014 September 22, 2014
Registration Data Access Protocol Query Format Registration Data Access Protocol Query Format
draft-ietf-weirds-rdap-query-13 draft-ietf-weirds-rdap-query-14
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. Registries (DNRs)) using "RESTful" web access patterns. These
uniform patterns define the query syntax for the Registration Data
Access Protocol (RDAP).
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 26, 2015. This Internet-Draft will expire on March 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 11 skipping to change at page 2, line 13
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. Conventions Used in This Document . . . . . . . . . . . . . . 2 1. Conventions Used in This Document . . . . . . . . . . . . . . 2
1.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 2 1.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Path Segment Specification . . . . . . . . . . . . . . . . . 4 3. Path Segment Specification . . . . . . . . . . . . . . . . . 4
3.1. Lookup Path Segment Specification . . . . . . . . . . . . 4 3.1. Lookup Path Segment Specification . . . . . . . . . . . . 5
3.1.1. IP Network Path Segment Specification . . . . . . . . 5 3.1.1. IP Network Path Segment Specification . . . . . . . . 5
3.1.2. Autonomous System Path Segment Specification . . . . 6 3.1.2. Autonomous System Path Segment Specification . . . . 6
3.1.3. Domain Path Segment Specification . . . . . . . . . . 6 3.1.3. Domain Path Segment Specification . . . . . . . . . . 6
3.1.4. Name Server Path Segment Specification . . . . . . . 7 3.1.4. Name Server Path Segment Specification . . . . . . . 7
3.1.5. Entity Path Segment Specification . . . . . . . . . . 7 3.1.5. Entity Path Segment Specification . . . . . . . . . . 8
3.1.6. Help Path Segment Specification . . . . . . . . . . . 8 3.1.6. Help Path Segment Specification . . . . . . . . . . . 8
3.2. Search Path Segment Specification . . . . . . . . . . . . 8 3.2. Search Path Segment Specification . . . . . . . . . . . . 8
3.2.1. Domain Search . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Domain Search . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Name Server Search . . . . . . . . . . . . . . . . . 10 3.2.2. Name Server Search . . . . . . . . . . . . . . . . . 10
3.2.3. Entity Search . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Entity Search . . . . . . . . . . . . . . . . . . . . 11
4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 11 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 12
5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Partial String Searching . . . . . . . . . . . . . . . . 12
6. Internationalization Considerations . . . . . . . . . . . . . 13 4.2. Character Encoding Considerations . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4.3. Associated Records . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. Internationalization Considerations . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Conventions Used in This Document 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.1. Acronyms and Abbreviations 1.1. Acronyms and Abbreviations
IDN: Internationalized Domain Name IDN: Internationalized Domain Name
skipping to change at page 3, line 10 skipping to change at page 3, line 16
was first described in a doctoral dissertation [REST]. was first described in a doctoral dissertation [REST].
RESTful: An adjective that describes a service using HTTP and the RESTful: An adjective that describes a service using HTTP and the
principles of REST. principles of REST.
RIR: Regional Internet Registry RIR: Regional Internet Registry
2. Introduction 2. Introduction
This document describes a specification for querying registration This document describes a specification for querying registration
data using a RESTful web service and uniform query patterns. The data using a RESTful web service and uniform query patterns. The
service is implemented using the Hypertext Transfer Protocol (HTTP) service is implemented using the Hypertext Transfer Protocol (HTTP)
[RFC7230]. [RFC7230]. These uniform patterns define the query syntax for the
Registration Data Access Protocol (RDAP).
The protocol described in this specification is intended to address The protocol described in this specification is intended to address
deficiencies with the WHOIS protocol [RFC3912] that have been deficiencies with the WHOIS protocol [RFC3912] that have been
identified over time, including: identified over time, including:
o Lack of standardized command structures, o Lack of standardized command structures,
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.
skipping to change at page 3, line 34 skipping to change at page 3, line 41
all of the RIRs and DNRs. The intent of the patterns described here all of the RIRs and DNRs. The intent of the patterns described here
are to enable queries of: are to enable queries of:
o networks by IP address, o networks by IP address,
o autonomous system numbers by number, o autonomous system numbers by number,
o reverse DNS meta-data by domain, o reverse DNS meta-data by domain,
o name servers by name, o name servers by name,
o registrars by name, and o registrars by name, and
o entities (such as contacts) by identifier. o entities (such as contacts) by identifier.
It is envisioned that each registry will continue to maintain Server implementations are free to support only a subset of these
NICNAME/WHOIS and/or RESTful web services specific to their needs and features depending on local requirements. If a server receives a
those of their constituencies, and the information retrieved through query that it cannot process because it is not implemented it SHOULD
the patterns described here may reference such services. return an HTTP 501 [RFC7231] error. It is also envisioned that each
registry will continue to maintain WHOIS and/or RESTful web services
specific to their needs and those of their constituencies, and the
information retrieved through the patterns described here may
reference such services.
Likewise, future IETF standards may add additional patterns for Likewise, future IETF standards may add additional patterns for
additional query types. A simple pattern namespacing scheme is additional query types. A simple pattern namespacing scheme is
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.
skipping to change at page 4, line 15 skipping to change at page 4, line 27
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 for these functions will ever be possible. uniform approach for these functions will ever be possible.
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
authorization are out-of-scope for this document as deployments will authorization are out-of-scope for this document as deployments will
have to make choices based on local criteria. Specified have to make choices based on local criteria. Supported
authentication mechanisms MUST use HTTP. authentication mechanisms are described in
[I-D.ietf-weirds-rdap-sec].
3. Path Segment Specification 3. Path Segment Specification
The base URLs used to construct RDAP queries are maintained in an The base URLs used to construct RDAP queries are maintained in an
IANA registry described in [I-D.ietf-weirds-bootstrap]. Queries are IANA registry described in [I-D.ietf-weirds-bootstrap]. Queries are
formed by retrieving the appropriate base URL from the registry and formed by retrieving the appropriate base URL from the registry and
appending a path segment specified in either Section 3.1 or appending a path segment specified in either Section 3.1 or
Section 3.2. Generally, a registry or other service provider will Section 3.2. Generally, a registry or other service provider will
provide a base URL that identifies the protocol, host and port, and provide a base URL that identifies the protocol, host and port, and
this will be used as a base URL that the complete URL is resolved this will be used as a base URL that the complete URL is resolved
skipping to change at page 6, line 40 skipping to change at page 7, line 6
3.1.3. Domain Path Segment Specification 3.1.3. Domain Path Segment Specification
Syntax: domain/<domain name> Syntax: domain/<domain name>
Queries for domain information are of the form /domain/XXXX/..., Queries for domain information are of the form /domain/XXXX/...,
where XXXX is a fully-qualified (relative to the root) domain name where XXXX is a fully-qualified (relative to the root) domain name
[RFC1594] in either the in-addr.arpa or ip6.arpa zones (for RIRs) or [RFC1594] in either the in-addr.arpa or ip6.arpa zones (for RIRs) or
a fully-qualified domain name in a zone administered by the server a fully-qualified domain name in a zone administered by the server
operator (for DNRs). Internationalized domain names represented in operator (for DNRs). Internationalized domain names represented in
either A-label or U-label format [RFC5890] are also valid domain either A-label or U-label format [RFC5890] are also valid domain
names. IDNs SHOULD NOT be represented as a mixture of A-labels and names.
U-labels; that is, all internationalized labels in an IDN SHOULD be
either A-labels or U-labels.
If the client sends the server an IDN in U-label format, servers that IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels;
support IDNs MUST convert the IDN into A-label format and perform that is, all internationalized labels in an IDN SHOULD be either
IDNA processing as specified in RFC 5891 [RFC5891]. The server A-labels or U-labels. It is possible for an RDAP client to assemble
should perform an exact match lookup using the A-label. a query string from multiple independent data sources. Such a client
might not be able to perform conversions between A-labels and
U-labels. An RDAP server that receives a query string with a mixture
of A-labels and U-labels MAY convert all the U-labels to A-labels,
perform IDNA processing, and proceed with exact-match lookup. In
such cases, the response to be returned to the query source may not
match the input from the query source. Alternatively, the server MAY
refuse to process the query.
The server MAY perform the match using either the A-label or U-label
form. Using one consistent form for matching every label is likely
to be more reliable.
The following URL would be used to find information describing the The following URL would be used to find information describing the
zone serving the network 192.0.2/24: zone serving the network 192.0.2/24:
http://example.com/rdap/domain/2.0.192.in-addr.arpa http://example.com/rdap/domain/2.0.192.in-addr.arpa
The following URL would be used to find information describing the The following URL would be used to find information describing the
zone serving the network 2001:db8:1::/48: zone serving the network 2001:db8:1::/48:
http://example.com/rdap/domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa http://example.com/rdap/domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
The following URL would be used to find information for the The following URL would be used to find information for the
blah.example.com domain name: blah.example.com domain name:
http://example.com/rdap/domain/blah.example.com http://example.com/rdap/domain/blah.example.com
skipping to change at page 7, line 26 skipping to change at page 7, line 51
http://example.com/rdap/domain/xn--fo-5ja.example http://example.com/rdap/domain/xn--fo-5ja.example
3.1.4. Name Server Path Segment Specification 3.1.4. Name Server Path Segment Specification
Syntax: nameserver/<name server name> Syntax: nameserver/<name server name>
The <name server name> parameter represents a fully qualified name as The <name server name> parameter represents a fully qualified name as
specified in RFC 952 [RFC0952] and RFC 1123 [RFC1123]. specified in RFC 952 [RFC0952] and RFC 1123 [RFC1123].
Internationalized names represented in either A-label or U-label Internationalized names represented in either A-label or U-label
format [RFC5890] are also valid name server names. IDNs SHOULD NOT format [RFC5890] are also valid name server names. IDN processing
be represented as a mixture of A-labels and U-labels; that is, all for name server names uses the domain name processing instructions
internationalized labels in an IDN SHOULD be either A-labels or specified in Section 3.1.3.
U-labels.
If the client sends the server an IDN in U-label format, servers that
support IDNs MUST convert the IDN into A-label format and perform
IDNA processing as specified in RFC 5891 [RFC5891]. The server
should perform an exact match lookup using the A-label.
The following URL would be used to find information for the The following URL would be used to find information for the
ns1.example.com name server: ns1.example.com name server:
http://example.com/rdap/nameserver/ns1.example.com http://example.com/rdap/nameserver/ns1.example.com
The following URL would be used to find information for the The following URL would be used to find information for the
ns1.xn--fo-5ja.example name server: ns1.xn--fo-5ja.example name server:
http://example.com/rdap/nameserver/ns1.xn--fo-5ja.example http://example.com/rdap/nameserver/ns1.xn--fo-5ja.example
3.1.5. Entity Path Segment Specification 3.1.5. Entity Path Segment Specification
Syntax: entity/<handle> Syntax: entity/<handle>
The <handle> parameter represents an entity (such as a contact, The <handle> parameter represents an entity (such as a contact,
registrant, or registrar) identifier. For example, for some DNRs registrant, or registrar) identifier whose syntax is specific to the
contact identifiers are specified in RFC 5730 [RFC5730] and RFC 5733 registration provider. For example, for some DNRs contact
identifiers are specified in RFC 5730 [RFC5730] and RFC 5733
[RFC5733]. [RFC5733].
The following URL would be used to find information for the entity The following URL would be used to find information for the entity
associated with handle XXXX: associated with handle XXXX:
http://example.com/rdap/entity/XXXX http://example.com/rdap/entity/XXXX
3.1.6. Help Path Segment Specification 3.1.6. Help Path Segment Specification
Syntax: help Syntax: help
skipping to change at page 8, line 31 skipping to change at page 9, line 4
successfully use the service. The following URL would be used to successfully use the service. The following URL would be used to
return "help" information: return "help" information:
http://example.com/rdap/help http://example.com/rdap/help
3.2. Search Path Segment Specification 3.2. Search Path Segment Specification
A simple search to determine if an object exists (or not) without A simple search to determine if an object exists (or not) without
returning RDAP-encoded results can be performed using the HTTP HEAD returning RDAP-encoded results can be performed using the HTTP HEAD
method as described in Section 4.1 of [I-D.ietf-weirds-using-http]. method as described in Section 4.1 of [I-D.ietf-weirds-using-http].
Detailed results can be retrieved using the path segments specified
here.
The resource type path segments for search are: The resource type path segments for search are:
o 'domains': Used to identify a domain name information search using o 'domains': Used to identify a domain name information search using
a pattern to match a fully-qualified domain name. a pattern to match a fully-qualified domain name.
o 'nameservers': Used to identify a name server information search o 'nameservers': Used to identify a name server information search
using a pattern to match a host name. using a pattern to match a host name.
o 'entities': Used to identify an entity information search using a o 'entities': Used to identify an entity information search using a
pattern to match a string identifier. pattern to match a string identifier.
RDAP search path segments are formed using a concatenation of the RDAP search path segments are formed using a concatenation of the
plural form of the object being searched for, a forward slash plural form of the object being searched for and an HTTP query
character ('/', ASCII value 0x002F), and an HTTP query string. The string. The HTTP query string is formed using a concatenation of the
HTTP query string is formed using a concatenation of the question question mark character ('?', ASCII value 0x003F), the JSON object
mark character ('?', ASCII value 0x003F), the JSON object value value associated with the object being searched for, the equal sign
associated with the object being searched for, the equal sign character ('=', ASCII value 0x003D), and the search pattern. Search
character ('=', ASCII value 0x003D), and the search pattern. For the pattern query processing is described more fully in Section 4. For
domain and entity objects described in this document the plural the domain and entity objects described in this document the plural
object forms are "domains" and "entities". object forms are "domains" and "entities".
Detailed results can be retrieved using the HTTP GET method and the
path segments specified here.
3.2.1. Domain Search 3.2.1. Domain Search
Syntax: domains?name=<domain search pattern> Syntax: domains?name=<domain search pattern>
Syntax: domains?nsLdhName=<domain search pattern> Syntax: domains?nsLdhName=<domain search pattern>
Syntax: domains?nsIp=<domain search pattern> Syntax: domains?nsIp=<domain search pattern>
Searches for domain information by name are specified using this Searches for domain information by name are specified using this
form: form:
skipping to change at page 11, line 33 skipping to change at page 12, line 12
URLs MUST be properly encoded according to the rules of [RFC3986]. URLs MUST be properly encoded according to the rules of [RFC3986].
In the example above, "Bobby Joe*" is encoded to "Bobby%20Joe*". In the example above, "Bobby Joe*" is encoded to "Bobby%20Joe*".
4. Query Processing 4. Query Processing
Servers indicate the success or failure of query processing by Servers indicate the success or failure of query processing by
returning an appropriate HTTP response code to the client. Response returning an appropriate HTTP response code to the client. Response
codes not specifically identified in this document are described in codes not specifically identified in this document are described in
[I-D.ietf-weirds-using-http]. [I-D.ietf-weirds-using-http].
4.1. Partial String Searching
Partial string searching uses the asterisk ('*', ASCII value 0x002A) Partial string searching uses the asterisk ('*', ASCII value 0x002A)
character to match zero or more trailing characters. A character character to match zero or more trailing characters. A character
string representing multiple domain name labels MAY be concatenated string representing multiple domain name labels MAY be concatenated
to the end of the search pattern to limit the scope of the search. 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 For example, the search pattern "exam*" will match "example.com" and
"example.net". The search pattern "exam*.com" will match "example.net". The search pattern "exam*.com" will match
"example.com". Note that these search patterns include implied "example.com". Note that these search patterns include implied
beginning and end of string regular expression markers, and the beginning and end of string regular expression markers, and the
"example*.com" search would be translated into a POSIX regular "example*.com" search would be translated into a POSIX regular
expression as "^example.*\.com$". Additional pattern matching expression as "^example.*\.com$". Additional pattern matching
skipping to change at page 12, line 9 skipping to change at page 12, line 38
searching, it SHOULD return an HTTP 422 [RFC4918] error. When searching, it SHOULD return an HTTP 422 [RFC4918] error. When
returning a 422 error, the server MAY also return an error response returning a 422 error, the server MAY also return an error response
body as specified in Section 7 of [I-D.ietf-weirds-json-response] if body as specified in Section 7 of [I-D.ietf-weirds-json-response] if
the requested media type is one that is specified in the requested media type is one that is specified in
[I-D.ietf-weirds-using-http]. [I-D.ietf-weirds-using-http].
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 another characters because Unicode characters can be combined with another
Unicode character or characters. Servers SHOULD NOT partially match Unicode character or characters. Servers SHOULD NOT partially match
combinations of Unicode characters where a Unicode character may be combinations of Unicode characters where a Unicode character may be
legally combined with another Unicode character or characters. legally combined with another Unicode character or characters. It
should be noted, though, that it may not always be possible to detect
possible cases where a character could have been combined with
another character, but was not, because of the way combining
characters can be combined with many other characters.
Clients should avoid submitting a partial match search of Unicode Clients should avoid submitting 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 is 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 a complete character and no combinations of character x are to be
searched). searched).
4.2. 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.
An RDAP client submitting a query string containing non-US-ASCII An RDAP client submitting a query string containing non-US-ASCII
characters converts such strings into Unicode in UTF-8 encoding. It characters converts such strings into Unicode in UTF-8 encoding. It
then performs any local case mapping deemed necessary. Strings are then performs any local case mapping deemed necessary. Strings are
skipping to change at page 13, line 12 skipping to change at page 14, line 5
For everything else, servers map fullwidth and halfwidth characters For everything else, servers map fullwidth and halfwidth characters
to their decomposition equivalents. Servers convert strings to the to their decomposition equivalents. Servers convert strings to the
same coded character set of the target data that is to be looked up same coded character set of the target data that is to be looked up
or searched and each string is normalized using the same or searched and each string is normalized using the same
normalization that was used on the target data. In general, storage normalization that was used on the target data. In general, storage
of strings as Unicode is RECOMMENDED. For the purposes of of strings as Unicode is RECOMMENDED. For the purposes of
comparison, Normalization Form KC (NFKC, [Unicode-UAX15]) with case comparison, Normalization Form KC (NFKC, [Unicode-UAX15]) with case
folding is used to maximize predictability and the number of matches. folding is used to maximize predictability and the number of matches.
Note the use of case-folded NFKC as opposed to NFC in this case. Note the use of case-folded NFKC as opposed to NFC in this case.
4.3. Associated Records
Conceptually, a name-record in a database may include a link to an Conceptually, a name-record in a database may include a link to an
associated name-record, which may include a link to another such associated name-record, which may include a link to another such
record, and so on. If an implementation is to return more than one record, and so on. If an implementation is to return more than one
name-record in response to a query, information from the records name-record in response to a query, information from the records
thereby identified is returned. thereby identified is returned.
Note that this model includes arrangements for associated names, Note that this model includes arrangements for associated names,
including those that are linked by policy mechanisms and names bound including those that are linked by policy mechanisms and names bound
together for some other purposes. Note also that returning together for some other purposes. Note also that returning
information that was not explicitly selected by an exact-match information that was not explicitly selected by an exact-match
skipping to change at page 15, line 21 skipping to change at page 16, line 14
Ernie Dainow, Jean-Philippe Dionne, Behnam Esfahbod, John Klensin, Ernie Dainow, Jean-Philippe Dionne, Behnam Esfahbod, John Klensin,
Edward Lewis, John Levine, Mark Nottingham, and Andrew Sullivan. Edward Lewis, John Levine, Mark Nottingham, and Andrew Sullivan.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-weirds-bootstrap] [I-D.ietf-weirds-bootstrap]
Blanchet, M. and G. Leclanche, "Finding the Authoritative Blanchet, M. and G. Leclanche, "Finding the Authoritative
Registration Data (RDAP) Service", draft-ietf-weirds- Registration Data (RDAP) Service", draft-ietf-weirds-
bootstrap-04 (work in progress), July 2014. bootstrap-06 (work in progress), September 2014.
[I-D.ietf-weirds-json-response] [I-D.ietf-weirds-json-response]
Newton, A. and S. Hollenbeck, "JSON Responses for the Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-json-response-08 (work in progress), August 2014. weirds-json-response-08 (work in progress), August 2014.
[I-D.ietf-weirds-rdap-sec] [I-D.ietf-weirds-rdap-sec]
Hollenbeck, S. and N. Kong, "Security Services for the Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol", draft-ietf-weirds- Registration Data Access Protocol", draft-ietf-weirds-
rdap-sec-08 (work in progress), August 2014. rdap-sec-08 (work in progress), August 2014.
[I-D.ietf-weirds-using-http] [I-D.ietf-weirds-using-http]
Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-using-http-10 (work in progress), August 2014. weirds-using-http-11 (work in progress), September 2014.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985. host table specification", RFC 952, October 1985.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
skipping to change at page 18, line 31 skipping to change at page 19, line 31
Replaced .well-known with bootstrap-defined prefix. Replaced Replaced .well-known with bootstrap-defined prefix. Replaced
references to RFC 2616 with references to RFC 7231 and draft-ietf- references to RFC 2616 with references to RFC 7231 and draft-ietf-
httpbis-http2, adding a note to make it clear that 2616 is an httpbis-http2, adding a note to make it clear that 2616 is an
acceptable reference if http2 isn't ready when needed. acceptable reference if http2 isn't ready when needed.
-12: IDN label processing clarification. Added domain search by -12: IDN label processing clarification. Added domain search by
name server name and name server IP address. Minor text editing name server name and name server IP address. Minor text editing
for consistency in the search sections. Replaced reference to for consistency in the search sections. Replaced reference to
draft-ietf-httpbis-http2 with a reference to RFC 7230 and removed draft-ietf-httpbis-http2 with a reference to RFC 7230 and removed
reference note. reference note.
-13: Added HTTP HEAD reference in Section 3.2. -13: Added HTTP HEAD reference in Section 3.2.
-14: Address WG last call comments.
Authors' Addresses Authors' Addresses
Andrew Lee Newton Andrew Lee Newton
American Registry for Internet Numbers American Registry for Internet Numbers
3635 Concorde Parkway 3635 Concorde Parkway
Chantilly, VA 20151 Chantilly, VA 20151
US US
Email: andy@arin.net Email: andy@arin.net
 End of changes. 25 change blocks. 
56 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/