draft-ietf-weirds-rdap-query-16.txt   draft-ietf-weirds-rdap-query-17.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: April 30, 2015 Verisign Labs Expires: June 26, 2015 Verisign Labs
October 27, 2014 December 23, 2014
Registration Data Access Protocol Query Format Registration Data Access Protocol Query Format
draft-ietf-weirds-rdap-query-16 draft-ietf-weirds-rdap-query-17
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 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 April 30, 2015. This Internet-Draft will expire on June 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 36 skipping to change at page 2, line 36
4.2. Associated Records . . . . . . . . . . . . . . . . . . . 13 4.2. Associated Records . . . . . . . . . . . . . . . . . . . 13
5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Internationalization Considerations . . . . . . . . . . . . . 14 6. Internationalization Considerations . . . . . . . . . . . . . 14
6.1. Character Encoding Considerations . . . . . . . . . . . . 14 6.1. Character Encoding Considerations . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
IDNA: Internationalized Domain Names in Applications IDNA: Internationalized Domain Names in Applications, a protocol
for the handling of IDNs.
DNR: Domain Name Registry DNR: Domain Name Registry
NFC: Unicode Normalization Form C NFC: Unicode Normalization Form C ([Unicode-UAX15])
NFKC: Unicode Normalization Form KC NFKC: Unicode Normalization Form KC ([Unicode-UAX15])
RDAP: Registration Data Access Protocol RDAP: Registration Data Access Protocol
REST: Representational State Transfer State Transfer. The term REST: Representational State Transfer. The term was first
was first described in a doctoral dissertation [REST]. 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] and the conventions described in [RFC7230] and the conventions described in
skipping to change at page 3, line 45 skipping to change at page 3, line 46
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.
Server implementations are free to support only a subset of these Server implementations are free to support only a subset of these
features depending on local requirements. Servers MUST return an features depending on local requirements. Servers MUST return an
HTTP 501 (Not Implemented) [RFC7231] response to inform clients of HTTP 501 (Not Implemented) [RFC7231] response to inform clients of
unsupported queries. It is also envisioned that each registry will unsupported query types. It is also envisioned that each registry
continue to maintain WHOIS and/or other RESTful web services specific will continue to maintain WHOIS and/or other RESTful web services
to their needs and those of their constituencies, and the information specific to their needs and those of their constituencies, and the
retrieved through the patterns described here may reference such information retrieved through the patterns described here may
services. 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 37 skipping to change at page 4, line 37
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. Supported have to make choices based on local criteria. Supported
authentication mechanisms are described in authentication mechanisms are described in
[I-D.ietf-weirds-rdap-sec]. [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 an 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
against, as per Section 5 of RFC 3986 [RFC3986]. For example, if the against, as per Section 5 of RFC 3986 [RFC3986]. For example, if the
base URL is "http://example.com/rdap/", all RDAP query URLs will base URL is "https://example.com/rdap/", all RDAP query URLs will
begin with "http://example.com/rdap/". begin with "https://example.com/rdap/".
The bootstrap registry does not contain information for query objects The bootstrap registry does not contain information for query objects
that are not part of a global namespace, including entities and help. that are not part of a global namespace, including entities and help.
A base URL for an associated object is required to construct a A base URL for an associated object is required to construct a
complete query. complete query.
For entities, a base URL is retrieved for the service (domain, For entities, a base URL is retrieved for the service (domain,
address, etc.) associated with a given entity. The query URL is address, etc.) associated with a given entity. The query URL is
constructed by concatenating the base URL to the entity path segment constructed by concatenating the base URL to the entity path segment
specified in either Section 3.1.5 or Section 3.2.3. specified in either Section 3.1.5 or Section 3.2.3.
For help, a base URL is retrieved for any service (domain, address, For help, a base URL is retrieved for any service (domain, address,
etc.) for which additional information is required. The query URL is etc.) for which additional information is required. The query URL is
constructed by concatenating the base URL to the help path segment constructed by concatenating the base URL to the help path segment
specified in either Section 3.1.6. specified in Section 3.1.6.
3.1. Lookup Path Segment Specification 3.1. Lookup Path Segment Specification
A simple lookup to determine if an object exists (or not) without A simple lookup 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].
The resource type path segments for exact match lookup are: The resource type path segments for exact match lookup are:
o 'ip': Used to identify IP networks and associated data referenced o 'ip': Used to identify IP networks and associated data referenced
skipping to change at page 5, line 51 skipping to change at page 5, line 51
Semantically, the simpler form using the address can be thought of as Semantically, the simpler form using the address can be thought of as
a CIDR block with a bitmask length of 32 for IPv4 and a bitmask a CIDR block with a bitmask length of 32 for IPv4 and a bitmask
length of 128 for IPv6. A given specific address or CIDR may fall length of 128 for IPv6. A given specific address or CIDR may fall
within multiple IP networks in a hierarchy of networks, therefore within multiple IP networks in a hierarchy of networks, therefore
this query targets the "most-specific" or smallest IP network which this query targets the "most-specific" or smallest IP network which
completely encompasses it in a hierarchy of IP networks. completely encompasses it in a hierarchy of IP networks.
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, compressed or not compressed. The rules to [RFC4291] can be used. This includes IPv6 addresses written using
write a text representation of an IPv6 address [RFC5952] are with or without compressed zeros, and IPv6 addresses containing
RECOMMENDED. However, the zone_id [RFC4007] is not appropriate in embedded IPv4 addresses. The rules to write a text representation of
this context and therefore the corresponding syntax extension in RFC an IPv6 address [RFC5952] are RECOMMENDED. However, the zone_id
6874 [RFC6874] MUST NOT be used. [RFC4007] is not appropriate in this context and therefore the
corresponding syntax extension in RFC 6874 [RFC6874] MUST NOT be
used, and servers are to ignore it if possible.
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:
http://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:
http://example.com/rdap/ip/192.0.2.0/24 https://example.com/rdap/ip/192.0.2.0/24
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 2001:db8::0: specific network containing 2001:db8::0:
http://example.com/rdap/ip/2001:db8::0 https://example.com/rdap/ip/2001:db8::0
3.1.2. Autonomous System Path Segment Specification 3.1.2. Autonomous System Path Segment Specification
Syntax: autnum/<autonomous system number> Syntax: autnum/<autonomous system number>
Queries for information regarding autonomous system number Queries for information regarding autonomous system number
registrations are of the form /autnum/XXX/... where XXX is an AS registrations are of the form /autnum/XXX/... where XXX is an AS
Plain autonomous system number [RFC5396]. In some registries, Plain autonomous system number [RFC5396]. In some registries,
registration of autonomous system numbers is done on an individual registration of autonomous system numbers is done on an individual
number basis, while other registries may register blocks of number basis, while other registries may register blocks of
autonomous system numbers. The semantics of this query are such that autonomous system numbers. The semantics of this query are such that
if a number falls within a range of registered blocks, the target of if a number falls within a range of registered blocks, the target of
the query is the block registration, and that individual number the query is the block registration, and that individual number
registrations are considered a block of numbers with a size of 1. registrations are considered a block of numbers with a size of 1.
For example, the following URL would be used to find information For example, the following URL would be used to find information
describing autonomous system number 12 (a number within a range of describing autonomous system number 12 (a number within a range of
registered blocks): registered blocks):
http://example.com/rdap/autnum/12 https://example.com/rdap/autnum/12
The following URL would be used to find information describing 4-byte The following URL would be used to find information describing 4-byte
autonomous system number 65538: autonomous system number 65538:
http://example.com/rdap/autnum/65538 https://example.com/rdap/autnum/65538
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
(as specified in RFC 952 [RFC0952] and RFC 1123 [RFC1123]) in either (as specified in RFC 952 [RFC0952] and RFC 1123 [RFC1123]) in either
the in-addr.arpa or ip6.arpa zones (for RIRs) or a fully-qualified the in-addr.arpa or ip6.arpa zones (for RIRs) or a fully-qualified
domain name in a zone administered by the server operator (for DNRs). domain name in a zone administered by the server operator (for DNRs).
Internationalized domain names represented in either A-label or Internationalized domain names represented in either A-label or
U-label format [RFC5890] are also valid domain names. See U-label format [RFC5890] are also valid domain names. See
Section 6.1 for information on character encoding for the U-label Section 6.1 for information on character encoding for the U-label
format. format.
IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels;
that is, all internationalized labels in an IDN SHOULD be either that is, internationalized labels in an IDN SHOULD be either all
A-labels or U-labels. It is possible for an RDAP client to assemble A-labels or all U-labels. It is possible for an RDAP client to
a query string from multiple independent data sources. Such a client assemble a query string from multiple independent data sources. Such
might not be able to perform conversions between A-labels and a client might not be able to perform conversions between A-labels
U-labels. An RDAP server that receives a query string with a mixture and U-labels. An RDAP server that receives a query string with a
of A-labels and U-labels MAY convert all the U-labels to A-labels, mixture of A-labels and U-labels MAY convert all the U-labels to
perform IDNA processing, and proceed with exact-match lookup. In A-labels, perform IDNA processing, and proceed with exact-match
such cases, the response to be returned to the query source may not lookup. In such cases, the response to be returned to the query
match the input from the query source. Alternatively, the server MAY source may not match the input from the query source. Alternatively,
refuse to process the query. the server MAY refuse to process the query.
The server MAY perform the match using either the A-label or U-label 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 form. Using one consistent form for matching every label is likely
to be more reliable. 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 https://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 https://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 https://example.com/rdap/domain/blah.example.com
The following URL would be used to find information for the The following URL would be used to find information for the
xn--fo-5ja.example IDN: xn--fo-5ja.example IDN:
http://example.com/rdap/domain/xn--fo-5ja.example https://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 host The <name server name> parameter represents a fully qualified host
name as specified in RFC 952 [RFC0952] and RFC 1123 [RFC1123]. name as 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. IDN processing format [RFC5890] are also valid name server names. IDN processing
for name server names uses the domain name processing instructions for name server names uses the domain name processing instructions
specified in Section 3.1.3. See Section 6.1 for information on specified in Section 3.1.3. See Section 6.1 for information on
character encoding for the U-label format. character encoding for the U-label format.
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 https://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 https://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 whose syntax is specific to the registrant, or registrar) identifier whose syntax is specific to the
registration provider. For example, for some DNRs contact registration provider. For example, for some DNRs contact
identifiers are specified in RFC 5730 [RFC5730] and RFC 5733 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 https://example.com/rdap/entity/XXXX
3.1.6. Help Path Segment Specification 3.1.6. Help Path Segment Specification
Syntax: help Syntax: help
The help path segment can be used to request helpful information The help path segment can be used to request helpful information
(command syntax, terms of service, privacy policy, rate limiting (command syntax, terms of service, privacy policy, rate limiting
policy, supported authentication methods, supported extensions, policy, supported authentication methods, supported extensions,
technical support contact, etc.) from an RDAP server. The response technical support contact, etc.) from an RDAP server. The response
to "help" should provide basic information that a client needs to to "help" should provide basic information that a client needs to
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 https://example.com/rdap/help
3.2. Search Path Segment Specification 3.2. Search Path Segment Specification
Pattern matching semantics are described in Section 4.1. The Pattern matching semantics are described in Section 4.1. The
resource type path segments for search are: 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.
skipping to change at page 9, line 45 skipping to change at page 9, line 45
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:
/domains?name=XXXX domains?name=XXXX
XXXX is a search pattern representing a domain name in "letters, XXXX is a search pattern representing a domain name in "letters,
digits, hyphen" format [RFC5890] in a zone administered by the server digits, hyphen" format [RFC5890] in a zone administered by the server
operator of a DNR. The following URL would be used to find DNR operator of a DNR. The following URL would be used to find DNR
information for domain names matching the "example*.com" pattern: information for domain names matching the "example*.com" pattern:
http://example.com/rdap/domains?name=example*.com https://example.com/rdap/domains?name=example*.com
Internationalized Domain Names (IDNs) in U-label format [RFC5890] can Internationalized Domain Names (IDNs) in U-label format [RFC5890] can
also be used as search patterns (see Section 4). Searches for these also be used as search patterns (see Section 4). Searches for these
names are of the form /domains?name=XXXX, where XXXX is a search names are of the form /domains?name=XXXX, where XXXX is a search
pattern representing a domain name in U-label format [RFC5890]. See pattern representing a domain name in U-label format [RFC5890]. See
Section 6.1 for information on character encoding for the U-label Section 6.1 for information on character encoding for the U-label
format. format.
Searches for domain information by name server name are specified Searches for domain information by name server name are specified
using this form: using this form:
/domains?nsLdhName=YYYY domains?nsLdhName=YYYY
YYYY is a search pattern representing a host name in "letters, YYYY is a search pattern representing a host name in "letters,
digits, hyphen" format [RFC5890] in a zone administered by the server digits, hyphen" format [RFC5890] in a zone administered by the server
operator of a DNR. The following URL would be used to search for operator of a DNR. The following URL would be used to search for
domains delegated to name servers matching the "ns1.example*.com" domains delegated to name servers matching the "ns1.example*.com"
pattern: pattern:
http://example.com/rdap/domains?nsLdhName=ns1.example*.com https://example.com/rdap/domains?nsLdhName=ns1.example*.com
Searches for domain information by name server IP address are Searches for domain information by name server IP address are
specified using this form: specified using this form:
/domains?nsIp=ZZZZ domains?nsIp=ZZZZ
ZZZZ is a search pattern representing an IPv4 [RFC1166] or IPv6 ZZZZ is a search pattern representing an IPv4 [RFC1166] or IPv6
[RFC5952] address. The following URL would be used to search for [RFC5952] address. The following URL would be used to search for
domains that have been delegated to name servers that resolve to the domains that have been delegated to name servers that resolve to the
"192.0.2.0" address: "192.0.2.0" address:
http://example.com/rdap/domains?nsIp=192.0.2.0 https://example.com/rdap/domains?nsIp=192.0.2.0
3.2.2. Name Server Search 3.2.2. Name Server Search
Syntax: nameservers?name=<name server search pattern> Syntax: nameservers?name=<name server search pattern>
Syntax: nameservers?ip=<name server search pattern> Syntax: nameservers?ip=<name server search pattern>
Searches for name server information by name server name are Searches for name server information by name server name are
specified using this form: specified using this form:
/nameservers?name=XXXX nameservers?name=XXXX
XXXX is a search pattern representing a host name in "letters, XXXX is a search pattern representing a host name in "letters,
digits, hyphen" format [RFC5890] in a zone administered by the server digits, hyphen" format [RFC5890] in a zone administered by the server
operator of a DNR. The following URL would be used to find DNR operator of a DNR. The following URL would be used to find DNR
information for name server names matching the "ns1.example*.com" information for name server names matching the "ns1.example*.com"
pattern: pattern:
http://example.com/rdap/nameservers?name=ns1.example*.com https://example.com/rdap/nameservers?name=ns1.example*.com
Internationalized name server names in U-label format [RFC5890] can Internationalized name server names in U-label format [RFC5890] can
also be used as search patterns (see Section 4). Searches for these also be used as search patterns (see Section 4). Searches for these
names are of the form /nameservers?name=XXXX, where XXXX is a search names are of the form /nameservers?name=XXXX, where XXXX is a search
pattern representing a name server name in U-label format [RFC5890]. pattern representing a name server name in U-label format [RFC5890].
See Section 6.1 for information on character encoding for the U-label See Section 6.1 for information on character encoding for the U-label
format. format.
Searches for name server information by name server IP address are Searches for name server information by name server IP address are
specified using this form: specified using this form:
/nameservers?ip=YYYY nameservers?ip=YYYY
YYYY is a search pattern representing an IPv4 [RFC1166] or IPv6 YYYY is a search pattern representing an IPv4 [RFC1166] or IPv6
[RFC5952] address. The following URL would be used to search for [RFC5952] address. The following URL would be used to search for
name server names that resolve to the "192.0.2.0" address: name server names that resolve to the "192.0.2.0" address:
http://example.com/rdap/nameservers?ip=192.0.2.0 https://example.com/rdap/nameservers?ip=192.0.2.0
3.2.3. Entity Search 3.2.3. Entity Search
Syntax: entities?fn=<entity name search pattern> Syntax: entities?fn=<entity name search pattern>
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
where XXXX is a search pattern representing an entity name as where XXXX is a search pattern representing the "FN" property of an
specified in Section 6.1 of [I-D.ietf-weirds-json-response]. The entity (such as a contact, registrant, or registrar) name as
specified in Section 5.1 of [I-D.ietf-weirds-json-response]. The
following URL would be used to find information for entity names following URL would be used to find information for entity names
matching the "Bobby Joe*" pattern. matching the "Bobby Joe*" pattern:
http://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
where XXXX is a search pattern representing an entity (such as a
where XXXX is a search pattern representing an entity handle as contact, registrant, or registrar) identifier whose syntax is
specified in Section 6.1 of [I-D.ietf-weirds-json-response]. The specific to the registration provider. The following URL would be
following URL would be used to find information for entity names used to find information for entity handles matching the "CID-40*"
matching the "CID-40*" pattern. pattern:
http://example.com/rdap/entities?handle=CID-40* https://example.com/rdap/entities?handle=CID-40*
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].
skipping to change at page 12, line 42 skipping to change at page 12, line 45
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 7 of return an error response body as specified in Section 7 of
[I-D.ietf-weirds-json-response] if the requested media type is one [I-D.ietf-weirds-json-response] if the requested media type is one
that is specified in [I-D.ietf-weirds-using-http]. that is specified in [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 each
Unicode character or characters. Servers SHOULD NOT partially match other. Servers SHOULD NOT partially match combinations of Unicode
combinations of Unicode characters where a Unicode character may be characters where a legal combination is possible. It should be
legally combined with another Unicode character or characters. It noted, though, that it may not always be possible to detect cases
should be noted, though, that it may not always be possible to detect where a character could have been combined with another character,
possible cases where a character could have been combined with but was not, because characters can be combined in many different
another character, but was not, because of the way combining ways.
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
skipping to change at page 13, line 41 skipping to change at page 13, line 41
that has been filtered by whatever policies are in place. that has been filtered by whatever policies are in place.
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
lookup, including additional names that match a relatively fuzzy lookup, including additional names that match a relatively fuzzy
search as well as lists of names that are linked together, may cause search as well as lists of names that are linked together, may cause
privacy issues. privacy issues.
Note that there might not be a single, static information return
policy that applies to all clients equally. Client identity and
associated authorizations can be a relevant factor in determining how
broad the response set will be for any particular query.
5. Extensibility 5. Extensibility
This document describes path segment specifications for a limited This document describes path segment specifications for a limited
number of objects commonly registered in both RIRs and DNRs. It does number of objects commonly registered in both RIRs and DNRs. It does
not attempt to describe path segments for all of the objects not attempt to describe path segments for all of the objects
registered in all registries. Custom path segments can be created registered in all registries. Custom path segments can be created
for objects not specified here using the process described in for objects not specified here using the process described in
Section 6 of "HTTP usage in the Registration Data Access Protocol Section 6 of "HTTP usage in the Registration Data Access Protocol
(RDAP)" [I-D.ietf-weirds-using-http]. (RDAP)" [I-D.ietf-weirds-using-http].
skipping to change at page 16, line 8 skipping to change at page 16, line 14
Search functionality also increases the privacy risk of disclosing Search functionality also increases the privacy risk of disclosing
object relationships that might not otherwise be obvious. For object relationships that might not otherwise be obvious. For
example, a search that returns IDN variants [RFC6927] that do not example, a search that returns IDN variants [RFC6927] that do not
explicitly match a client-provided search pattern can disclose explicitly match a client-provided search pattern can disclose
information about registered domain names that might not be otherwise information about registered domain names that might not be otherwise
available. Implementers need to consider the policy and privacy available. Implementers need to consider the policy and privacy
implications of returning information that was not explicitly implications of returning information that was not explicitly
requested. requested.
Note that there might not be a single, static information return
policy that applies to all clients equally. Client identity and
associated authorizations can be a relevant factor in determining how
broad the response set will be for any particular query.
9. Acknowledgements 9. Acknowledgements
This document is derived from original work on RIR query formats This document is derived from original work on RIR query formats
developed by Byron J. Ellacott of APNIC, Arturo L. Servin of developed by Byron J. Ellacott of APNIC, Arturo L. Servin of
LACNIC, Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN. LACNIC, Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN.
Additionally, this document incorporates DNR query formats originally Additionally, this document incorporates DNR query formats originally
described by Francisco Arias and Steve Sheng of ICANN and Scott described by Francisco Arias and Steve Sheng of ICANN and Scott
Hollenbeck of Verisign Labs. Hollenbeck of Verisign Labs.
The authors would like to acknowledge the following individuals for The authors would like to acknowledge the following individuals for
their contributions to this document: Francisco Arias, Marc Blanchet, their contributions to this document: Francisco Arias, Marc Blanchet,
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., "Finding the Authoritative Registration Data Blanchet, M., "Finding the Authoritative Registration Data
(RDAP) Service", draft-ietf-weirds-bootstrap-09 (work in (RDAP) Service", draft-ietf-weirds-bootstrap-11 (work in
progress), October 2014. progress), December 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-10 (work in progress), October 2014. weirds-json-response-13 (work in progress), December 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-09 (work in progress), September 2014. rdap-sec-12 (work in progress), December 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-13 (work in progress), October 2014. weirds-using-http-15 (work in progress), November 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 19, line 36 skipping to change at page 20, line 4
-11: Replaced reference to RFC 4627 with reference to RFC 7159. -11: Replaced reference to RFC 4627 with reference to RFC 7159.
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. -14: Address WG last call comments.
-15: Address AD review comments. -15: Address AD review comments.
-16: Address IETF last call comments. -16: Address IETF last call comments.
-17: Address IESG review 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. 51 change blocks. 
83 lines changed or deleted 98 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/