draft-ietf-weirds-using-http-02.txt   draft-ietf-weirds-using-http-03.txt 
Network Working Group A.L. Newton Network Working Group A.L. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track B.J. Ellacott Intended status: Standards Track B.J. Ellacott
Expires: September 26, 2013 APNIC Expires: September 28, 2013 APNIC
N. Kong N. Kong
CNNIC CNNIC
March 25, 2013 March 27, 2013
Using the Registration Data Access Protocol (RDAP) with HTTP Using the Registration Data Access Protocol (RDAP) with HTTP
draft-ietf-weirds-using-http-02 draft-ietf-weirds-using-http-03
Abstract Abstract
This document describes the usage of the Registration Data Access This document describes the usage of the Registration Data Access
Protocol (RDAP) using HTTP. Protocol (RDAP) using HTTP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 26, 2013. This Internet-Draft will expire on September 28, 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 5, line 41 skipping to change at page 5, line 41
Some servers apply rate limits to deter address scraping and other Some servers apply rate limits to deter address scraping and other
abuses. When a server declines to answer a query due to rate limits, abuses. When a server declines to answer a query due to rate limits,
it MAY return a 429 response code as described in [RFC6585]. A it MAY return a 429 response code as described in [RFC6585]. A
client that receives a 429 response SHOULD decrease its query rate, client that receives a 429 response SHOULD decrease its query rate,
and honor the Retry-After header if one is present. and honor the Retry-After header if one is present.
Note that this is not a defense against denial-of-service attacks, Note that this is not a defense against denial-of-service attacks,
since a malicious client could ignore the code and continue to send since a malicious client could ignore the code and continue to send
queries at a high rate. queries at a high rate.
5.6. Cross-Origin Resource Sharing
When responding to queries, it is RECOMMENDED that servers use the
Access-Control-Allow-Origin header, as specified by
[W3C.WD-cors-20130129].
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 [RFC4627] data serialization and URI path
segments (see Section 7). segments (see Section 7).
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".
skipping to change at page 8, line 35 skipping to change at page 8, line 38
data in character sets other than ASCII and languages other than data in character sets other than ASCII and languages other than
English (the data format will most likely be in Unicode and almost English (the data format will most likely be in Unicode and almost
certainly languages other than English will be encountered). Under certainly languages other than English will be encountered). Under
most scenarios, clients requesting data will not signal that the data most scenarios, clients requesting data will not signal that the data
be returned in a particular language or script. On the other hand, be returned in a particular language or script. On the other hand,
when servers return data and have knowledge that the data is in a when servers return data and have knowledge that the data is in a
language or script, the data should be annotated with language language or script, the data should be annotated with language
identifiers thus allowing clients to process and display the data identifiers thus allowing clients to process and display the data
accordingly. accordingly.
A language identifier in the response is specified in section 5.3 of
[draft-ietf-weirds-json-response]. It is used to indicate the
language/script of the response data. It is possible that
registration data is stored in several different languages and
returned in a single response. Data portion of different language
types SHOULD be tagged with its corresponding identifier if known.
8.3. Language Identifiers in HTTP Headers 8.3. Language Identifiers in HTTP Headers
Given the description of the use of language identifiers in Given the description of the use of language identifiers in
Section 8.2, unless otherwise specified servers SHOULD ignore the Section 8.2, unless otherwise specified servers SHOULD ignore the
HTTP [RFC2616] Accept-Language header when formulating responses. HTTP [RFC2616] Accept-Language header when formulating responses.
However, servers MAY return language identifiers in the Content- However, servers MAY return language identifiers in the Content-
Language header so as to inform clients of the intended language of Language header so as to inform clients of the intended language of
HTTP layer messages. HTTP layer messages.
9. Contributing Authors and Acknowledgements 9. Contributing Authors and Acknowledgements
John Levine provided text to tighten up the Accept header usage and John Levine provided text to tighten up the Accept header usage and
the text for the section on 429 responses. the text for the section on 429 responses.
Marc Blanchet provided some clarifying text regarding the use of URLs Marc Blanchet provided some clarifying text regarding the use of URLs
with redirects. with redirects.
10. Normative References 10. Normative References
[draft-ietf-weirds-json-response]
Newton, A.L. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", Work in
progress: Internet Drafts draft-ietf-weirds-json-
response-01.txt, December 2012.
[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.
[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.
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
skipping to change at page 9, line 44 skipping to change at page 9, line 33
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, April 2012. Codes", RFC 6585, April 2012.
[W3C.WD-cors-20130129]
Kesteren, A., "Cross-Origin Resource Sharing", World Wide
Web Consortium LastCall WD-cors-20130129, January 2013,
<http://www.w3.org/TR/2012/WD-cors-20130129>.
Appendix A. Cache Busting Appendix A. Cache Busting
To overcome issues with misbehaving HTTP [RFC2616] cache To overcome issues with misbehaving HTTP [RFC2616] cache
infrastructure, clients MAY use an adhoc and improbably used query infrastructure, clients MAY use an adhoc and improbably used query
parameter with a random value of their choosing. As Section 4.2 parameter with a random value of their choosing. As Section 4.2
instructs servers to ignore unknown parameters, this is unlikely to instructs servers to ignore unknown parameters, this is unlikely to
have any known side effects. have any known side effects.
An example of using an unknown query parameter to bust caches: An example of using an unknown query parameter to bust caches:
skipping to change at page 10, line 47 skipping to change at page 10, line 43
* Added contributing authors and acknowledgements section. * Added contributing authors and acknowledgements section.
* Added some clarifying text regarding complete URLs in the * Added some clarifying text regarding complete URLs in the
redirect section. redirect section.
* Changed media type to application/rdap+json * Changed media type to application/rdap+json
* Added media type registration * Added media type registration
-03
* Removed forward reference to draft-ietf-weirds-json-response.
* Added reference and recommended usage of CORS
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. 9 change blocks. 
17 lines changed or deleted 21 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/