draft-ietf-weirds-rdap-query-04.txt   draft-ietf-weirds-rdap-query-05.txt 
Network Working Group A.L. 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: October 03, 2013 Verisign Labs Expires: December 14, 2013 Verisign Labs
April 01, 2013 June 12, 2013
Registration Data Access Protocol Lookup Format Registration Data Access Protocol Lookup Format
draft-ietf-weirds-rdap-query-04 draft-ietf-weirds-rdap-query-05
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.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 October 03, 2013. This Internet-Draft will expire on December 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Path Segment Specification . . . . . . . . . . . . . . . . . 4 3. Path Segment Specification . . . . . . . . . . . . . . . . . 4
3.1. IP Network Path Segment Specification . . . . . . . . . . 4 3.1. IP Network Path Segment Specification . . . . . . . . . . 4
3.2. Autonomous System Path Segment Specification . . . . . . 5 3.2. Autonomous System Path Segment Specification . . . . . . 5
3.3. Domain Path Segment Specification . . . . . . . . . . . . 6 3.3. Domain Path Segment Specification . . . . . . . . . . . . 6
3.4. Name Server Path Segment Specification . . . . . . . . . 6 3.4. Name Server Path Segment Specification . . . . . . . . . 6
3.5. Entity Path Segment Specification . . . . . . . . . . . . 7 3.5. Entity Path Segment Specification . . . . . . . . . . . . 7
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Help Path Segment Specification . . . . . . . . . . . . . 7
5. Internationalization Considerations . . . . . . . . . . . . . 7 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Internationalization Considerations . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Path Segment Specification for Search Queries . . . 10 Appendix A. Path Segment Specification for Search Queries . . . 11
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 4, line 18 skipping to change at page 4, line 18
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. Specified
authentication mechanisms MUST use HTTP. authentication mechanisms MUST use HTTP.
3. Path Segment Specification 3. Path Segment Specification
The uniform patterns start with a base URL [RFC3986] specified by The uniform patterns start with a base URL [RFC3986] specified by
each registry or any other service provider offering this service. each registry or any other service provider offering this service.
The base URL is followed by a resource-type-specific path segment. The base URL is followed by a resource-type-specific path segment.
The base URL may contain its own path segments (e.g. http:// The base URL may contain its own path segments (e.g. http://
example.com/... or http://example.com/restful-WHOIS/... ). The example.com/... or http://example.com/restful-WHOIS/... ). The
characters used to form a path segment are limited to those that can characters used to form a path segment are limited to those that can
be used to form a URI as specified in RFC 3986 [RFC3986]. be used to form a URI as specified in RFC 3986 [RFC3986].
The resource type path segments are: The resource type path segments are:
o 'ip': IP networks and associated data referenced using either an o 'ip': IP networks and associated data referenced using either an
IPv4 or IPv6 address. IPv4 or IPv6 address.
o 'autnum': Autonomous system registrations and associated data o 'autnum': Autonomous system registrations and associated data
referenced using an AS Plain autonomous system number. referenced using an AS Plain autonomous system number.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
associated data referenced using a fully-qualified domain name. associated data referenced using a fully-qualified domain name.
o 'nameserver': Used to identify a name server information query. o 'nameserver': Used to identify a name server information query.
o 'entity': Used to identify an entity information query. o 'entity': Used to identify an entity information query.
3.1. IP Network Path Segment Specification 3.1. IP Network Path Segment Specification
Syntax: ip/<IP address> or ip/<CIDR prefix>/<CIDR length> Syntax: ip/<IP address> or ip/<CIDR prefix>/<CIDR length>
Queries for information about IP networks are of the form /ip/XXX/... Queries for information about IP networks are of the form /ip/XXX/...
or /ip/XXX/YY/... where the path segment following 'ip' is either an or /ip/XXX/YY/... where the path segment following 'ip' is either an
IPv4 [RFC1166] or IPv6 [RFC5952] address (i.e. XXX) or an IPv4 or IPv4 [RFC1166] or IPv6 [RFC5952] address (i.e. XXX) or an IPv4 or
IPv6 CIDR [RFC4632] notation address block (i.e. XXX/YY). IPv6 CIDR [RFC4632] notation address block (i.e. XXX/YY).
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 [RFC3986], as IPv4address and described in section 3.2.2 of [RFC3986], as IPv4address and
IPv6address ABNF definitions. Any valid IPv6 text address format IPv6address ABNF definitions. Any valid IPv6 text address format
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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. For example, for some DNRs
contact identifiers are specified in RFC 5730 [RFC5730] and RFC 5733 contact identifiers are specified in RFC 5730 [RFC5730] and RFC 5733
[RFC5733]. [RFC5733].
The following path would be used to find information for the entity The following path would be used to find information for the entity
associated with handle CID-4005: associated with handle CID-4005:
/entity/CID-4005 /entity/CID-4005
3.6. Help Path Segment Specification
Syntax: help
The help path segment can be used to request helpful information
(command syntax, terms of service, privacy policy, rate limiting
policy, supported authentication methods, supported extensions,
technical support contact, etc.) from an RDAP server. The response
to "help" should provide basic information that a client needs to
successfully use the service. The following path would be used to
return "help" information:
/help
4. Extensibility 4. 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 TBD of "Using HTTP for RESTful Whois Services by Internet Section TBD of "Using HTTP for RESTful Whois Services by Internet
Registries" [I-D.ietf-weirds-using-http]. Registries" [I-D.ietf-weirds-using-http].
skipping to change at page 8, line 28 skipping to change at page 8, line 48
Access Protocol" [I-D.ietf-weirds-json-response]. Access Protocol" [I-D.ietf-weirds-json-response].
6. IANA Considerations 6. IANA Considerations
This document does not specify any IANA actions. This document does not specify any IANA actions.
7. Security Considerations 7. Security Considerations
Security services for the operations specified in this document are Security services for the operations specified in this document are
described in "Security Services for the Registration Data Access described in "Security Services for the Registration Data Access
Protocol" [I-D.ietf-weirds-rdap-sec]. As we identify specific use Protocol" [I-D.ietf-weirds-rdap-sec].
cases for which security services are needed they will be described
here.
8. Acknowledgements 8. 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,
LACNIC, Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN. 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. Hollenbeck of Verisign.
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,
Jean-Philippe Dionne, Behnam Esfahbod, Edward Lewis, and John Levine. Ernie Dainow, Jean-Philippe Dionne, Behnam Esfahbod, Edward Lewis,
and John Levine.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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-02 (work in progress), January 2013. weirds-json-response-04 (work in progress), June 2013.
[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-01 (work in progress), November 2012. rdap-sec-04 (work in progress), June 2013.
[I-D.ietf-weirds-using-http] [I-D.ietf-weirds-using-http]
Newton, A., Ellacott, B., and N. Kong, "Using the Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the
Registration Data Access Protocol (RDAP) with HTTP", Registration Data Access Protocol (RDAP)", draft-ietf-
draft-ietf-weirds-using-http-03 (work in progress), March weirds-using-http-05 (work in progress), May 2013.
2013.
[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.
[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.
[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet
numbers", RFC 1166, July 1990. numbers", RFC 1166, July 1990.
skipping to change at page 11, line 11 skipping to change at page 11, line 27
on more basic protocol operations. Once we understand how exact- on more basic protocol operations. Once we understand how exact-
match queries will work we will attempt to define specifications for match queries will work we will attempt to define specifications for
search queries in other documents. search queries in other documents.
It is important to note that there are already multiple It is important to note that there are already multiple
implementations of RESTful RDAP-like prototypes that provide search implementations of RESTful RDAP-like prototypes that provide search
capabilities. For example: capabilities. For example:
ARIN: The American Registry for Internet Numbers (ARIN) has ARIN: The American Registry for Internet Numbers (ARIN) has
published an API [1] (see Section 4.4.2) that describes using published an API [1] (see Section 4.4.2) that describes using
plural forms of path segment identifiers (e.g. "domains") and plural forms of path segment identifiers (e.g. "domains") and
Matrix URIs [2] to indicate that a client is requesting a list of Matrix URIs [2] to indicate that a client is requesting a list of
values when searching for RIR registration data. A prototype values when searching for RIR registration data. A prototype
service [3] that implements this API is up and running. service [3] that implements this API is up and running.
Verisign: Verisign has deployed a prototype service [4] that Verisign: Verisign has deployed a prototype service [4] that
implements searches for DNR registration data using HTML query implements searches for DNR registration data using HTML query
strings (e.g. "?_PRE") to identify search parameters. For strings (e.g. "?_PRE") to identify search parameters. For
example, "http://dnrd.verisignlabs.com/dnrd-ap/domain/ example, "http://dnrd.verisignlabs.com/dnrd-ap/domain/
verisign?_PRE" performs a search for domain names with a verisign?_PRE" performs a search for domain names with a
"verisign" prefix. "verisign" prefix.
Appendix B. Change Log Appendix B. Change Log
Initial -00: Adopted as working group document. Initial -00: Adopted as working group document.
-01: Added "Conventions Used in This Document" section. Added -01: Added "Conventions Used in This Document" section. Added
normative reference to draft-ietf-weirds-rdap-sec and some normative reference to draft-ietf-weirds-rdap-sec and some
wrapping text in the Security Considerations section. wrapping text in the Security Considerations section.
skipping to change at page 11, line 48 skipping to change at page 12, line 15
extensibility. extensibility.
-03: Changed 'query' to 'lookup' in document title to better -03: Changed 'query' to 'lookup' in document title to better
describe the 'exact match lookup' purpose of this document. describe the 'exact match lookup' purpose of this document.
Included a multitude of minor additions and clarifications Included a multitude of minor additions and clarifications
provided by Marc Blanchet and Jean-Philippe Dionne. Modified the provided by Marc Blanchet and Jean-Philippe Dionne. Modified the
domain and name server sections to include support for IDN domain and name server sections to include support for IDN
U-labels. U-labels.
-04: Updated the domain and name server sections to use .example IDN -04: Updated the domain and name server sections to use .example IDN
U-labels. Added text to note that mixed IDN labels SHOULD NOT be U-labels. Added text to note that mixed IDN labels SHOULD NOT be
used. Fixed broken sentences in Section 5. used. Fixed broken sentences in Section 5.
-05: Added "help" path segment.
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
URI: http://www.arin.net URI: http://www.arin.net
Scott Hollenbeck Scott Hollenbeck
 End of changes. 23 change blocks. 
28 lines changed or deleted 43 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/