Network Working Group A. Newton Internet-Draft VeriSign, Inc. Expires: August 20, 2002 February 19, 2002 IRIS HTTP Binding draft-newton-iris-http-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 20, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies how to use HTTP as the application transport substrate for IRIS (draft-newton-iris-00.txt). Newton Expires August 20, 2002 [Page 1] Internet-Draft iris-http February 2002 Table of Contents 1. Introduction and Motivations . . . . . . . . . . . . . . . . . 3 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 3. URI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Use of HTTP . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Message Passing . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 HTTP Features . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Internationalization Considerations . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 A. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 Newton Expires August 20, 2002 [Page 2] Internet-Draft iris-http February 2002 1. Introduction and Motivations The proposal in this document describes an IRIS[12] application transport binding using HTTP[6]. Requirements for IRIS and the specification in this document are outlined in [13]. The choice of HTTP as the transport substrate is primarily driven by the need to re-use an existing, well-understood protocol with all the necessary features to support the requirements. This gives implementers a wealth of toolkits and debugging gear for use in constructing both servers and clients and allows operators to apply existing experience in issues of deployment. It is also felt that the construction of a simple application transport for the specific purpose of IRIS would yield a similar, though likely smaller, standard after taking into consideration such matters as framing, authentication, etc. It is not the intent of this document to specify HTTP for such usages as by-passing fire-walls, co-mingling URI schemes, or any other such methods which might lead to confusion between an IRIS application and traditional World Wide Web applications using HTTP. The proposal in this document intends to adhere to the best common practices spelled out in RFC3205[8]. Finally, precedents for using other transport mechanisms in layered applications do not seem to fit with the design goals of IRIS. BEEP[3], while a very complete application transport, offers many more features than would otherwise be used in the normal and expected uses of this application. Examples of such features are multiplexing connection behavior and peer-to-peer session negotiation. Conversely, the straight use of TCP such as that specified by [14] does not offer the client negotiation characteristics needed by a referral application where a single client, in the act of processing a query, may traverse multiple servers operating with different parameters. Newton Expires August 20, 2002 [Page 3] Internet-Draft iris-http February 2002 2. Document Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119[11]. Newton Expires August 20, 2002 [Page 4] Internet-Draft iris-http February 2002 3. URI Definition An IRIS URI[16] has the following general syntax. iris://// The full ABNF[17] with certain values included from RFC2396[16] follows. iris-uri = "iris://" server "/" registry-name "/" entity-name server = // as specified by RFC2396 registry-namespace = // as specified by IRIS entity-name = *(unreserved | escaped) reserved = // as specified by RFC2396 escaped = "%" hex hex hex = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" According to the rules in IRIS[12], there is no such thing as a relative URI for this scheme. In addition, valid URI's with this scheme MUST always contain a registry name (namespace identifier) and an entity name. In addition, the entity name MUST be encoded using the UTF-8[18] encoding scheme. Any octet that does not meet the qualification as an unreserved character according to RFC2396[16] MUST be represented by a "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. Newton Expires August 20, 2002 [Page 5] Internet-Draft iris-http February 2002 4. Use of HTTP 4.1 Message Passing The use of the HTTP transport is straight forward. The client connects to an IRIS[12] server and issues a request using the POST method to the "/" path with the Content-Type and Accept header set to "application/xml". The content of the POST body is the IRIS XML[2] instance to be parsed by the server. The results are sent back to the client with a Content-Type of "application/xml". The body of the result is the IRIS XML instance to be parsed by the client. If a client sends an IRIS command, the request MUST also be accompanied by the appropriate Connection header using the "close" connection-token as specified by HTTP/1.1[6]. If the XML instance contains no other request commands, the server MUST return a 204 "No Content" message before closing the connection. If the XML instance contains other request commands, the server MUST return a valid XML instance. 4.2 HTTP Features Though pipelining is allowed and specified by HTTP/1.1[6], the IRIS binding to HTTP restricts the use of the feature. Clients MAY NOT pipeline requests. IRIS allows authentication by means of the application transport. Clients MAY employee the authentication procedures specified in RFC2617[7] for basic and digest authentication using HTTP. In addition, the use of TLS[5] for both client and server authentication and session encryption MAY be used via an Upgrade header as specified by RFC2817[4]. Tunneling methods such as those specified by RFC2818[15] MAY NOT be used. 4.3 Versioning Clients SHOULD inquire as to the supported version of IRIS and SHOULD make this inquiry before issuing any IRIS queries. To do this, the client issues a request using the GET method to the "/versions" path with the Accept header set to "application/xml". The server MUST respond with an XML instance according to the following DTD. The contents of the element MUST be a URI[16] Newton Expires August 20, 2002 [Page 6] Internet-Draft iris-http February 2002 specifying the XML namespace of an XML Schema according to [1]. If a client requests an IRIS version, according to the rules above, for which a server cannot produce responses (i.e. doesn't support that version of IRIS), the server MUST return a 501 "Not Implemented" response. Newton Expires August 20, 2002 [Page 7] Internet-Draft iris-http February 2002 5. Internationalization Considerations URI's are not considered to be internationalized. The topic of internationalized URI's is beyond the scope of this document and is not specific to the IRIS URI scheme defined here. It is an issue to be addressed by a larger scope. The entity name component of an IRIS URI is specified using UTF-8. This has been done for interoperability purposes. Newton Expires August 20, 2002 [Page 8] Internet-Draft iris-http February 2002 6. IANA Considerations The IANA will need to be asked to register the IRIS URI scheme. The IANA will need to assign a standard port number to IRIS over HTTP. It MUST NOT be the same port numbers for the URI schemes http (80) or https (443). Newton Expires August 20, 2002 [Page 9] Internet-Draft iris-http February 2002 7. Security Considerations This document introduces no known security concerns. However, implementers should be fully aware of the security considerations given by IRIS[12], HTTP/1.1[6], HTTP Basic and Digest Authentication[7], and Upgrading To TLS with HTTP[4]. In addition, deference should be given to the security concerns outlined in RFC3205[8]. Newton Expires August 20, 2002 [Page 10] Internet-Draft iris-http February 2002 References [1] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, . [2] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [3] Rose, M.T., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [4] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. [5] Dierks, T., Allen, C., Treese, W., Karlton, P.L., Freier, A.O. and P.C. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [6] Fielding, R.T., Gettys, J., Mogul, J.C., Nielsen, H.F., Masinter, L., Leach, P.J. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [7] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence, S.D., Leach, P.J., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [8] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002. [9] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, STD 2, October 1994. [10] Narten, T. and H.T. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [12] Newton, A, "Internet Registry Information Service", Internet Draft, a work in-progress., February 2002. [13] Newton, A and S Kerr, "Internet Registry Directory Requirements", Internet Draft, a work in-progress., January 2002. Newton Expires August 20, 2002 [Page 11] Internet-Draft iris-http February 2002 [14] Hollenbeck, S, "EPP TCP Transport", Internet Draft, a work in-progress., January 2002. [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [16] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [17] Crocker, D.H. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [18] The Unicode Consortium, "The Unicode Standard, Version 2.0", ISBN 0-201-48345-9 ISBN 0-201-48345-9, January 1988, . Author's Address Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com URI: http://www.research.netsol.com/ Newton Expires August 20, 2002 [Page 12] Internet-Draft iris-http February 2002 Appendix A. Outstanding Issues The following items will need further investigation for future versions of this document. o Incorporation of a query model using DNS SRV records similar to that specified in section 7 of draft-hall-ldap-whois-00.txt. o A valid IANA template for registering the URI scheme. Newton Expires August 20, 2002 [Page 13] Internet-Draft iris-http February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Newton Expires August 20, 2002 [Page 14]