draft-ietf-crisp-iris-lwz-02.txt   draft-ietf-crisp-iris-lwz-03.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: October 31, 2005 April 29, 2005 Expires: December 9, 2005 June 7, 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-02 draft-ietf-crisp-iris-lwz-03
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 October 31, 2005. This Internet-Draft will expire on December 9, 2005.
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).
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
3.1.4 Payload Types . . . . . . . . . . . . . . . . . . . . 7
3.1.5 Version Information . . . . . . . . . . . . . . . . . 7
3.1.6 Size Information . . . . . . . . . . . . . . . . . . . 8
3.1.7 Other Information . . . . . . . . . . . . . . . . . . 8
4. Internationalization Considerations . . . . . . . . . . . . . 10 4. Internationalization Considerations . . . . . . . . . . . . . 10
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
skipping to change at page 6, line 4 skipping to change at page 6, line 4
(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 pick the value randomly and SHOULD NOT responses. Clients SHOULD pick the value randomly and SHOULD NOT
use sequences of 16 bit values. Clients MUST NOT set all the bits use sequences of 16 bit values. Clients MUST NOT set all the bits
in this value to 1 (i.e. use a value of 0xFFFF). in this value to 1 (i.e. use a value of 0xFFFF).
maximum response length - the total length of the UDP packet (i.e. 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.3.1.2). information (Section 3.1.6).
authority length - the length of the authority field in this authority length - the length of the authority field in this
payload descriptor. payload descriptor.
authority - a string of octets describing the authority against 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.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
+--------+-------------+ +--------+-------------+
field | header | transaction | field | header | transaction |
| | ID | | | ID |
+--------+-------------+ +--------+-------------+
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.3.1.3). 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: Each bit in the 1 byte payload header has the following meaning:
bits 7 and 6 - version number ('V' flag) - If 0 (both bits are bits 7 and 6 - 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 5 - 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 4 - 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 3 - 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 2 - reserved - This MUST be 0.
bits 1 and 0 - The value of these bits indicate payload types bits 1 and 0 - The value of these bits indicate payload types
(Section 3.1.3.1) ('PT' flag). (Section 3.1.4) ('PT' field).
3.1.3.1 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.
The payload type values in binary are as follows: The payload type values in binary are as follows:
00 - xml payload ('xml' type). The payload is either an IRIS- 00 - xml payload ('xml' type). The payload is either an IRIS-
based XML request or an IRIS-based XML response. based XML request or an IRIS-based XML response.
01 - version info ('vi' type). In a request packet, this payload 01 - version info ('vi' type). In a request packet, this payload
type indicates that the server is to respond with version type indicates that the server is to respond with version
information (Section 3.1.3.1.1), and that the payload is empty. information (Section 3.1.5), and that the payload is empty. In a
In a response packet, this payload type indicates that the payload response packet, this payload type indicates that the payload is
is version information (Section 3.1.3.1.1). version information (Section 3.1.5).
10 - size info ('si' type). This payload type has no meaning in a 10 - size info ('si' type). This payload type has no meaning in a
request packet and is a descriptor error. In a response packet, request packet and is a descriptor error. In a response packet,
this payload type indicates that the payload is size information this payload type indicates that the payload is size information
(Section 3.1.3.1.2). (Section 3.1.6).
11 - other info ('oi' type). This payload type has no meaning in 11 - other info ('oi' type). This payload type has no meaning in
a request packet and is a descriptor error. In a response packet, a request packet and is a descriptor error. In a response packet,
this payload type indicates that the payload is other information this payload type indicates that the payload is other information
(Section 3.1.3.1.3). (Section 3.1.7).
3.1.3.1.1 Version Information 3.1.5 Version Information
A payload type with version information ('vi') MUST be comformant to A payload type with version information ('vi') MUST be comformant to
the XML defined in [7] and use the <versions> element as the root the XML defined in [7] and use the <versions> element as the root
element. element.
In the context of IRIS-LWZ, the protocol identifiers for these In the context of IRIS-LWZ, the protocol identifiers for these
elements are as follows: elements are as follows:
<transferProtocol> - the value "iris.lwz1" to indicate the <transferProtocol> - the value "iris.lwz1" to indicate the
protocol specified in this document. protocol specified in this document.
skipping to change at page 8, line 32 skipping to change at page 8, line 32
3. The IRIS-based XML payload does not match a version the server 3. The IRIS-based XML payload does not match a version the server
supports. supports.
The protocols identified by the <transferProtocol> element MUST only The protocols identified by the <transferProtocol> element MUST only
indicate protocols running on the same socket as the sender of the indicate protocols running on the same socket as the sender of the
corresponding request. In other words, while a server operator may corresponding request. In other words, while a server operator may
also be running IRIS-XPC, this XML instance is only intended to also be running IRIS-XPC, this XML instance is only intended to
describe version negotiation for IRIS-LWZ. describe version negotiation for IRIS-LWZ.
3.1.3.1.2 Size Information The definition of octet size for the 'requestSizeOctets' and
'responseSizeOctets' attributes of the <tranferProtocol> element are
defined in Section 3.1.6.
3.1.6 Size Information
A payload type with size information ('si') MUST be comformant to the A payload type with size information ('si') MUST be comformant to the
XML defined in [7] and use the <responseSize> element as the root XML defined in [7] and use the <size> element as the root element.
element.
3.1.3.1.3 Other Information Octet counts provided by this information are defined as the total
length of the UDP packet (i.e. UDP header length + payload
descriptor length + XML payload length).
3.1.7 Other Information
A payload type with other information ('oi') MUST be comformant to A payload type with other information ('oi') MUST be comformant to
the XML defined in [7] and use the <other> element as the root the XML defined in [7] and use the <other> element as the root
element. element.
The values for the 'type' attribute of <other> are as follows: The values for the 'type' attribute of <other> are as follows:
'descriptor-error' - indicates there was an error decoding the 'descriptor-error' - indicates there was an error decoding the
descriptor. Servers SHOULD send a descriptor error in the descriptor. Servers SHOULD send a descriptor error in the
following cases: following cases:
 End of changes. 

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