draft-ietf-crisp-iris-lwz-08.txt   rfc4993.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Request for Comments: 4993 VeriSign, Inc.
Intended status: Standards Track March 5, 2007 Category: Standards Track August 2007
Expires: September 6, 2007
A Lightweight UDP Transfer Protocol for the the Internet Registry
Information Service
draft-ietf-crisp-iris-lwz-08
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 A Lightweight UDP Transfer Protocol
http://www.ietf.org/ietf/1id-abstracts.txt. for the Internet Registry Information Service
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2007. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 2. Document Terminology ............................................3
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Packet Format ...................................................4
3.1. Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5 3.1. Payload Descriptor .........................................4
3.1.1. Payload Request Descriptor . . . . . . . . . . . . . . 5 3.1.1. Payload Request Descriptor ..........................4
3.1.2. Payload Response Descriptor . . . . . . . . . . . . . 6 3.1.2. Payload Response Descriptor .........................5
3.1.3. Payload Header . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Payload Header ......................................6
3.1.4. Payload Types . . . . . . . . . . . . . . . . . . . . 7 3.1.4. Payload Types .......................................6
3.1.5. Version Information . . . . . . . . . . . . . . . . . 8 3.1.5. Version Information .................................7
3.1.6. Size Information . . . . . . . . . . . . . . . . . . . 9 3.1.6. Size Information ....................................8
3.1.7. Other Information . . . . . . . . . . . . . . . . . . 9 3.1.7. Other Information ...................................8
4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Interactions ....................................................9
5. Internationalization Considerations . . . . . . . . . . . . . 13 5. Internationalization Considerations ............................10
6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 14 6. IRIS Transport Mapping Definitions .............................10
6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. URI Scheme ................................................10
6.2. Application Protocol Label . . . . . . . . . . . . . . . . 14 6.2. Application Protocol Label ................................10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations ............................................10
7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Registrations .............................................10
7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 15 7.1.1. URI Scheme Registration ............................10
7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 15 7.1.2. Well-known UDP Port Registration ...................11
7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 16 7.1.3. S-NAPTR Registration ...............................11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations ........................................12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 18 9. References .....................................................13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References ......................................13
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References ....................................13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Examples ..............................................14
Intellectual Property and Copyright Statements . . . . . . . . . . 26 Appendix B. Contributors ..........................................18
1. Introduction 1. Introduction
Using Straightforward Name Authority Pointers [4], IRIS has the Using Straightforward Name Authority Pointers (S-NAPTR) [4], IRIS has
ability to define the use of multiple application transports or the 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 discretion 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.
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). Its message exchange (for IRIS Lightweight using Compression). Its message exchange
pattern is simple: a client sends a request in one UDP packet, and a pattern is simple: a client sends a request in one UDP packet, and a
server responds with an answer in one UDP packet. server responds with an answer in one UDP packet.
IRIS-LWZ packets are composed of two parts, a binary payload IRIS-LWZ packets are composed of two parts, a binary payload
descriptor and an request/response transaction payload. The request/ descriptor and a request/response transaction payload. The request/
response 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 Octet fields with numeric values are given according to the
conventions in RFC 1166 [10]: the left most bit of the whole field is conventions in RFC 1166 [10]: the left most bit of the whole field is
the most significant bit; when a multi-octet quantity is transmitted the most significant bit; when a multi-octet quantity is transmitted
the most significant octet is transmitted first. Bits signifying the most significant octet is transmitted first. Bits signifying
flags in an octet are numbered according to the conventions of RFC flags in an octet are numbered according to the conventions of RFC
1166 [10]: bit 0 is the most significant bit and bit 7 is the least 1166 [10]: bit 0 is the most significant bit and bit 7 is the least
significant bit. When a diagram describes a group of octets, the significant bit. When a diagram describes a group of octets, the
order of tranmission for the octets starts from the left. order of transmission for the octets starts from the left.
3. Packet Format 3. Packet Format
The packet format for IRIS-LWZ is as follows: The packet format for IRIS-LWZ is as follows:
+------------+---------+ +------------+---------+
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 IRIS-LWZ Packet
(where "src port" means source port and "dest port" means destination Each IRIS-LWZ query or response is contained in a single UDP
port). packet. Servers MUST be prepared to accept packets as large as
4000 octets, and clients MUST NOT send packets larger than 4000
Each IRIS-LWZ query or response is contained in a single UDP packet. octets.
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
and one for a response. However, each format shares a common 1 octet request and one for a response. However, each format shares a
payload header described in Section 3.1.3. common 1-octet 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 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 length 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 Request Payload Descriptor
These fields have the following meanings: These fields have the following meanings:
o header - as described in Section 3.1.3. o header - as described in Section 3.1.3.
o 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
(Section 3.1.2) and can be used by clients to match requests with 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
Section 8). Clients MUST NOT set all the bits in this value to 1 8). Clients MUST NOT set all the bits in this value to 1 (i.e.,
(i.e. use a value of 0xFFFF). use a value of 0xFFFF).
o maximum response length - the total length of the UDP packet (i.e. o maximum response length - the total length of the UDP packet
UDP header length + payload descriptor length + XML payload (i.e., 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).
o 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.
o 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 which 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 Payload Response 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 use 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 1-octet payload header has the
following meaning: following meaning:
o 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.
o 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.
skipping to change at page 7, line 34 skipping to change at page 6, line 31
o 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.
o 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.
o bit 5 - reserved - This MUST be 0. o bit 5 - reserved - This MUST be 0.
o bits 6 and 7 - The value of these bits indicate payload types o bits 6 and 7 - The value of these bits indicates 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 8, line 19 skipping to change at page 7, line 17
this payload type indicates that the payload is size information this payload type indicates that the payload is size information
(Section 3.1.6). (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.7). (Section 3.1.7).
3.1.5. 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 conformant to
the XML defined in [8] and use the <versions> element as the root the XML defined in [8] 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.
<application> - the XML namespace identifier for IRIS [3]. <application> - the XML namespace identifier for IRIS [3].
<dataModel> - the XML namespace identifier for IRIS registries. <dataModel> - the XML namespace identifier for IRIS registries.
This document defines no extension identifiers and no authentication This document defines no extension identifiers and no authentication
mechanism identifiers. mechanism identifiers.
Servers SHOULD send version information in the following cases: Servers SHOULD send version information in the following cases:
1. In response to a version information request (i.e. the PT flag is 1. In response to a version information request (i.e., the PT field
set to 'vi'). is set to 'vi').
2. The version in a payload descriptor header does not match a 2. The version in a payload descriptor header does not match a
version the server supports. version the server supports.
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 response. In other words, while a server operator may corresponding response. In other words, while a server operator may
also be running IRIS-XPC [9], this XML instance is only intended to also be running IRIS-XPC [9], this XML instance is only intended to
describe version negotiation for IRIS-LWZ. describe version negotiation for IRIS-LWZ.
The definition of octet size for the 'requestSizeOctets' and The octet size for the 'requestSizeOctets' and 'responseSizeOctets'
'responseSizeOctets' attributes of the <tranferProtocol> element are attributes of the <tranferProtocol> element are defined in Section
defined in Section 3.1.6. 3.1.6.
3.1.6. Size Information 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 conformant to the
XML defined in [8] and use the <size> element as the root element. XML defined in [8] and use the <size> element as the root element.
Octet counts provided by this information are defined as the total Octet counts provided by this information are defined as the total
length of the UDP packet (i.e. UDP header length + payload length of the UDP packet (i.e., UDP header length + payload
descriptor length + XML payload length). descriptor length + XML payload length).
3.1.7. Other Information 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 conformant to
the XML defined in [8] and use the <other> element as the root the XML defined in [8] 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:
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 field 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 field is 'oi').
3. When a request is sent with a transaction ID of 0xFFFF (which 3. When a request is sent with a transaction ID of 0xFFFF (which
is reserved for server use). is reserved for server use).
4. When a request is received with an incomplete or truncated 4. When a request is received with an incomplete or truncated
payload descriptor. payload descriptor.
5. When reserved bits in the payload descriptor are set to values 5. When reserved bits in the payload descriptor are set to values
other than zero. other than zero.
'payload-error' - indicates there was an error interpretting the 'payload-error' - indicates there was an error interpreting 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 field 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.
'authority-error' - indicates that the intended authority 'authority-error' - indicates that the intended authority
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
skipping to change at page 11, line 10 skipping to change at page 9, line 21
'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. Interactions 4. Interactions
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 Blocks Extensible
following strategy SHOULD be used: Exchange Protocol (BEEP)). The 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. The maximum packet size should be calculated as follows: 2. The maximum packet size should be calculated as follows:
1. If the path MTU is unknown, the maximum packet size MUST be a. If the path MTU is unknown, the maximum packet size MUST be
1500 octets. 1500 octets.
2. If the path MTU is known, the maximum packet size MUST NOT b. If the path MTU is known, the maximum packet size MUST NOT
exceed the path MTU and MUST NOT exceed 4000 octets. exceed the path MTU and MUST NOT exceed 4000 octets.
3. If a request is less than or equal to the maximum packet size, 3. If a request is less than or equal to the maximum packet size,
send it uncompressed. send it uncompressed.
4. If a request can be compressed to a size less than or equal to 4. If a request can be compressed to a size less than or equal to
the maximum packet size, send the request using compression. the maximum packet size, send the request using compression.
Otherwise use another transfer protocol. In cases where another Otherwise, use another transfer protocol. In cases where another
transfer protocol is needed, IRIS-XPC [9] is RECOMMENDED. transfer protocol is needed, IRIS-XPC [9] is RECOMMENDED.
5. If a request yields a size error, send the request with another 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 a
a client SHOULD not retransmit any request once the timeout value has client SHOULD NOT retransmit any request once the timeout value has
reached 60 seconds. If the next query the client sends is to the reached 60 seconds.
same server, it SHOULD start with the last timeout value used.
Clients that use timeout values other than the recommendations above Clients that use timeout values other than the recommendations above
MUST allocate or have allocated dedicate network resources that will MUST allocate or have allocated dedicated network resources that will
ensure fairness to other network packets and avoid network ensure fairness to other network packets and avoid network
congestion. congestion.
Clients MUST NOT have more than one outstanding request (i.e. a Clients MUST NOT have more than one outstanding request (i.e., an
unanswered request that has not timed out) at a time unless they unanswered request that has not timed out) at a time unless they
allocate or have been allocated dedicated network bandwidth and allocate or have been allocated dedicated network bandwidth and
resources reserved specifically for this purpose. resources reserved specifically for this purpose.
Finally, if a client intends multiple requests to the same server in Finally, if a client intends multiple requests to the same server in
a short amount of time, this protocol offers no real advantage over 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 IRIS-XPC [9]. In such a case, IRIS-XPC is RECOMMENDED to be used as
similarly effecient and would offer greater reponse sizes and allow it would be similarly or more efficient and would offer greater
better security. response 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 15, line 13 skipping to change at page 10, line 48
See Section 7.1.3. See Section 7.1.3.
7. IANA Considerations 7. IANA Considerations
7.1. Registrations 7.1. Registrations
7.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 6.1 and [3]. Status: permanent
Character encoding considerations: as defined in RFC2396 [5]. URL scheme syntax: defined in [3].
Character encoding considerations: as defined in RFC 3986 [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 8. 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.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 UDP Port Number: 715
Message Formats, Types, Opcodes, and Sequences: defined in Section 3 Message Formats, Types, Opcodes, and Sequences: defined in Sections 3
and Section 3.1. and 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>
skipping to change at page 16, line 18 skipping to change at page 12, line 4
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 8. 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
8. 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 confidentiality. Any application mechanisms for authentication or confidentiality. Any application
with these needs must provide out of band mechanisms (e.g., IPSec), with these needs must provide out-of-band mechanisms (e.g., IPsec),
or use the IRIS transfer protocols that provides such capabilities, or use the IRIS transfer protocols that provide such capabilities,
such as IRIS-XPC [9]. such as IRIS-XPC [9].
Due to this lack of security, it is possible for an attacker to alter Due to this lack of security, it is possible for an attacker to alter
IRIS-LWZ messages sent from the client to the server and from the IRIS-LWZ messages sent from the client to the server and from the
server to the client. Such an attack can result in denying usage of server to the client. Such an attack can result in denying usage of
an IRIS service or in supplying false information to end users and an IRIS service or in supplying false information to end users and
many other scenarios. many other scenarios.
Because IRIS-LWZ is a UDP based protocol, it is possible for servers Because IRIS-LWZ is a UDP-based protocol, it is possible for servers
using IRIS-LWZ to be used in a type of distributed denial of service using IRIS-LWZ to be used in a type of distributed denial-of-service
attack known as a reflection attack. This type of attack affects attack known as a reflection attack. This type of attack affects
other types of UDP using protocols, such as DNS. Server operators other types of UDP-using protocols, such as DNS. Server operators
should be prepared to apply the same methods used for mitigating should be prepared to apply the same methods used for mitigating
reflection attacks with other protocols, such as DNS, when using reflection attacks with other protocols, such as DNS, when using
IRIS-LWZ. All operators should follow the advice given in BCP 38 IRIS-LWZ. All operators should follow the advice given in BCP 38
[7]. [7].
IRIS-LWZ uses transaction IDs in the payload descriptors to better IRIS-LWZ uses transaction IDs in the payload descriptors to better
enable a client to match a response to a request. By randomizing the enable a client to match a response to a request. By randomizing the
transaction IDs being used (i.e. not using sequential numbers), transaction IDs being used (i.e., not using sequential numbers),
attackers flooding the network with a large amount of spoofed packets attackers flooding the network with a large amount of spoofed packets
have a lesser chance of succeeding with the attack. This measure is have a lesser chance of succeeding with the attack. This measure is
not guaranteed to thwart any such attack. Client implementers MUST not guaranteed to thwart any such attack. Client implementers MUST
take appropriate measures when ignoring this advice. take appropriate measures when ignoring this advice.
9. Normative References 9. References
9.1. 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
ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>. 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[3] Newton, A. and M. Sanz, "Internet Registry Information [3] Newton, A. and M. Sanz, "IRIS: The Internet Registry
Service", RFC 3891, January 2004. Information Service (IRIS) Core Protocol", RFC 3981, January
2005.
[4] Daigle, L. and A. Newton, "Domain-Based Application Service [4] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005. Service (DDDS)", RFC 3958, January 2005.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
August 1998. January 2005.
[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] Ferguson, P. and D. Senie, "Network Ingress Filtering: [7] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[8] Newton, A., "A Common Schema for Internet Registry Information [8] Newton, A., "A Common Schema for Internet Registry Information
Service Transfer Protocols", Service Transfer Protocols", RFC 4991, August 2007.
draft-ietf-crips-iris-common-transport-00 (work in progress),
April 2005.
[9] Newton, A., "XML Pipelining with Chunks for the Information [9] Newton, A., "XML Pipelining with Chunks for the Internet
Registry Information Service", draft-ietf-crips-iris-xpc-05 Registry Information Service", RFC 4992, August 2007.
(work in progress), January 2007.
9.2. Informative References
[10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", [10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers",
RFC 1166, July 1990. RFC 1166, July 1990.
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 contains either 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
are contained within parenthesis. are contained within parentheses.
The following example demonstrates an IRIS client requesting a lookup The following example demonstrates an IRIS client requesting a lookup
of 'AUP' in the 'local' entity class of a 'dreg1' registry. The of 'AUP' in the 'local' entity class of a 'dreg1' registry. The
client passes a bag with the search request. The server responds client passes a bag (see [3]) with the search request. The server
with a 'nameNotFound' response and an explanation. responds with a 'nameNotFound' response and an explanation.
C: (request packet) C: (request packet)
C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml) C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml)
C: 0x03 0xA4 (transaction ID=932) C: 0x03 0xA4 (transaction ID=932)
C: 0x05 0xDA (maximum response size=1498) C: 0x05 0xDA (maximum response size=1498)
C: 0x09 (authority length=9) C: 0x09 (authority length=9)
C: (authority="localhost") C: (authority="localhost")
C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74 C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74
C: (IRIS XML request) C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1" C: <request xmlns="urn:ietf:params:xml:ns:iris1"
skipping to change at page 20, line 39 skipping to change at page 15, line 44
S: (response packet) S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml) S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x03 0xA4 (transaction ID=932) S: 0x03 0xA4 (transaction ID=932)
S: (IRIS XML response) S: (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer></iris:answer> S: <iris:resultSet><iris:answer></iris:answer>
S: <iris:nameNotFound><iris:explanation language="en-US"> S: <iris:nameNotFound><iris:explanation language="en-US">
S: The name 'AUP' is not found in 'local'.</iris:explanation> S: The name 'AUP' is not found in 'local'.</iris:explanation>
S: </iris:nameNotFound></iris:resultSet></iris:response> S: </iris:nameNotFound></iris:resultSet></iris:response>
Figure 4: Example 1 Example 1
The following example demonstrates an IRIS client requesting domain The following example demonstrates an IRIS client requesting domain
availability information for 'milo.example.com'. The server responds availability information for 'milo.example.com'. The server responds
that the domain is assigned and active. that the domain is assigned and active.
C: (request packet) C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x0B 0xE7 (transaction ID=3047) C: 0x0B 0xE7 (transaction ID=3047)
C: 0x0F 0xA0 (maximum response size=4000) C: 0x0F 0xA0 (maximum response size=4000)
C: 0x0B (authority length=11) C: 0x0B (authority length=11)
C: (authority="example.com") C: (authority="example.com")
skipping to change at page 21, line 38 skipping to change at page 16, line 41
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"> S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer><domain S: <iris:resultSet><iris:answer><domain
S: authority="example.com" registryType="dchk1" S: authority="example.com" registryType="dchk1"
S: entityClass="domain-name" entityName="tcs-com-1" S: entityClass="domain-name" entityName="tcs-com-1"
S: temporaryReference="true" S: temporaryReference="true"
S: xmlns="urn:ietf:params:xml:ns:dchk1"><domainName> S: xmlns="urn:ietf:params:xml:ns:dchk1"><domainName>
S: milo.example.com</domainName><status><assignedAndActive/> S: milo.example.com</domainName><status><assignedAndActive/>
S: </status></domain></iris:answer> S: </status></domain></iris:answer>
S: </iris:resultSet></iris:response> S: </iris:resultSet></iris:response>
Figure 5: Example 2 Example 2
The following example demonstrates an IRIS client requesting domain The following example demonstrates an IRIS client requesting domain
availability information for felix.example.net, hobbes.example.net, availability information for felix.example.net, hobbes.example.net,
and daffy.example.net. The client does not support responses and daffy.example.net. The client does not support responses
compressed with DEFLATE and the maximum UDP packet it can safely compressed with DEFLATE, and the maximum UDP packet it can safely
receive is 498 octets. The server responds with size information receive is 498 octets. The server responds with size information
indicating that it would take 1211 octets to provide an answer. indicating that it would take 1211 octets to provide an answer.
C: (request packet) C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml) C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x7E 0x8A (transaction ID=32394) C: 0x7E 0x8A (transaction ID=32394)
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
skipping to change at page 22, line 38 skipping to change at page 17, line 44
C: </request> C: </request>
S: (response packet) S: (response packet)
S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si) S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si)
S: 0x7E 0x8A (transaction ID=32394) S: 0x7E 0x8A (transaction ID=32394)
S: (Size Information XML response) S: (Size Information XML response)
S: <responseSize xmlns="urn:ietf:params:xml:ns:iris-transport"> S: <responseSize xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <octets>1211</octets> S: <octets>1211</octets>
S: </responseSize> S: </responseSize>
Figure 6: Example 3 Example 3
The following example illustrates an IRIS client requesting the The following example illustrates an IRIS client requesting the
version information from a server, and the server returning the version information from a server, and the server returning the
verion information. version information.
C: (request packet) C: (request packet)
C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi) C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi)
C: 0x2E 0x9C (transaction ID=11932) C: 0x2E 0x9C (transaction ID=11932)
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)
skipping to change at page 23, line 26 skipping to change at page 18, line 29
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.lwz1"> 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 Example 4
Appendix B. Contributors Appendix B. Contributors
Substantive contributions to this document have been provided by the Substantive contributions to this document have been provided by the
members of the IETF's CRISP Working Group, especially Milena Caires members of the IETF's CRISP Working Group, especially Milena Caires
and David Blacka. and David Blacka.
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: andy@hxr.us EMail: andy@hxr.us
URI: http://www.verisignlabs.com/ URI: http://www.verisignlabs.com/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
skipping to change at page 26, line 45 skipping to change at page 19, 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.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 67 change blocks. 
158 lines changed or deleted 131 lines changed or added

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