draft-ietf-weirds-using-http-10.txt   draft-ietf-weirds-using-http-11.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track B. Ellacott Intended status: Standards Track B. Ellacott
Expires: February 23, 2015 APNIC Expires: March 8, 2015 APNIC
N. Kong N. Kong
CNNIC CNNIC
August 22, 2014 September 4, 2014
HTTP usage in the Registration Data Access Protocol (RDAP) HTTP usage in the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-using-http-10 draft-ietf-weirds-using-http-11
Abstract Abstract
This document is one of a collection that together describe the This document is one of a collection that together describe the
Registration Data Access Protocol (RDAP). It describes how RDAP is Registration Data Access Protocol (RDAP). It describes how RDAP is
transported using the Hypertext Transfer Protocol (HTTP). RDAP is a transported using the Hypertext Transfer Protocol (HTTP). RDAP is a
successor protocol to the very old WHOIS protocol. successor protocol to the very old WHOIS protocol.
Status of This Memo Status of This Memo
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 February 23, 2015. This Internet-Draft will expire on March 8, 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 4, line 42 skipping to change at page 4, line 42
First, each query is meant to return either zero or one result. With First, each query is meant to return either zero or one result. With
the maximum upper bound being set to one, the issuance of redirects the maximum upper bound being set to one, the issuance of redirects
is simplified to the traditional query/response model used by HTTP is simplified to the traditional query/response model used by HTTP
[RFC7230]. Should an entity contain more than one result, some of [RFC7230]. Should an entity contain more than one result, some of
which are better served by other servers, the redirection model which are better served by other servers, the redirection model
becomes much more complicated. becomes much more complicated.
Second, the semantics of the request/response allow for future and/or Second, the semantics of the request/response allow for future and/or
non-standard response formats. In this document, only a JSON non-standard response formats. In this document, only a JSON
[RFC4627] response media type is noted, with the response contents to [RFC7159] response media type is noted, with the response contents to
be described separately (see [I-D.ietf-weirds-json-response]). This be described separately (see [I-D.ietf-weirds-json-response]). This
document only describes how RDAP is transported using HTTP with this document only describes how RDAP is transported using HTTP with this
format. format.
Third, this protocol is intended to be able to make use of the range Third, this protocol is intended to be able to make use of the range
of mechanisms available for use with HTTP. HTTP offers a number of of mechanisms available for use with HTTP. HTTP offers a number of
mechanisms not described further in this document. Operators are mechanisms not described further in this document. Operators are
able to make use of these mechanisms according to their local policy, able to make use of these mechanisms according to their local policy,
including cache control, authorization, compression, and redirection. including cache control, authorization, compression, and redirection.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
Access-Control-Allow-Origin header field, as specified by Access-Control-Allow-Origin header field, as specified by
[W3C.CR-cors-20130129]. As the use of RDAP is for public resources, [W3C.CR-cors-20130129]. As the use of RDAP is for public resources,
a value of "*" is suitable for most cases. a value of "*" is suitable for most cases.
This header (often called the CORS header), helps in-browser web This header (often called the CORS header), helps in-browser web
applications by lifting the "same-origin" restriction. applications by lifting the "same-origin" restriction.
6. Extensibility 6. Extensibility
For extensibility purposes, this document defines an IANA registry For extensibility purposes, this document defines an IANA registry
for prefixes used in JSON [RFC4627] data serialization and URI path for prefixes used in JSON [RFC7159] data serialization and URI path
segments (see Section 8). segments (see Section 8).
Prefixes and identifiers SHOULD only consist of the alphabetic ASCII Prefixes and identifiers SHOULD only consist of the alphabetic ASCII
characters A through Z in both uppercase and lowercase, the numerical characters A through Z in both uppercase and lowercase, the numerical
digits 0 through 9, underscore characters, and SHOULD NOT begin with digits 0 through 9, underscore characters, and SHOULD NOT begin with
an underscore character, numerical digit or the characters "xml". an underscore character, numerical digit or the characters "xml".
The following describes the production of JSON names in ABNF The following describes the production of JSON names in ABNF
[RFC5234]. [RFC5234].
ABNF for JSON names ABNF for JSON names
skipping to change at page 8, line 13 skipping to change at page 8, line 13
purposes. First, client implementers using modern programming purposes. First, client implementers using modern programming
languages such as Ruby or Java can use libraries that automatically languages such as Ruby or Java can use libraries that automatically
promote JSON names to first order object attributes or members. promote JSON names to first order object attributes or members.
Second, a clean mapping between JSON and XML is easy to accomplish Second, a clean mapping between JSON and XML is easy to accomplish
using these rules. using these rules.
7. Security Considerations 7. Security Considerations
This document does not pose strong security requirements to the RDAP This document does not pose strong security requirements to the RDAP
protocol. However, it does not restrict against the use of security protocol. However, it does not restrict against the use of security
mechanisms offered by the HTTP protocol. mechanisms offered by the HTTP protocol. It does require the RDAP
clients MUST support HTTPS.
This document made recommendations for server implementations against This document made recommendations for server implementations against
denial-of-service (Section 5.5) and interoperability with existing denial-of-service (Section 5.5) and interoperability with existing
security mechanism in HTTP clients (Section 5.6). security mechanism in HTTP clients (Section 5.6).
Additional security considerations to the RDAP protocol are covered Additional security considerations to the RDAP protocol are covered
in [I-D.ietf-weirds-rdap-sec]. in [I-D.ietf-weirds-rdap-sec].
8. IANA Considerations 8. IANA Considerations
skipping to change at page 10, line 34 skipping to change at page 10, line 36
11.1. Normative References 11.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-08 (work in progress), August 2014. weirds-json-response-08 (work in progress), August 2014.
[I-D.ietf-weirds-rdap-query] [I-D.ietf-weirds-rdap-query]
Newton, A. and S. Hollenbeck, "Registration Data Access Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol Query Format", draft-ietf-weirds-rdap-query-11 Protocol Query Format", draft-ietf-weirds-rdap-query-13
(work in progress), July 2014. (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-07 (work in progress), August 2014. rdap-sec-08 (work in progress), August 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
skipping to change at page 11, line 26 skipping to change at page 11, line 29
Kesteren, A., "Cross-Origin Resource Sharing", World Wide Kesteren, A., "Cross-Origin Resource Sharing", World Wide
Web Consortium Candidate Recommendation CR-cors-20130129, Web Consortium Candidate Recommendation CR-cors-20130129,
January 2013, January 2013,
<http://www.w3.org/TR/2013/CR-cors-20130129>. <http://www.w3.org/TR/2013/CR-cors-20130129>.
11.2. Informative References 11.2. Informative References
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004. September 2004.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS [SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS
Terminology and Structure", September 2011. Terminology and Structure", September 2011.
Appendix A. Protocol Example Appendix A. Protocol Example
To demonstrate typical behaviour of an RDAP client and server, the To demonstrate typical behaviour of an RDAP client and server, the
following is an example of an exchange, including a redirect. The following is an example of an exchange, including a redirect. The
data in the response has been elided for brevity, as the data format data in the response has been elided for brevity, as the data format
is not described in this document. The media type used here is is not described in this document. The media type used here is
described in [I-D.ietf-weirds-json-response]. described in [I-D.ietf-weirds-json-response].
skipping to change at page 16, line 5 skipping to change at page 15, line 49
* Added further references to draft-ietf-weirds-rdap-query and * Added further references to draft-ietf-weirds-rdap-query and
draft-ietf-weirds-json-response (comment by Stephen Farrell) draft-ietf-weirds-json-response (comment by Stephen Farrell)
* Added comment regarding the use of the CORS header (comment by * Added comment regarding the use of the CORS header (comment by
Stephen Farrell) Stephen Farrell)
* Explanded SSAC (comment by Sean Turner) * Explanded SSAC (comment by Sean Turner)
* Added text about HEAD and GET. * Added text about HEAD and GET.
-11
* Changed JSON reference to RFC 7159.
* Noted that clients MUST support HTTPS.
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
 End of changes. 12 change blocks. 
13 lines changed or deleted 20 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/