Network Working Group A. Newton Internet-Draft VeriSign, Inc. Expires: February 12, 2003 August 14, 2002 Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) draft-ietf-crisp-iris-beep 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 February 12, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS) as described draft-ietf-crisp-iris-core-00.txt. Newton Expires February 12, 2003 [Page 1] Internet-Draft iris-beep August 2002 Table of Contents 1. Introduction and Motivations . . . . . . . . . . . . . . . . . 3 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 3. BEEP Profile Identification . . . . . . . . . . . . . . . . . 5 4. IRIS Message Packages . . . . . . . . . . . . . . . . . . . . 6 5. IRIS Message Patterns . . . . . . . . . . . . . . . . . . . . 7 6. URI Definition . . . . . . . . . . . . . . . . . . . . . . . . 8 7. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Registrations . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1 BEEP Profile Registration . . . . . . . . . . . . . . . . . . 10 8.2 URI Scheme Registration . . . . . . . . . . . . . . . . . . . 10 8.3 Well-known TCP Port Registration . . . . . . . . . . . . . . . 10 9. Internationalization Considerations . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 Newton Expires February 12, 2003 [Page 2] Internet-Draft iris-beep August 2002 1. Introduction and Motivations The proposal in this document describes an IRIS[8] application transport binding using BEEP[2]. Requirements for IRIS and the specification in this document are outlined in CRISP[14]. The choice of BEEP 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 and probably less complete, standard after taking into consideration such matters as framing, authentication, etc. Precedents for using other transport mechanisms in layered applications do not seem to fit with the design goals of IRIS. HTTP[5] offers many features employed for use by similar applications. However, it is not the intention of IRIS to be put to such uses as by-passing fire-walls, co-mingling URI schemes, or any other such methods which might lead to confusion between IRIS and traditional World Wide Webb applications. Beyond adhering to the guidelines spelled out in RFC3205[6], the use of HTTP also offers many other challenges that quickly erode its appeal. For example, the appropriate use of TLS[4] with HTTP is defined by RFC2817[3], but the common use as described in RFC2818[10] is usually the only method in most implementations. Finally, the straight use of TCP such as that specified by EPP-TCP[9] 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 February 12, 2003 [Page 3] Internet-Draft iris-beep August 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[7]. Newton Expires February 12, 2003 [Page 4] Internet-Draft iris-beep August 2002 3. BEEP Profile Identification The BEEP profile for IRIS is identified with the following URI: http://iana.org/beep/transient/crisp/iris/1 This URI is used in the "profile" element in BEEP during channel creation. It contains the version number of the IRIS schema to be used. According to the rules of BEEP, multiple "profile" elements may be offered thus allowing for a negotiation of the version of IRIS to be used. According to the rules of IRIS, this profile maps to the version of IRIS identified by "urn:ietf:params:xml:ns:iris1". Once this profile is accepted and the channel is created, the state of the channel is considered ready to exchange IRIS messages. Newton Expires February 12, 2003 [Page 5] Internet-Draft iris-beep August 2002 4. IRIS Message Packages The BEEP profile for IRIS transmits XML[1] instances encoded as UTF-8[13] using the media-type of "application/xml" according to RFC3023[15]. Newton Expires February 12, 2003 [Page 6] Internet-Draft iris-beep August 2002 5. IRIS Message Patterns The BEEP profile for IRIS only has a one-to-one request/response message pattern. This exchange involves sending an IRIS XML instance, which results in a response of an IRIS XML instance. The request is sent by the client using an "MSG" message containing a valid IRIS XML instance. The server responds with an "RPY" message containing a valid IRIS XML instance. The "ERR" message is not used for faults and all responses from the server MUST use the "RPY" message. Newton Expires February 12, 2003 [Page 7] Internet-Draft iris-beep August 2002 6. URI Definition An IRIS URI[11] has the following general syntax. iris:///// The full ABNF[12] with certain values included from RFC2396[11] follows. iris-uri = "iris://" authority "/" registry-id "/" entity-class "/" entity-name authority = // as specified by RFC2396 registry-id = // as specified by IRIS entity-class = *(unreserved | escaped) 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[8], 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 ID (namespace identifier), an entity class, and an entity name. In addition, the entity class and entity name MUST be encoded using the UTF-8[13] encoding scheme. Any octet that does not meet the qualification as an unreserved character according to RFC2396[11] 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 February 12, 2003 [Page 8] Internet-Draft iris-beep August 2002 7. URI Resolution The authority component of an IRIS URI may only contain a domain name or an IP address accompanied by an optional port number. A domain name in the authority component MAY NOT be accompanied by a port number. The authority component of the scheme adheres to the syntax specified in RFC2396[11], but indicates the server or set of servers authoritatively responsible for a domain according to SRV[16] records in DNS if a domain is specified or indicates the specific server to be queried if an IP address is specified. The rules for resolution are: o If the authority component is a domain name, the SRV algorithm is used with a service parameter of "iris" and a protocol parameter of "tcp" to determine the IP/TCP addressing information. If no appropriate SRV RRs are found (e.g., for "_iris._tcp.example.com"), then the DNS is queried for the A RRs corresponding to the domain name and the port number used is the well-known port assigned by the IANA for IRIS using BEEP. o If the authority component is an IP address, then the DNS is not queried, and the IP address is used directly. If a port number is present, it is used directly; otherwise, the port number used is the well-known port assigned by the IANA for IRIS over BEEP. Here are some examples of IRIS URI's: o iris://example.com/dreg/domain/example.com * Asks a server authoritative for "example.com" about "example.com". o iris://com/dreg/domain/example.com * Asks a server authoritative for "com" about "example.com". o iris://10.0.1.1:44/dreg/domain/example.com * Asks the server at IP address 10.0.1.1 on port 44 about the domain "example.com". Newton Expires February 12, 2003 [Page 9] Internet-Draft iris-beep August 2002 8. Registrations 8.1 BEEP Profile Registration Profile Identification: http://iana.org/beep/transient/crisp/iris/0.2 Messages exchanged during Channel Creation: none Messages starting one-to-one exchanges: IRIS XML instance Messages in positive replies: IRIS XML instance Messages in negative replies: none Messages in one-to-many exchanges: none Message Syntax: IRIS XML instances as defined by IRIS[8]. Message Semantics: request/response exchanges as defined by IRIS[8]. Contact Information: Andrew Newton 8.2 URI Scheme Registration URL scheme name: iris URL scheme syntax: defined in Section 6. Character encoding considerations: as defined in RFC2396[11]. Intended usage: identifies an IRIS entity made available using the BEEP profile for IRIS Applications using this scheme: defined in IRIS[8]. Interoperability considerations: n/a Security Considerations: defined in Section 11. Relevant Publications: BEEP[2] and IRIS[8]. Contact Information: Andrew Newton Author/Change controller: the IESG 8.3 Well-known TCP Port Registration Protocol Number: TCP Newton Expires February 12, 2003 [Page 10] Internet-Draft iris-beep August 2002 Message Formats, Types, Opcodes, and Sequences: defined in Section 3, Section 4, and Section 5. Functions: defined in IRIS[8]. Use of Broadcast/Multicast: none Proposed Name: IRIS over BEEP Short name: iris Contact Information: Andrew Newton Newton Expires February 12, 2003 [Page 11] Internet-Draft iris-beep August 2002 9. 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 class and entity name components of an IRIS URI is specified using UTF-8. This has been done for interoperability purposes. Newton Expires February 12, 2003 [Page 12] Internet-Draft iris-beep August 2002 10. 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 BEEP. Newton Expires February 12, 2003 [Page 13] Internet-Draft iris-beep August 2002 11. Security Considerations This document introduces no known security concerns. However, implementers should be fully aware of the security considerations given by IRIS[8], BEEP[2], and TLS[4]. Newton Expires February 12, 2003 [Page 14] Internet-Draft iris-beep August 2002 References [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [2] Rose, M.T., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [3] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. [4] 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. [5] 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. [6] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [8] Newton, A, "Internet Registry Information Service", draft-ietf-crisp-iris-core-00 (work in progress), August 2002. [9] Hollenbeck, S, "EPP TCP Transport", Internet Draft, a work in-progress., January 2002. [10] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [11] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [12] Crocker, D.H. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [13] The Unicode Consortium, "The Unicode Standard, Version 2.0", ISBN 0-201-48345-9 ISBN 0-201-48345-9, January 1988, . [14] Newton, A, "Cross Registry Internet Service Protocol (CRISP) Requirements", draft-ietf-crisp-requirements-00 (work in progress), August 2002. Newton Expires February 12, 2003 [Page 15] Internet-Draft iris-beep August 2002 [15] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [16] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. 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.verisignlabs.com/ Newton Expires February 12, 2003 [Page 16] Internet-Draft iris-beep August 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 February 12, 2003 [Page 17]