Network Working Group A. Newton Internet-Draft L. Daigle Expires: December 5, 2003 VeriSign, Inc. June 06, 2003 IRIS - A Lightweight Transport draft-newton-iris-lightweight-01.txt 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 December 5, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines a lightweight UDP transport for the Internet Registry Information Service (IRIS). Newton & Daigle Expires December 5, 2003 [Page 1] Internet-Draft iris-lwz June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use of IRIS-LWZ . . . . . . . . . . . . . . . . . . . . . . 3 2.1 IRIS-LWZ Packet Formats . . . . . . . . . . . . . . . . . . 3 2.2 IRIS-LWZ Transactions . . . . . . . . . . . . . . . . . . . 4 2.2.1 Client behaviour . . . . . . . . . . . . . . . . . . . . . . 4 2.2.2 Server behaviour . . . . . . . . . . . . . . . . . . . . . . 5 3. IRIS-LWZ Operations . . . . . . . . . . . . . . . . . . . . 6 3.1 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . 11 5. IRIS Transport Mapping Definitions . . . . . . . . . . . . . 12 5.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2 Application Protocol Label . . . . . . . . . . . . . . . . . 12 6. Registrations . . . . . . . . . . . . . . . . . . . . . . . 12 6.1 URI Scheme Registration . . . . . . . . . . . . . . . . . . 12 6.2 Well-known UDP Port Registration . . . . . . . . . . . . . . 13 6.3 NAPSTR Registration . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . 16 Newton & Daigle Expires December 5, 2003 [Page 2] Internet-Draft iris-lwz June 2003 1. Introduction The Internet Registry Information Service (IRIS [3]) defines a CRISP [5] compliant administrative information service for Internet registries. However, there exist situations where the particular needs of an Internet registry operator may be met with a lightweight transport of IRIS. In order to meet the requirements of CRISP, IRIS uses BEEP [1] over TCP to accomplish such tasks as authentication and encryption. These tasks are almost impossible to conduct over UDP. However, there do exist certain use cases which do not need these features. Based on the needs and policies of an Internet registry, these profiled cases may be conducted over a faster, more lightweight UDP-based transport. It is not the intent of this memo to suggest an alternative to the full IRIS protocol, but to offer an additional method for serving IRIS data should an Internet registry determine it appropriate. And while IRIS does specify that BEEP is its default transport, it does allow for the deployment of more than one transport (as is common with many IP-based protocols). An Internet registry should determine their ability to use this lightweight version based on the following criteria: 1) no access controls are needed and all access is considered anonymous, 2) no encryption or privacy is needed, and 3) the expected queries produce results with small amounts of data. Specifically, each communication (query or response) is required to fit in a single UDP packet. To accomplish a lightweight administrative access service, this slimmed down use of IRIS uses XML that has undergone GZIP [2] compression. However, the schemas used in this lightweight transport are the same as used in other transports of IRIS. For the purposes of describing this profiled use of UDP in comparison with IRIS delivered over BEEP/TCP, this document will refer to IRIS over BEEP/TCP as "IRIS-BEEP", the core schemas and operations of IRIS as "IRIS", and this document's specification of lightweight IRIS over UDP as "IRIS-LWZ". 2. Use of IRIS-LWZ 2.1 IRIS-LWZ Packet Formats The UDP packet format for IRIS-LWZ is as follows: Newton & Daigle Expires December 5, 2003 [Page 3] Internet-Draft iris-lwz June 2003 0 16 31 +--------------------+--------------------+ | Src Port | Dst Port | +--------------------+--------------------+ | Checksum | Length | +--------------------+--------------------+ | Data: GZIP'ed XML instance | | compliant with IRIS-LWZ | | schema defined above | | | (...) | | +-----------------------------------------+ Again, each IRIS-LWZ query and response is contained in a single UDP packet. If no length information is contained in the IRIS-LWZ query, servers should assume a packet size limitation of 512 bytes. 2.2 IRIS-LWZ Transactions 2.2.1 Client behaviour To initiate an IRIS-LWZ query, a client sends a UDP datagram to the identified IRIS-LWZ port on the destination server. As outlined above, the UDP packet payload is the byte sequence obtained by applying GZIP to a valid IRIS-LWZ XML query instance. The client then waits for a reply from the server on the same port from which it sent the query packet. The timeout waiting for a reply is at the discretion of the client. As an example, the client may send the following XML to the server: Newton & Daigle Expires December 5, 2003 [Page 4] Internet-Draft iris-lwz June 2003 After GZIP compression, the client sends a UDP payload similar to the following: 0000:0000 1f 8b 08 08 87 fe 57 3e 00 03 69 72 69 73 6c 77 0000:0010 2d 6c 6f 6f 6b 75 70 2e 78 6d 6c 00 8d 91 31 6f 0000:0020 85 20 14 85 77 7f 05 61 57 c4 2e 0d d1 b7 bc 74 0000:0030 7b ed d0 d7 a1 2b 41 aa e4 21 58 ee 35 ea bf 2f 0000:0040 a2 6d d2 0e 6d 99 b8 27 df e1 70 a0 b6 f3 b3 7e 0000:0050 9f 34 60 46 c8 32 58 07 0d 9d 82 13 46 e3 9b 18 0000:0060 65 90 03 88 28 0b 07 c2 04 03 b9 9d 39 fd 24 c5 0000:0070 02 a6 a1 3d e2 28 18 9b e7 b9 98 ef 0a 1f 3a 56 0000:0080 95 25 67 af 8f 97 ab ea f5 20 73 e3 00 a5 53 3a 0000:0090 f9 c0 08 48 f2 c5 2b 89 c6 bb 3f e3 48 b4 1d fb 0000:00a0 62 81 96 fc 82 f3 04 6e 14 dd 5c 56 bb 0e fb 86 0000:00b0 f2 ea be a4 a7 2c 2a 75 d8 bb fe a3 29 8f 0e b2 0000:00c0 9d 12 5d a0 65 50 fd 55 e3 29 cd 51 b1 de df a6 0000:00d0 f1 c1 a1 c1 f5 d0 08 09 ba 33 80 61 7d 59 47 dd 0000:00e0 d0 36 8e e9 ad f6 a5 13 7b b6 12 62 ae f2 0e a5 0000:00f0 c2 bc 97 ae b5 fa 27 f4 24 87 e8 1f e4 ad e2 94 0000:0100 b0 3d b3 66 df 2e b1 75 61 47 99 d8 ac 66 5f df 0000:0110 78 ca 3e 00 27 87 1e 9e d3 01 00 00 Before compression, the payload is 467 bytes. After compression, the payload is 284 bytes. 2.2.2 Server behaviour Upon receipt of an IRIS-LWZ query, the server will un-GZIP the UDP Newton & Daigle Expires December 5, 2003 [Page 5] Internet-Draft iris-lwz June 2003 packet payload, carry out whatever processing is appropriate, create a valid IRIS-LWZ XML response instance to the query, and apply GZIP to that instance. If the resulting size is greater than the maximum size provided in the query (or 512 bytes if no maximum size was provided), the server will respond with a GZIP'ed instance of IRIS-LWZ response XML indicating the response was too large. The response is sent as a UDP datagram to the source address and port of the original query. The server's responsibility for addressing a query ends with the transmission of the UDP response datagram. 3. IRIS-LWZ Operations The XML in the following sections is descriptive of the formal XML syntax described in Section 4. For each request type, there is one or more response types. The following shows a brief summary: o * o * an IRIS response. * containing * containing 3.1 Requests IRIS-LWZ requests use the formal syntax specified in Section 4. There are two types of IRIS-LWZ requests: o a profile request o an IRIS request The profile request simply uses the element. Newton & Daigle Expires December 5, 2003 [Page 6] Internet-Draft iris-lwz June 2003 An IRIS request is wrapped in an element. This element has an OPTIONAL 'length' attribute containing a positive integer. This attribute indicates the allowable length of the response in bytes. It allows clients that have an understanding of their UDP path to specify how long the response should be. Clients that do not care about UDP fragmentation may set this number arbitrarily high. If this attribute is not present, servers SHOULD assume a length of 512 bytes. The following is an example of an IRIS request with a query in the 'dreg1' registry-type. com The Cobbler Shoppe AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ c3nBl8CHdkmKuVGUy/ijmvdO5QxuSlU0R4BoCLZk/Sob22RApTn T+ROMbXFQBrxGH08daAOy98WqpfAutWJri61JLpubIbaqhGyB48 Qt69V6OhYfFsJjvoNEOh1k2dgzXhSlzP3OMVSKRlBzGcO8= Newton & Daigle Expires December 5, 2003 [Page 7] Internet-Draft iris-lwz June 2003 3.2 Responses The IRIS-LWZ responses come in two flavors: o a response o a response The response MUST be returned by the server when a client issues a request. The element contains children. Each child element contains an IRIS profile as defined by IRIS-BEEP [4]. The following is an example of a response. http://iana.org/beep/transient/crisp/iris1/dreg1 The response MUST be sent by the server to the client in reply to an . It contains one of three types of content: o an IRIS response o an error indicating the IRIS request was for an unsupported profile. o an error indicating the IRIS response was too large to send. An containing an IRIS response simply contains the IRIS response to the appropriate IRIS request. The following is an example of 'dreg1' IRIS response. thecobblershoppe.com When a client makes an IRIS request for a profile that is not supported by the server, the server MUST return an indicating that an error has occured. This is done with the child element. To signal this condition, the element MUST contain the element. Here is an example: Newton & Daigle Expires December 5, 2003 [Page 9] Internet-Draft iris-lwz June 2003 http://iana.org/beep/transient/crisp/iris1/dreg1 When a client makes an IRIS request that yields a response too large to fit in the negotiated UDP packet, the server MUST respond with an indicating that a size error has occured. This is done with the child element. To signal this condition, the element MUST contain a element. The content of the element is a positive integer stating the size of the IRIS response. Upon receiving this error, a client has the following options: o Requery over IRIS-BEEP. o Requery over IRIS-LWZ using a larger 'length' indicator. o Signal an error. The following is an example of a length error: Newton & Daigle Expires December 5, 2003 [Page 10] Internet-Draft iris-lwz June 2003 2652 4. Formal XML Syntax The following is the XML Schema used to define IRIS-LWZ operations. Lightweight (LWZ) Internet Registry Information Service (IRIS) Schema v1 Newton & Daigle Expires December 5, 2003 [Page 11] Internet-Draft iris-lwz June 2003 5. IRIS Transport Mapping Definitions This section lists the definitions required by IRIS [3] for transport mappings. 5.1 URI Scheme The URI scheme name specific to this transport MUST be "iris-lwz". 5.2 Application Protocol Label The application protocol label MUST be "iris-lwz". 6. Registrations 6.1 URI Scheme Registration URL scheme name: iris-lwz URL scheme syntax: defined in Section 5.1 and [3]. Newton & Daigle Expires December 5, 2003 [Page 12] Internet-Draft iris-lwz June 2003 Character encoding considerations: as defined in RFC2396 [10]. Intended usage: identifies an IRIS entity made available using compressed XML over UDP Applications using this scheme: defined in IRIS [3]. Interoperability considerations: n/a Security Considerations: defined in Section 8. Relevant Publications: IRIS [3]. Contact Information: Andrew Newton Author/Change controller: the IESG 6.2 Well-known UDP Port Registration Protocol Number: UDP Message Formats, Types, Opcodes, and Sequences: defined in Section 2.1 and Section 3. Functions: defined in IRIS [3]. Use of Broadcast/Multicast: none Proposed Name: IRIS over LWZ Short name: iris-lwz Contact Information: Andrew Newton 6.3 NAPSTR Registration Application Protocol Label: iris-lwz Intended usage: identifies an IRIS server using compressed XML over UDP Interoperability considerations: n/a Security Considerations: defined in Section 8. Relevant Publications: IRIS [3]. Contact Information: Andrew Newton Newton & Daigle Expires December 5, 2003 [Page 13] Internet-Draft iris-lwz June 2003 Author/Change controller: the IESG 7. IANA Considerations Registrations with the IANA are described in Section 6. 8. Security Considerations IRIS-LWZ is intended for serving public data; it provides no in-band mechanisms for authentication or encryption. Any application that needs that must provide out of band mechanisms to provide it (e.g., IPSec), or use the IRIS protocol with an application transport that provides such capabilities (e.g. BEEP [1]. References [1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [2] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L. and G. Randers-Pehrson, "GZIP file format specification version 4.3", RFC 1952, May 1996. [3] Newton, A., "Internet Registry Information Service", draft-ietf-crisp-iris-core-01 (work in progress), November 2002. [4] Newton, A., "Internet Registry Information Service (IRIS) over Blocks Exstensible Exchange Protocol (BEEP)", draft-ietf-crisp-iris-beep-01 (work in progress), November 2002. [5] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", draft-ietf-crisp-requirements-00 (work in progress), August 2002. [6] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [7] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, . [8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, . Newton & Daigle Expires December 5, 2003 [Page 14] Internet-Draft iris-lwz June 2003 [9] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, . [10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Authors' Addresses Andrew Newton VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US EMail: anewton@verisignlabs.com; anewton@ecotroph.net Leslie Daigle VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US EMail: leslie@verisignlabs.com; leslie@thinkingcat.com Newton & Daigle Expires December 5, 2003 [Page 15] Internet-Draft iris-lwz June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 assignees. 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 Newton & Daigle Expires December 5, 2003 [Page 16] Internet-Draft iris-lwz June 2003 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 & Daigle Expires December 5, 2003 [Page 17]