draft-ietf-crisp-iris-lwz-03.txt   draft-ietf-crisp-iris-lwz-04.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: December 9, 2005 June 7, 2005 Expires: January 13, 2006 July 12, 2005
A Lightweight UDP Transfer Protocol for the the Internet Registry A Lightweight UDP Transfer Protocol for the the Internet Registry
Information Service Information Service
draft-ietf-crisp-iris-lwz-03 draft-ietf-crisp-iris-lwz-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 9, 2005. This Internet-Draft will expire on January 13, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a lightweight UDP transfer protocol for the This document describes a lightweight UDP transfer protocol for the
Internet Registry Information Service (IRIS). Internet Registry Information Service (IRIS). This transfer protocol
uses a single packet for every request and response, and optionally
employs compression over the contents of the packet.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5 3.1 Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Payload Request Descriptor . . . . . . . . . . . . . . 5 3.1.1 Payload Request Descriptor . . . . . . . . . . . . . . 5
3.1.2 Payload Response Descriptor . . . . . . . . . . . . . 6 3.1.2 Payload Response Descriptor . . . . . . . . . . . . . 6
3.1.3 Payload Header . . . . . . . . . . . . . . . . . . . . 6 3.1.3 Payload Header . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 2, line 29 skipping to change at page 2, line 29
5. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 11 5. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 11
5.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Application Protocol Label . . . . . . . . . . . . . . . . 11 5.2 Application Protocol Label . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 12 6.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1 URI Scheme Registration . . . . . . . . . . . . . . . 12 6.1.1 URI Scheme Registration . . . . . . . . . . . . . . . 12
6.1.2 Well-known UDP Port Registration . . . . . . . . . . . 12 6.1.2 Well-known UDP Port Registration . . . . . . . . . . . 12
6.1.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12 6.1.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 20 B. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 22
1. Introduction 1. Introduction
Using S-NAPTR [4], IRIS has the ability to define the use of multiple Using S-NAPTR [4], IRIS has the ability to define the use of multiple
application transports or transfer protocols for different types of application transports or transfer protocols for different types of
registry services, all at the descretion of the server operator. The registry services, all at the descretion of the server operator. The
UDP transfer protocol defined in this document is completely modular UDP transfer protocol defined in this document is completely modular
and may be used by any registry types. and may be used by any registry types.
The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ
(for IRIS Lightweight using Compression). (for IRIS Lightweight using Compression). Its message exchange
pattern is simple: a client sends a request in one UDP packet, and a
server responds with an answer in one UDP packet.
IRIS-LWZ is composed of two parts, a binary payload descriptor and an IRIS-LWZ packets are composed of two parts, a binary payload
request/response transaction payload. The request/response descriptor and an request/response transaction payload. The request/
transaction payload may be compressed using the DEFLATE [1] response transaction payload may be compressed using the DEFLATE [1]
algorithm. algorithm.
2. Document Terminology 2. Document Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [6]. document are to be interpreted as described in RFC2119 [6].
Octet fields with numberic values are given according to the
conventions in RFC 1166 [8]: the left most bit of the whole field is
the most significant bit; when a multi-octet quantity is transmitted
the most significant octet is transmitted first. Bits signifying
flags in an octet are numbered according to the conventions of RFC
1166 [8]: bit 0 is the most significant bit and bit 7 is the least
significant bit. When a diagram describes a group of octets, the
order of tranmission for the octets starts from the left.
3. Packet Format 3. Packet Format
The UDP packet format for IRIS-LWZ is as follows: The UDP packet format for IRIS-LWZ is as follows:
+------+------+----------+--------+------------+---------+ +------+------+----------+--------+------------+---------+
field | src | dest | checksum | UDP | payload | payload | field | src | dest | checksum | UDP | payload | payload |
| port | port | | length | descriptor | | | port | port | | length | descriptor | |
+------+------+----------+--------+------------+---------+ +------+------+----------+--------+------------+---------+
octets 2 2 2 2 1..261 0..n octets 2 2 2 2 1..261 0..n
skipping to change at page 6, line 34 skipping to change at page 6, line 34
octets 1 2 octets 1 2
The transaction ID MUST be the value of the transaction ID of the The transaction ID MUST be the value of the transaction ID of the
corresponding request. If the corresponding request did not contain corresponding request. If the corresponding request did not contain
a transaction ID, servers MUST use a transaction ID with all bits set a transaction ID, servers MUST use a transaction ID with all bits set
to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see
Section 3.1.7). Section 3.1.7).
3.1.3 Payload Header 3.1.3 Payload Header
Each bit in the 1 byte payload header has the following meaning: The bits of the payload header are ordered according to RFC 1166 [8],
where bit 0 is the most significant and bit 7 is the least
significant. Each bit in the one octet payload header has the
following meaning:
bits 7 and 6 - version number ('V' field) - If 0 (both bits are bits 0 and 1 - version number ('V' field) - If 0 (both bits are
zero), the protocol is the version defined in this document. zero), the protocol is the version defined in this document.
Otherwise, the rest of the bits in the header and the payload may Otherwise, the rest of the bits in the header and the payload may
be interpreted as another version. be interpreted as another version.
bit 5 - request/response flag ('RR' flag) - If 0, this packet is a bit 2 - request/response flag ('RR' flag) - If 0, this packet is a
request (Section 3.1.1) packet. If 1, this packet is a response request (Section 3.1.1) packet. If 1, this packet is a response
(Section 3.1.2) packet. (Section 3.1.2) packet.
bits 4 - payload deflated ('PD' flag) - If 1, the payload is bits 3 - payload deflated ('PD' flag) - If 1, the payload is
compressed using the DEFLATE [1] algorithm. compressed using the DEFLATE [1] algorithm.
bit 3 - deflate supported ('DS' flag) - If 1, the sender of this bit 4 - deflate supported ('DS' flag) - If 1, the sender of this
packet supports compression using the DEFLATE algorithm. When packet supports compression using the DEFLATE algorithm. When
this bit is 0 in a request, the payload of the response MUST NOT this bit is 0 in a request, the payload of the response MUST NOT
be compressed with DEFLATE. be compressed with DEFLATE.
bit 2 - reserved - This MUST be 0. bit 5 - reserved - This MUST be 0.
bits 1 and 0 - The value of these bits indicate payload types bits 6 and 7 - The value of these bits indicate payload types
(Section 3.1.4) ('PT' field). (Section 3.1.4) ('PT' field).
3.1.4 Payload Types 3.1.4 Payload Types
A payload type indicates the type of content in the UDP packet A payload type indicates the type of content in the UDP packet
following the payload descriptor. Some payload types have no meaning following the payload descriptor. Some payload types have no meaning
in request packets, and some payload types differ in meaning between in request packets, and some payload types differ in meaning between
requests and responses. Some payload types indicate an empty requests and responses. Some payload types indicate an empty
payload. payload.
skipping to change at page 14, line 40 skipping to change at page 14, line 40
August 1998. August 1998.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[7] Newton, A., "A Common Schema for Internet Registry Information [7] Newton, A., "A Common Schema for Internet Registry Information
Service Transfer Protocols", Service Transfer Protocols",
draft-ietf-crips-iris-common-transport-00 (work in progress), draft-ietf-crips-iris-common-transport-00 (work in progress),
April 2005. April 2005.
[8] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers",
RFC 1166, July 1990.
Author's Address Author's Address
Andrew L. Newton Andrew L. Newton
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Sterling, VA 20166 Sterling, VA 20166
USA USA
Phone: +1 703 948 3382 Phone: +1 703 948 3382
Email: anewton@verisignlabs.com; andy@hxr.us Email: anewton@verisignlabs.com; andy@hxr.us
skipping to change at page 20, line 5 skipping to change at page 21, line 5
S: <transferProtocol protocolId="iris.lwz"> S: <transferProtocol protocolId="iris.lwz">
S: <application protocolId="urn:ietf:params:xml:ns:iris1"> S: <application protocolId="urn:ietf:params:xml:ns:iris1">
S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/> S: <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/> S: <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
S: </application> S: </application>
S: </transferProtocol> S: </transferProtocol>
S: </versions> S: </versions>
Figure 7: Example 4 Figure 7: Example 4
Appendix B. Contributors
Substantive contributions to this document have been provided by the
members of the IETF's CRISP Working Group, especially Milena Caires
and David Blacka.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/