idnits 2.17.1 draft-ietf-weirds-using-http-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 5, 2012) is 4160 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAC-051' ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft ARIN 4 Intended status: Standards Track B. Ellacott 5 Expires: June 8, 2013 APNIC 6 N. Kong 7 CNNIC 8 December 5, 2012 10 Using the Registration Data Access Protocol (RDAP) with HTTP 11 draft-ietf-weirds-using-http-01 13 Abstract 15 This document describes the usage of the Registration Data Access 16 Protocol (RDAP) using HTTP. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 8, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Accept Header . . . . . . . . . . . . . . . . . . . . . . 6 57 4.2. Query Parameters . . . . . . . . . . . . . . . . . . . . . 6 58 5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . . 7 59 5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . . 7 60 5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . . 7 62 5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 7 63 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 8. Internationalization Considerations . . . . . . . . . . . . . 10 66 8.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 10 67 8.2. Language Identifiers in Queries and Responses . . . . . . 10 68 8.3. Language Identifiers in HTTP Headers . . . . . . . . . . . 10 69 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 70 Appendix A. Cache Busting . . . . . . . . . . . . . . . . . . . . 12 71 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 This document describes the usage of HTTP for Registration Data 77 Directory Services running on RESTful web servers. The goal of this 78 document is to tie together the usage patterns of HTTP into a common 79 profile applicable to the various types of Directory Services serving 80 Registration Data using RESTful styling. By giving the various 81 Directory Services common behavior, a single client is better able to 82 retrieve data from Directory Services adhering to this behavior. 84 In designing these common usage patterns, this draft endeavours to 85 satisfy requirements for a Registration Data Access Protocol (RDAP) 86 that is documented in [draft-kucherawy-weirds-requirements]. This 87 draft also introduces an additional design consideration to define a 88 simple use of HTTP. Where complexity may reside, it is the goal of 89 this specification to place it upon the server and to keep the client 90 as simple as possible. A client implementation should be possible 91 using common operating system scripting tools. 93 This is the basic usage pattern for this protocol: 95 1. A client issues an HTTP query using GET. As an example, a query 96 for the network registration 192.0.2.0 might be 97 http://example.com/ip/192.0.2.0. 99 2. If the receiving server has the information for the query, it 100 examines the Accept header field of the query and returns a 200 101 response with a response entity appropriate for the requested 102 format. 104 3. If the receiving server does not have the information for the 105 query but does have knowledge of where the information can be 106 found, it will return a redirection response (3xx) with the 107 Location: header containing an HTTP URL pointing to the 108 information or another server known to have knowledge of the 109 location of the information. The client is expected to re-query 110 using that HTTP URL. 112 4. If the receiving server does not have the information being 113 requested and does not have knowledge of where the information 114 can be found, it should return a 404 response. 116 It is important to note that it is not the intent of this document to 117 redefine the meaning and semantics of HTTP. The purpose of this 118 document is to clarify the use of standard HTTP mechanisms for this 119 application. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 As is noted in SSAC Report on WHOIS Terminology and Structure 128 [SAC-051], the term "Whois" is overloaded, often referring to a 129 protocol, a service and data. In accordance with [SAC-051], this 130 document describes the base behavior for a Registration Data Access 131 Protocol (RDAP). [SAC-051] describes a protocol profile of RDAP for 132 Doman Name Registries (DNRs), DNRD-AP. This document and others from 133 the IETF WEIRDS working group describe a single protocol, RDAP, for 134 access to the data of both DNRs and Regional Internet Registries 135 (RIRs). RIRs are also often referred to as number resource 136 registries and are responsible for the registration of IP address 137 networks and autonomous system numbers. 139 3. Design Intents 141 There are a few design criteria this document attempts to support. 143 First, each query is meant to return either zero or one result. With 144 the maximum upper bound being set to one, the issuance of redirects 145 is simplified to the known query/respone model used by HTTP 146 [RFC2616]. Should a result contain more than one result, some of 147 which are better served by other servers, the redirection model 148 becomes much more complicated. 150 Second, multiple response formats are supported by this protocol. At 151 present the IETF WEIRDS working group is defining only a JSON 152 [RFC4627] response format, but server operators may use other data 153 formats when those formats are requested. 155 Third, HTTP offers a number of transport protocol mechanisms not 156 described further in this document. Operators are able to make use 157 of these mechanisms according to their local policy, including cache 158 control, authorization, compression, and redirection. HTTP also 159 benefits from widespread investment in scalability, reliability, and 160 performance, and widespread programmer understanding of client 161 behaviours for RESTful web services, reducing the cost to deploy 162 Registration Data Directory Services and clients. 164 4. Queries 166 4.1. Accept Header 168 Clients SHOULD put the media type of the format they desire in the 169 Accept header field. 171 Accept: application/rdap 173 Servers SHOULD respond with an appropriate media type in the Content- 174 Type header in accordance with the preference rules for the Accept 175 header in HTTP [RFC2616]. 177 Content-Type: application/rdap 179 Clients MAY use a generic media type for the desired data format of 180 the response (e.g. "application/json"), but servers SHOULD respond 181 with the most appropriate media type (e.g. "application/rdap"). In 182 other words, a client may use "application/json" to express that it 183 desires JSON or "application/rdap" to express that it desires RDAP 184 specific JSON, but the server would respond with "application/rdap". 186 4.2. Query Parameters 188 Servers SHOULD ignore unknown query parameters. Use of unknown query 189 parameters for cache-busting is described in Appendix A. 191 5. Types of HTTP Response 193 This section describes the various types of responses a server may 194 send to a client. While no standard HTTP response code is forbidden 195 in usage, at a minimum clients SHOULD understand the response codes 196 described in this section. It is expected that usage of response 197 codes and types for this application not defined here will be 198 described in subsequent documents. 200 5.1. Positive Answers 202 If a server has the information requested by the client and wishes to 203 respond to the client with the information according to its policies, 204 it SHOULD encode the answer in the format most appropriate according 205 to the standard and defined rules for processing the HTTP Accept 206 header, and return that answer in the body of a 200 response. 208 5.2. Redirects 210 If a server wishes to inform a client that the answer to a given 211 query can be found elsewhere, it SHOULD return either a 301 or a 307 212 response code and an HTTP URL in the Location: header. The client is 213 expected to issue a subsequent query using the given URL without any 214 processing of the URL. In other words, the server is to hand back a 215 complete URL and the client should not have to transform the URL to 216 follow it. 218 A server SHOULD use a 301 response to inform the client of a 219 permanent move and a 307 response otherwise. For this application, 220 such an example of a permanent move might be a top level domain (TLD) 221 operator informing a client the information being sought can be found 222 with another TLD operator (i.e. a query for the domain bar in 223 foo.example is found at http://foo.example/domain/bar). 225 5.3. Negative Answers 227 If a server wishes to respond that it has no information regarding 228 the query, it SHOULD return a 404 response code. Optionally, it MAY 229 include additional information regarding the negative answer in the 230 HTTP entity body. 232 5.4. Malformed Queries 234 If a server receives a query which it cannot understand, it SHOULD 235 return a 400 response code. Optionally, it MAY include additional 236 information regarding this negative answer in the HTTP entity body. 238 6. Extensibility 240 For extensibility purposes, this document defines an IANA registry 241 for prefixes used in JSON [RFC4627] data serialization and URI path 242 segments (see Section 7). 244 Prefixes and identifiers SHOULD only consist of the alphabetic ASCII 245 characters A through Z in both uppercase and lowercase, the numerical 246 digits 0 through 9, underscore characters, and SHOULD NOT begin with 247 an underscore character, numerical digit or the characters "xml". 248 The following describes the production of JSON names in ABNF 249 [RFC5234]. 251 ABNF for JSON names 253 name = ALPHA *( ALPHA / DIGIT / "_" ) 255 Figure 1 257 This restriction is a union of the Ruby programming language 258 identifier syntax and the XML element name syntax and has two 259 purposes. First, client implementers using modern programming 260 languages such as Ruby or Java may use libraries that automatically 261 promote JSON names to first order object attributes or members. 262 Second, a clean mapping between JSON and XML is easy to accomplish 263 using these rules. 265 7. IANA Considerations 267 This specification proposes an IANA registry for RDAP extensions. 268 The purpose of this registry is to ensure uniqueness of extension 269 identifiers. The extension identifier is used as prefix in JSON 270 names and as a prefix of path segments in RDAP URLs. 272 The production rule for these identifiers is specified in Section 6. 274 In accordance with RFC5226, the IANA policy for assigning new values 275 shall be Specification Required: values and their meanings must be 276 documented in an RFC or in some other permanent and readily available 277 reference, in sufficient detail that interoperability between 278 independent implementations is possible. 280 The following is a preliminary template for an RDAP extension 281 registration: 283 Extension identifier: the identifier of the extension 285 Registry operator: the name of the registry operator 287 Published specification: RFC number, bibliographical reference or 288 URL to a permanent and readily available specification 290 Person & email address to contact for further information: The 291 names and email addresses of individuals for contact regarding 292 this registry entry 294 Intended usage: brief reasons for this registry entry 296 The following is an example of a registration in the RDAP extension 297 registry: 299 Extension identifier: lunarNic 301 Registry operator: The Registry of the Moon, LLC 303 Published specification: http://www.example/moon_apis/rdap 305 Person & email address to contact for further information: 306 Professor Bernardo de la Paz 308 Intended usage: COMMON 310 8. Internationalization Considerations 312 8.1. URIs and IRIs 314 Clients MAY use IRIs as they see fit, but MUST transform them to URIs 315 [RFC3986] for interaction with RDAP servers. RDAP servers MUST use 316 URIs in all responses, and clients MAY transform these URIs to IRIs. 318 8.2. Language Identifiers in Queries and Responses 320 Depending on the data format of the response, servers MAY include 321 data in character sets other than ASCII and languages other than 322 English (the data format will most likely be in Unicode and almost 323 certainly languages other than English will be encountered). Under 324 most scenarios, clients requesting data will not signal that the data 325 be returned in a particular language or script. On the other hand, 326 when servers return data and have knowledge that the data is in a 327 language or script, the data should be annotated with language 328 identifiers thus allowing clients to process and display the data 329 accordingly. 331 A language identifier in the response is specified in section 5.3 of 332 [draft-ietf-weirds-json-response]. It is used to indicate the 333 language/script of the response data. It is possible that 334 registration data is stored in several different languages and 335 returned in a single response. Data portion of different language 336 types SHOULD be tagged with its corresponding identifier if known. 338 8.3. Language Identifiers in HTTP Headers 340 Given the description of the use of language identifiers in 341 Section 8.2, unless otherwise specified servers SHOULD ignore the 342 HTTP [RFC2616] Accept-Language header when formulating responses. 344 However, servers MAY return language identifiers in the Content- 345 Language header so as to inform clients of the intended language of 346 HTTP layer messages. 348 9. Normative References 350 [draft-kucherawy-weirds-requirements] 351 Kucherawy, M., "Requirements For Internet Registry 352 Services", Work in progress: Internet 353 Drafts draft-kucherawy-weirds-requirements-04.txt, 354 April 2011. 356 [draft-ietf-weirds-json-response] 357 Newton, A. and S. Hollenbeck, "JSON Responses for the 358 Registration Data Access Protocol (RDAP)", Work in 359 progress: Internet 360 Drafts draft-ietf-weirds-json-response-01.txt, 361 December 2012. 363 [SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS 364 Terminology and Structure", September 2011. 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC4627] Crockford, D., "The application/json Media Type for 370 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 372 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 373 Resource Identifier (URI): Generic Syntax", STD 66, 374 RFC 3986, January 2005. 376 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 377 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 378 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 380 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 381 Specifications: ABNF", STD 68, RFC 5234, January 2008. 383 Appendix A. Cache Busting 385 To overcome issues with misbehaving HTTP [RFC2616] cache 386 infrastructure, clients MAY use an adhoc and improbably used query 387 parameter with a random value of their choosing. As Section 4.2 388 instructs servers to ignore unknown parameters, this is unlikely to 389 have any known side effects. 391 An example of using an unknown query parameter to bust caches: 393 http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123 395 Use of an unknown parameter to overcome misbehaving caches is not 396 part of any specification and is offered here for informational 397 purposes. 399 Appendix B. Changelog 401 Initial WG -00: Updated to working group document 2012-September-20 403 -01 405 * Updated for the sections moved to the JSON responses draft. 407 * Simplified media type, removed "level" parameter. 409 * Updated 2119 language and added boilerplate. 411 * In section 1, noted that redirects can go to redirect servers 412 as well. 414 * Added Section 8.2 and Section 8.3. 416 Authors' Addresses 418 Andrew Lee Newton 419 American Registry for Internet Numbers 420 3635 Concorde Parkway 421 Chantilly, VA 20151 422 US 424 Email: andy@arin.net 425 URI: http://www.arin.net 427 Byron J. Ellacott 428 Asia Pacific Network Information Center 429 6 Cordelia Street 430 South Brisbane QLD 4101 431 Australia 433 Email: bje@apnic.net 434 URI: http://www.apnic.net 436 Ning Kong 437 China Internet Network Information Center 438 4 South 4th Street, Zhongguancun, Haidian District 439 Beijing 100190 440 China 442 Phone: +86 10 5881 3147 443 Email: nkong@cnnic.cn