draft-ietf-weirds-rdap-query-03.txt   draft-ietf-weirds-rdap-query-04.txt 
Network Working Group A.L. Newton Network Working Group A.L. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track S. Hollenbeck Intended status: Standards Track S. Hollenbeck
Expires: September 15, 2013 Verisign Labs Expires: October 03, 2013 Verisign Labs
March 14, 2013 April 01, 2013
Registration Data Access Protocol Lookup Format Registration Data Access Protocol Lookup Format
draft-ietf-weirds-rdap-query-03 draft-ietf-weirds-rdap-query-04
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 September 15, 2013. This Internet-Draft will expire on October 03, 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 22 skipping to change at page 2, line 22
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 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Internationalization Considerations . . . . . . . . . . . . . 7 5. Internationalization Considerations . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 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 . . . 10
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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].
skipping to change at page 6, line 14 skipping to change at page 6, line 14
3.3. Domain Path Segment Specification 3.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 domain name [RFC4343] in either the where XXXX is a fully-qualified domain name [RFC4343] in either the
in-addr.arpa or ip6.arpa zones (for RIRs) or a fully-qualified domain 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). 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. U-label format [RFC5890] are also valid domain names. IDN labels
SHOULD NOT be represented as a mixture of A-labels and U-labels.
If the client sends the server an IDN U-label, servers that support If the client sends the server an IDN in U-label format, servers that
IDNs MUST convert the IDN into A-label format and perform IDNA support IDNs MUST convert the IDN into A-label format and perform
processing as specified in RFC 5891 [RFC5891]. The server should IDNA processing as specified in RFC 5891 [RFC5891]. The server
perform an exact match lookup using the A-label. should perform an exact match lookup using the A-label.
The following path would be used to find information describing the The following path would be used to find information describing the
zone serving the network 192.0.2/24: zone serving the network 192.0.2/24:
/domain/2.0.192.in-addr.arpa /domain/2.0.192.in-addr.arpa
The following path would be used to find information describing the The following path would be used to find information describing the
zone serving the network 2001:db8:1::/48: zone serving the network 2001:db8:1::/48:
/domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa /domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
The following path would be used to find information for the The following path would be used to find information for the
example.com domain name: example.com domain name:
/domain/example.com /domain/example.com
The following path would be used to find information for the
xn--xemple-9ua.example IDN:
/domain/xn--xemple-9ua.example
3.4. Name Server Path Segment Specification 3.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. format [RFC5890] are also valid name server names. IDN labels SHOULD
NOT be represented as a mixture of A-labels and U-labels.
If the client sends the server an IDN U-label, servers that support If the client sends the server an IDN in U-label format, servers that
IDNs MUST convert the IDN into A-label format and perform IDNA support IDNs MUST convert the IDN into A-label format and perform
processing as specified in RFC 5891 [RFC5891]. The server should IDNA processing as specified in RFC 5891 [RFC5891]. The server
perform an exact match lookup using the A-label. should perform an exact match lookup using the A-label.
The following path would be used to find information for the The following path would be used to find information for the
ns1.example.com name server: ns1.example.com name server:
/nameserver/ns1.example.com /nameserver/ns1.example.com
The following path would be used to find information for the IDN The following path would be used to find information for the
ns1.xn--xemple-9ua.com name server: ns1.xn--xemple-9ua.example name server:
/nameserver/ns1.xn--xemple-9ua.com /nameserver/ns1.xn--xemple-9ua.example
3.5. Entity Path Segment Specification 3.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. 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].
skipping to change at page 7, line 44 skipping to change at page 8, line 4
Registries" [I-D.ietf-weirds-using-http]. Registries" [I-D.ietf-weirds-using-http].
Custom path segments can be created by prefixing the segment with a Custom path segments can be created by prefixing the segment with a
unique identifier followed by an underscore character (0x5F). For unique identifier followed by an underscore character (0x5F). For
example, a custom entity path segment could be created by prefixing example, a custom entity path segment could be created by prefixing
"entity" with "custom_", producing "custom_entity". Servers MUST "entity" with "custom_", producing "custom_entity". Servers MUST
return an appropriate failure status code for a request with an return an appropriate failure status code for a request with an
unrecognized path segment. unrecognized path segment.
5. Internationalization Considerations 5. Internationalization Considerations
There is value in supporting the ability to submit either a U-label There is value in supporting the ability to submit either a U-label
(Unicode form of an IDN label) or an A-label (ASCII form of an IDN (Unicode form of an IDN label) or an A-label (ASCII form of an IDN
label) as a query argument to an RDAP service. Clients capable of label) as a query argument to an RDAP service. Clients capable of
processing non-ASCII characters may prefer a U-label since this is processing non-ASCII characters may prefer a U-label since this is
more visually recognizable and familiar than A-label strings, but more visually recognizable and familiar than A-label strings, but
clients of programmatic interfaces may wish to submit and display clients using programmatic interfaces might find it easier to submit
A-labels or may not be able to input U-labels with their keyboard and display A-labels if they are unable to input U-labels with their
configuration. . keyboard configuration. Both query forms are acceptable.
Internationalized domain and name server names can contain character Internationalized domain and name server names can contain character
variants and variant labels as described in RFC 4290 [RFC4290]. variants and variant labels as described in RFC 4290 [RFC4290].
Clients that support queries for internationalized domain and name Clients that support queries for internationalized domain and name
server names MUST accept service provider responses that describe server names MUST accept service provider responses that describe
variants as specified in "JSON Responses for the Registration Data variants as specified in "JSON Responses for the Registration Data
Access Protocol" [I-D.ietf-weirds-json-response]. Access Protocol" [I-D.ietf-weirds-json-response].
6. IANA Considerations 6. IANA Considerations
skipping to change at page 8, line 35 skipping to change at page 8, line 43
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. 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, Edward Lewis, and John Levine. 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-02 (work in progress), January 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-
skipping to change at page 9, line 6 skipping to change at page 9, line 19
weirds-json-response-02 (work in progress), January 2013. weirds-json-response-02 (work in progress), January 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-01 (work in progress), November 2012.
[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, "Using the
Registration Data Access Protocol (RDAP) with HTTP", Registration Data Access Protocol (RDAP) with HTTP",
draft-ietf-weirds-using-http-01 (work in progress), draft-ietf-weirds-using-http-03 (work in progress), March
December 2012. 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 10, line 38 skipping to change at page 10, line 51
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
Appendix A. Path Segment Specification for Search Queries Appendix A. Path Segment Specification for Search Queries
All of the path segments described in this document identify patterns All of the path segments described in this document identify patterns
for exact-match lookups of data elements. We have explicitly omitted for exact-match lookups of data elements. We have explicitly omitted
specifications for search queries in the interest of first focusing specifications for search queries in the interest of first focusing
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. 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
skipping to change at page 11, line 31 skipping to change at page 11, line 45
Changed the last sentence in section 4 to more clearly specify Changed the last sentence in section 4 to more clearly specify
error response behavior. Added acknowledgements. Added a error response behavior. Added acknowledgements. Added a
paragraph in the introduction regarding future IETF standards and paragraph in the introduction regarding future IETF standards and
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
U-labels. Added text to note that mixed IDN labels SHOULD NOT be
used. Fixed broken sentences in Section 5.
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. 19 change blocks. 
28 lines changed or deleted 35 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/