draft-ietf-crisp-iris-lwz-07.txt   draft-ietf-crisp-iris-lwz-08.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: July 13, 2007 January 9, 2007 Intended status: Standards Track March 5, 2007
Expires: September 6, 2007
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-07 draft-ietf-crisp-iris-lwz-08
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 35
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 July 13, 2007. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
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). This transfer protocol Internet Registry Information Service (IRIS). This transfer protocol
uses a single packet for every request and response, and optionally uses a single packet for every request and response, and optionally
employs compression over the contents of the packet. employs compression over the contents of the packet.
Table of Contents Table of Contents
skipping to change at page 2, line 19 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Payload Header . . . . . . . . . . . . . . . . . . . . 7
3.1.4. Payload Types . . . . . . . . . . . . . . . . . . . . 7 3.1.4. Payload Types . . . . . . . . . . . . . . . . . . . . 7
3.1.5. Version Information . . . . . . . . . . . . . . . . . 8 3.1.5. Version Information . . . . . . . . . . . . . . . . . 8
3.1.6. Size Information . . . . . . . . . . . . . . . . . . . 9 3.1.6. Size Information . . . . . . . . . . . . . . . . . . . 9
3.1.7. Other Information . . . . . . . . . . . . . . . . . . 9 3.1.7. Other Information . . . . . . . . . . . . . . . . . . 9
4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Internationalization Considerations . . . . . . . . . . . . . 12 5. Internationalization Considerations . . . . . . . . . . . . . 13
6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 13 6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 14
6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Application Protocol Label . . . . . . . . . . . . . . . . 13 6.2. Application Protocol Label . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15
7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 14 7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 15
7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 14 7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 15
7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 15 7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 9. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
Using Straightforward Name Authority Pointers [4], IRIS has the Using Straightforward Name Authority Pointers [4], IRIS has the
ability to define the use of multiple application transports or ability to define the use of multiple application transports or
transfer protocols for different types of registry services, all at transfer protocols for different types of registry services, all at
the descretion of the server operator. The UDP transfer protocol the descretion of the server operator. The UDP transfer protocol
defined in this document is completely independent of the registry defined in this document is completely independent of the registry
types for which it can carry data. types for which it can carry data.
skipping to change at page 5, line 19 skipping to change at page 5, line 19
+------------+---------+ +------------+---------+
field | payload | payload | field | payload | payload |
| descriptor | | | descriptor | |
+------------+---------+ +------------+---------+
octets 3 or 6..261* 0..n octets 3 or 6..261* 0..n
* In request packets, the payload descriptor can vary in length * In request packets, the payload descriptor can vary in length
from 6 to 261 octets (i.e. 6..261). In response packets, the from 6 to 261 octets (i.e. 6..261). In response packets, the
payload descriptor is always 3 octets. payload descriptor is always 3 octets.
IRIS-LWZ Packet
(where "src port" means source port and "dest port" means destination (where "src port" means source port and "dest port" means destination
port). port).
Each IRIS-LWZ query or response is contained in a single UDP packet. Each IRIS-LWZ query or response is contained in a single UDP packet.
Servers MUST be prepared to accepted packets as large as 4000 octets, Servers MUST be prepared to accepted packets as large as 4000 octets,
and clients MUST NOT send packets larger than 4000 octets. and clients MUST NOT send packets larger than 4000 octets.
3.1. Payload Descriptor 3.1. Payload Descriptor
The payload descriptor has two different formats, one for a request The payload descriptor has two different formats, one for a request
skipping to change at page 5, line 44 skipping to change at page 5, line 46
The payload descriptor for request packets varies from 6 to 261 The payload descriptor for request packets varies from 6 to 261
octets in lenght and has the following format: octets in lenght and has the following format:
+--------+-------------+----------+-----------+-----------+ +--------+-------------+----------+-----------+-----------+
field | header | transaction | maximum | authority | authority | field | header | transaction | maximum | authority | authority |
| | ID | response | length | | | | ID | response | length | |
| | | length | | | | | | length | | |
+--------+-------------+----------+-----------+-----------+ +--------+-------------+----------+-----------+-----------+
octets 1 2 2 1 0..255 octets 1 2 2 1 0..255
Request Payload Descriptor
These fields have the following meanings: These fields have the following meanings:
header - as described in Section 3.1.3. o header - as described in Section 3.1.3.
transaction ID - a 16 bit value identifying the transaction. This o transaction ID - a 16 bit value identifying the transaction. This
value will be returned in the payload response descriptor value will be returned in the payload response descriptor
(Section 3.1.2) and can be used by clients to match requests with (Section 3.1.2) and can be used by clients to match requests with
responses. Clients SHOULD NOT use sequential values (See responses. Clients SHOULD NOT use sequential values (See
Section 8). Clients MUST NOT set all the bits in this value to 1 Section 8). Clients MUST NOT set all the bits in this value to 1
(i.e. use a value of 0xFFFF). (i.e. use a value of 0xFFFF).
maximum response length - the total length of the UDP packet (i.e. o maximum response length - the total length of the UDP packet (i.e.
UDP header length + payload descriptor length + XML payload UDP header length + payload descriptor length + XML payload
length) that should not be exceeded when responding to this length) that should not be exceeded when responding to this
request. If the server cannot provide a response that is equal to request. If the server cannot provide a response that is equal to
or less than this value, then it MUST respond with size or less than this value, then it MUST respond with size
information (Section 3.1.6). information (Section 3.1.6).
authority length - the length of the authority field in this o authority length - the length of the authority field in this
payload descriptor. payload descriptor.
authority - a string of octets describing the authority against o authority - a string of octets describing the authority against
wich this request is to be executed. See [3] for the definition wich this request is to be executed. See [3] for the definition
and description of an authority. The number of octets in this and description of an authority. The number of octets in this
string MUST be no more and no less than the number specified by string MUST be no more and no less than the number specified by
the authority length. the authority length.
3.1.2. Payload Response Descriptor 3.1.2. Payload Response Descriptor
The payload descriptor for response packets is always 3 octets and The payload descriptor for response packets is always 3 octets and
consists of a payload header (Section 3.1.3) and a transaction ID. consists of a payload header (Section 3.1.3) and a transaction ID.
+--------+-------------+ +--------+-------------+
field | header | transaction | field | header | transaction |
| | ID | | | ID |
+--------+-------------+ +--------+-------------+
octets 1 2 octets 1 2
Response Payload Descriptor
The purpose of the transaction ID is to allow clients to match The purpose of the transaction ID is to allow clients to match
requests to responses. A value of 0xFFFF is reserved for server use. requests to responses. A value of 0xFFFF is reserved for server use.
The value of the transaction ID is as follows: The value of the transaction ID is as follows:
1. If the transaction ID in the corresponding request could not be 1. If the transaction ID in the corresponding request could not be
read due to truncation, servers MUST use a transaction ID with read due to truncation, servers MUST use a transaction ID with
all bits set to 1 (i.e. a value of OxFFFF) and send a descriptor all bits set to 1 (i.e. a value of OxFFFF) and send a descriptor
error (see Section 3.1.7). error (see Section 3.1.7).
2. If the transaction ID in the corresponding request is a value of 2. If the transaction ID in the corresponding request is a value of
0xFFFF, servers MUST us a transaction ID of 0xFFFF and send a 0xFFFF, servers MUST use a transaction ID of 0xFFFF and send a
descriptor error (see Section 3.1.7). descriptor error (see Section 3.1.7).
3. Otherwise, the transaction ID MUST be the value of the 3. Otherwise, the transaction ID MUST be the value of the
transaction ID of the corresponding request. transaction ID of the corresponding request.
3.1.3. Payload Header 3.1.3. Payload Header
The bits of the payload header are ordered according to RFC 1166 The bits of the payload header are ordered according to RFC 1166
[10], where bit 0 is the most significant and bit 7 is the least [10], where bit 0 is the most significant and bit 7 is the least
significant. Each bit in the one octet payload header has the significant. Each bit in the one octet payload header has the
following meaning: following meaning:
bits 0 and 1 - version number ('V' field) - If 0 (both bits are o 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 2 - request/response flag ('RR' flag) - If 0, this packet is a o 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 3 - payload deflated ('PD' flag) - If 1, the payload is o bits 3 - payload deflated ('PD' flag) - If 1, the payload is
compressed using the DEFLATE [1] algorithm. compressed using the DEFLATE [1] algorithm.
bit 4 - deflate supported ('DS' flag) - If 1, the sender of this o 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 5 - reserved - This MUST be 0. o bit 5 - reserved - This MUST be 0.
bits 6 and 7 - The value of these bits indicate payload types o 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 11, line 17 skipping to change at page 11, line 17
The intent of IRIS-LWZ is to utilize UDP for IRIS requests and The intent of IRIS-LWZ is to utilize UDP for IRIS requests and
responses when UDP is appropriate. Not all IRIS requests and responses when UDP is appropriate. Not all IRIS requests and
responses will be able to utilize UDP and may require the use of responses will be able to utilize UDP and may require the use of
other transfer protocols (i.e. IRIS-XPC [9] and/or BEEP). The other transfer protocols (i.e. IRIS-XPC [9] and/or BEEP). The
following strategy SHOULD be used: following strategy SHOULD be used:
1. If a request requires authentication, confidentiality, or other 1. If a request requires authentication, confidentiality, or other
security, use another transfer protocol. IRIS-XPC [9] is security, use another transfer protocol. IRIS-XPC [9] is
RECOMMENDED. RECOMMENDED.
2. If a request is less than or equal to 4000 octets, send it 2. The maximum packet size should be calculated as follows:
uncompressed.
3. If a request can be compressed to a size less than or equal to 1. If the path MTU is unknown, the maximum packet size MUST be
4000 octets, send the request using compression. Otherwise use 1500 octets.
another transfer protocol. In cases where another transfer
protocol is needed, IRIS-XPC [9] is RECOMMENDED.
4. If a request yields a size error, send the request with another 2. If the path MTU is known, the maximum packet size MUST NOT
exceed the path MTU and MUST NOT exceed 4000 octets.
3. If a request is less than or equal to the maximum packet size,
send it uncompressed.
4. If a request can be compressed to a size less than or equal to
the maximum packet size, send the request using compression.
Otherwise use another transfer protocol. In cases where another
transfer protocol is needed, IRIS-XPC [9] is RECOMMENDED.
5. If a request yields a size error, send the request with another
transfer protocol. IRIS-XPC [9] is RECOMMENDED. transfer protocol. IRIS-XPC [9] is RECOMMENDED.
If a client does not know the path MTU or does not use the packet
size recommendations above, the client MUST allocate or have
allocated dedicated network resources that will ensure fairness to
other network packets and avoid packet fragmentation.
For retransmission of requests considered to be unanswered, a client For retransmission of requests considered to be unanswered, a client
SHOULD retransmit using a timeout value initially set to 1 second. SHOULD retransmit using a timeout value initially set to 1 second.
This timeout value SHOULD be doubled for every retransmission, and it This timeout value SHOULD be doubled for every retransmission, and it
a client SHOULD not retransmit any request once the timeout value has a client SHOULD not retransmit any request once the timeout value has
reached 60 seconds. reached 60 seconds. If the next query the client sends is to the
same server, it SHOULD start with the last timeout value used.
Additionally, if a client intends thousands of requests to the same Clients that use timeout values other than the recommendations above
server in a short amount of time, this protocol offers no real MUST allocate or have allocated dedicate network resources that will
advantage over IRIS-XPC [9]. In such a case, IRIS-XPC should be used ensure fairness to other network packets and avoid network
as it would be similarly effecient and would offer greater reponse congestion.
sizes and allow better security.
Clients MUST NOT have more than one outstanding request (i.e. a
unanswered request that has not timed out) at a time unless they
allocate or have been allocated dedicated network bandwidth and
resources reserved specifically for this purpose.
Finally, if a client intends multiple requests to the same server in
a short amount of time, this protocol offers no real advantage over
IRIS-XPC [9]. In such a case, IRIS-XPC should be used as it would be
similarly effecient and would offer greater reponse sizes and allow
better security.
5. Internationalization Considerations 5. Internationalization Considerations
XML processors are obliged to recognize both UTF-8 and UTF-16 [2] XML processors are obliged to recognize both UTF-8 and UTF-16 [2]
encodings. Use of the XML defined by [8] MUST NOT use any other encodings. Use of the XML defined by [8] MUST NOT use any other
character encodings other than UTF-8 or UTF-16. character encodings other than UTF-8 or UTF-16.
6. IRIS Transport Mapping Definitions 6. IRIS Transport Mapping Definitions
This section lists the definitions required by IRIS [3] for transport This section lists the definitions required by IRIS [3] for transport
skipping to change at page 25, line 5 skipping to change at page 26, line 5
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: andy@hxr.us Email: andy@hxr.us
URI: http://www.verisignlabs.com/ URI: http://www.verisignlabs.com/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
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.
skipping to change at page 25, line 29 skipping to change at page 26, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 29 change blocks. 
61 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/