draft-ietf-crisp-iris-lwz-04.txt   draft-ietf-crisp-iris-lwz-05.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: January 13, 2006 July 12, 2005 Expires: August 11, 2006 February 7, 2006
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-04 draft-ietf-crisp-iris-lwz-05
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 January 13, 2006. This Internet-Draft will expire on August 11, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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
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.4 Payload Types . . . . . . . . . . . . . . . . . . . . 7
3.1.5 Version Information . . . . . . . . . . . . . . . . . 7 3.1.5 Version Information . . . . . . . . . . . . . . . . . 8
3.1.6 Size Information . . . . . . . . . . . . . . . . . . . 8 3.1.6 Size Information . . . . . . . . . . . . . . . . . . . 9
3.1.7 Other Information . . . . . . . . . . . . . . . . . . 8 3.1.7 Other Information . . . . . . . . . . . . . . . . . . 9
4. Internationalization Considerations . . . . . . . . . . . . . 10 4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 11 5. Internationalization Considerations . . . . . . . . . . . . . 12
5.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 11 6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 13
5.2 Application Protocol Label . . . . . . . . . . . . . . . . 11 6.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.2 Application Protocol Label . . . . . . . . . . . . . . . . 13
6.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1.1 URI Scheme Registration . . . . . . . . . . . . . . . 12 7.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 14
6.1.2 Well-known UDP Port Registration . . . . . . . . . . . 12 7.1.1 URI Scheme Registration . . . . . . . . . . . . . . . 14
6.1.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12 7.1.2 Well-known UDP Port Registration . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.1.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 15
8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
B. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 22 B. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
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
skipping to change at page 5, line 13 skipping to change at page 5, line 13
order of tranmission for the octets starts from the left. 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 3..261 0..n
(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,
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
and one for a response. However, each format shares a common 1 octet and one for a response. However, each format shares a common 1 octet
payload header described in Section 3.1.3. payload header described in Section 3.1.3.
3.1.1 Payload Request Descriptor 3.1.1 Payload Request Descriptor
The payload descriptor for request packets has the following format: The payload descriptor for request packets varies from 6 to 261
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
These fields have the following meanings: These fields have the following meanings:
skipping to change at page 6, line 17 skipping to change at page 6, line 20
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.
3.1.2 Payload Response Descriptor 3.1.2 Payload Response Descriptor
The payload descriptor for response packets consists of a payload The payload descriptor for response packets is always 3 octets and
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
The transaction ID MUST be the value of the transaction ID of the The purpose of the transaction ID is to allow clients to match
corresponding request. If the corresponding request did not contain requests to responses. A value of 0xFFFF is reserved for server use.
a transaction ID, servers MUST use a transaction ID with all bits set The value of the transaction ID is as follows:
to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see
Section 3.1.7). 1. If the transaction ID in the corresponding request could not be
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
error (see Section 3.1.7).
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
descriptor error (see Section 3.1.7).
3. Otherwise, the transaction ID MUST be the value of the
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 [8], 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 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 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.
skipping to change at page 9, line 17 skipping to change at page 9, line 32
'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:
1. When a request is received with a payload type indicating size 1. When a request is received with a payload type indicating size
information (i.e. the PT flag is 'si'). information (i.e. the PT flag is 'si').
2. When a request is received with a payload type indicating 2. When a request is received with a payload type indicating
other information (i.e. the PT flag is 'oi'). other information (i.e. the PT flag is 'oi').
3. When a request is sent with an invalid transaction ID. 3. When a request is sent with a transaction ID of 0xFFFF (which
is reserved for server use).
4. When reserved bits in the payload descriptor are set to 4. When a request is received with an incomplete or truncated
payload descriptor.
5. When reserved bits in the payload descriptor are set to
values other than zero. values other than zero.
'payload-error' - indicates there was an error interpretting the 'payload-error' - indicates there was an error interpretting the
payload. Servers MUST send a payload error if they receive XML payload. Servers MUST send a payload error if they receive XML
(i.e. the PT flag is set to 'xml') and the XML cannot be parsed. (i.e. the PT flag is set to 'xml') and the XML cannot be parsed.
'system-error' - indicates that the receiver cannot process the 'system-error' - indicates that the receiver cannot process the
request due to a condition not related to this protocol. Servers request due to a condition not related to this protocol. Servers
SHOULD send a system-error when they are capable of responding to SHOULD send a system-error when they are capable of responding to
requests but not capable of processing requests. requests but not capable of processing requests.
skipping to change at page 10, line 5 skipping to change at page 11, line 5
specified in the corresponding request is not served by the specified in the corresponding request is not served by the
receiver. Servers SHOULD send an authority error when they receiver. Servers SHOULD send an authority error when they
receive a request directed to an authority other than those they receive a request directed to an authority other than those they
serve. serve.
'no-inflation-support-error' - indicates that the receiver does 'no-inflation-support-error' - indicates that the receiver does
not support payloads that have been compressed with DEFLATE [1]. not support payloads that have been compressed with DEFLATE [1].
Servers MUST send this error when they receive a request that has Servers MUST send this error when they receive a request that has
been compressed with DEFLATE but they do not support inflation. been compressed with DEFLATE but they do not support inflation.
4. Internationalization Considerations 4. Interactions
The intent of IRIS-LWZ is to utilize UDP for 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
other transfer protocols (i.e. IRIS-XPC and/or BEEP). The following
strategy SHOULD be used:
1. If a request requires authentication, confidentiality, or other
security, use another transfer protocol.
2. If a request is less than or equal to 4000 octets, send it
uncompressed.
3. If a request can be compressed to a size less than or equal to
4000 octets, send the request using compression. Otherwise use
another transfer protocol.
4. If a request yields a size error, send the request with another
transfer protocol.
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 [7] MUST NOT use any other encodings. Use of the XML defined by [7] MUST NOT use any other
character encodings other than UTF-8 or UTF-16. character encodings other than UTF-8 or UTF-16.
5. 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
mappings. mappings.
5.1 URI Scheme 6.1 URI Scheme
See Section 6.1.1. See Section 7.1.1.
5.2 Application Protocol Label 6.2 Application Protocol Label
See Section 6.1.3. See Section 7.1.3.
6. IANA Considerations 7. IANA Considerations
6.1 Registrations 7.1 Registrations
6.1.1 URI Scheme Registration 7.1.1 URI Scheme Registration
URL scheme name: iris.lwz URL scheme name: iris.lwz
URL scheme syntax: defined in Section 5.1 and [3]. URL scheme syntax: defined in Section 6.1 and [3].
Character encoding considerations: as defined in RFC2396 [5]. Character encoding considerations: as defined in RFC2396 [5].
Intended usage: identifies an IRIS entity made available using XML Intended usage: identifies an IRIS entity made available using XML
over UDP over UDP
Applications using this scheme: defined in IRIS [3]. Applications using this scheme: defined in IRIS [3].
Interoperability considerations: n/a Interoperability considerations: n/a
Security Considerations: defined in Section 7. Security Considerations: defined in Section 8.
Relevant Publications: IRIS [3]. Relevant Publications: IRIS [3].
Contact Information: Andrew Newton <andy@hxr.us> Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG Author/Change controller: the IESG
6.1.2 Well-known UDP Port Registration 7.1.2 Well-known UDP Port Registration
Protocol Number: UDP Protocol Number: UDP
UDP Port Number: TBD by IANA
Message Formats, Types, Opcodes, and Sequences: defined in Section 3 Message Formats, Types, Opcodes, and Sequences: defined in Section 3
and Section 3.1. and Section 3.1.
Functions: defined in IRIS [3]. Functions: defined in IRIS [3].
Use of Broadcast/Multicast: none Use of Broadcast/Multicast: none
Proposed Name: IRIS-LWZ Proposed Name: IRIS-LWZ
Short name: iris.lwz Short name: iris.lwz
Contact Information: Andrew Newton <andy@hxr.us> Contact Information: Andrew Newton <andy@hxr.us>
6.1.3 S-NAPTR Registration 7.1.3 S-NAPTR Registration
Application Protocol Label (see [4]): iris.lwz Application Protocol Label (see [4]): iris.lwz
Intended usage: identifies an IRIS server using XML over UDP Intended usage: identifies an IRIS server using XML over UDP
Interoperability considerations: n/a Interoperability considerations: n/a
Security Considerations: defined in Section 7. Security Considerations: defined in Section 8.
Relevant Publications: IRIS [3]. Relevant Publications: IRIS [3].
Contact Information: Andrew Newton <andy@hxr.us> Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG Author/Change controller: the IESG
7. Security Considerations 8. Security Considerations
IRIS-LWZ is intended for serving public data; it provides no in-band IRIS-LWZ is intended for serving public data; it provides no in-band
mechanisms for authentication or encryption. Any application with mechanisms for authentication or encryption. Any application with
this need must provide out of band mechanisms to provide it (e.g., this need must provide out of band mechanisms to provide it (e.g.,
IPSec), or use the IRIS transfer protocols that provides such IPSec), or use the IRIS transfer protocols that provides such
capabilities. capabilities.
8. Normative References 9. Normative References
[1] Deutsch, P., "DEFLATE Compressed Data Format Specification [1] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
[2] The Unicode Consortium, "The Unicode Standard, Version 3", [2] The Unicode Consortium, "The Unicode Standard, Version 3",
ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>. ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[3] Newton, A. and M. Sanz, "Internet Registry Information Service", [3] Newton, A. and M. Sanz, "Internet Registry Information Service",
RFC 3891, January 2004. RFC 3891, January 2004.
skipping to change at page 15, line 14 skipping to change at page 17, line 14
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: andy@hxr.us
URI: http://www.verisignlabs.com/ URI: http://www.verisignlabs.com/
Appendix A. Examples Appendix A. Examples
This section gives examples of IRIS-LWZ exchanges. Lines beginning This section gives examples of IRIS-LWZ exchanges. Lines beginning
with "C:" denote data sent by the client to the server, and lines with "C:" denote data sent by the client to the server, and lines
beginning with "S:" denote data sent by the server to the client. beginning with "S:" denote data sent by the server to the client.
Following the "C:" or "S:", the line either contains octet values in Following the "C:" or "S:", the line either contains octet values in
hexadecimal notation with comments or XML fragments. No line hexadecimal notation with comments or XML fragments. No line
contains both octet values with comments and XML fragments. Comments contains both octet values with comments and XML fragments. Comments
skipping to change at page 20, line 18 skipping to change at page 22, line 18
C: 0x01 0xF2 (maximum response size=498) C: 0x01 0xF2 (maximum response size=498)
C: 0x0B (authority length=11) C: 0x0B (authority length=11)
C: (authority="example.net") C: (authority="example.net")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
S: (response packet) S: (response packet)
S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi) S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi)
S: 0x2E 0x9C (transaction ID=11932) S: 0x2E 0x9C (transaction ID=11932)
S: (Version Information XML response) S: (Version Information XML response)
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport"> S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.lwz"> S: <transferProtocol protocolId="iris.lwz1">
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 Appendix B. Contributors
skipping to change at page 22, line 41 skipping to change at page 24, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 33 change blocks. 
52 lines changed or deleted 94 lines changed or added

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