draft-ietf-crisp-iris-lwz-05.txt   draft-ietf-crisp-iris-lwz-06.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: August 11, 2006 February 7, 2006 Expires: November 26, 2006 May 25, 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-05 draft-ietf-crisp-iris-lwz-06
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 August 11, 2006. This Internet-Draft will expire on November 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 12
6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 13 6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 13
6.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 Application Protocol Label . . . . . . . . . . . . . . . . 13 6.2. Application Protocol Label . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
7.1.1 URI Scheme Registration . . . . . . . . . . . . . . . 14 7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 14
7.1.2 Well-known UDP Port Registration . . . . . . . . . . . 14 7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 14
7.1.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 15 7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17
A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 22
B. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24 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 3..261 0..n octets 2 2 2 2 3 or 6..261* 0..n
* In request packets, the payload descriptor can vary in length
from 6 to 261 octets (i.e. 6..261). In response packets, the
payload descriptor is always 3 octets.
(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
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 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
skipping to change at page 6, line 18 skipping to change at page 6, line 22
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.
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
skipping to change at page 6, line 45 skipping to change at page 7, line 5
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 us 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 [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.
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.
skipping to change at page 7, line 28 skipping to change at page 7, line 34
bit 4 - deflate supported ('DS' flag) - If 1, the sender of this bit 4 - deflate supported ('DS' flag) - If 1, the sender of this
packet supports compression using the DEFLATE algorithm. When packet supports compression using the DEFLATE algorithm. When
this bit is 0 in a request, the payload of the response MUST NOT this bit is 0 in a request, the payload of the response MUST NOT
be compressed with DEFLATE. be compressed with DEFLATE.
bit 5 - reserved - This MUST be 0. bit 5 - reserved - This MUST be 0.
bits 6 and 7 - The value of these bits indicate payload types bits 6 and 7 - The value of these bits indicate payload types
(Section 3.1.4) ('PT' field). (Section 3.1.4) ('PT' field).
3.1.4 Payload Types 3.1.4. Payload Types
A payload type indicates the type of content in the UDP packet A payload type indicates the type of content in the UDP packet
following the payload descriptor. Some payload types have no meaning following the payload descriptor. Some payload types have no meaning
in request packets, and some payload types differ in meaning between in request packets, and some payload types differ in meaning between
requests and responses. Some payload types indicate an empty requests and responses. Some payload types indicate an empty
payload. payload.
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-
skipping to change at page 8, line 10 skipping to change at page 8, line 15
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.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 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.
<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 1. In response to a version information request (i.e. the PT flag is
is set to 'vi'). 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 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.
The definition of octet size for the 'requestSizeOctets' and The definition of octet size for the 'requestSizeOctets' and
'responseSizeOctets' attributes of the <tranferProtocol> element are 'responseSizeOctets' attributes of the <tranferProtocol> element are
defined in Section 3.1.6. defined in Section 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 comformant to the
XML defined in [7] and use the <size> element as the root element. XML defined in [7] 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 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:
skipping to change at page 9, line 38 skipping to change at page 9, line 39
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 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 5. When reserved bits in the payload descriptor are set to values
values other than zero. 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 13, line 10 skipping to change at page 13, line 10
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.
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
mappings. mappings.
6.1 URI Scheme 6.1. URI Scheme
See Section 7.1.1. See Section 7.1.1.
6.2 Application Protocol Label 6.2. Application Protocol Label
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]. 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
skipping to change at page 14, line 32 skipping to change at page 14, line 32
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: 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>
7.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 8. Security Considerations: defined in Section 8.
Relevant Publications: IRIS [3]. Relevant Publications: IRIS [3].
skipping to change at page 16, line 13 skipping to change at page 16, line 13
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 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.
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
attack known as a reflection attack. This type of attack affects
other types of UDP using protocols, such as DNS. Server operators
should be prepared to apply the same methods used for mitigating
reflection attacks with other protocols, such as DNS, when using
IRIS-LWZ.
9. 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 17, line 5 skipping to change at page 17, line 5
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[7] Newton, A., "A Common Schema for Internet Registry Information [7] Newton, A., "A Common Schema for Internet Registry Information
Service Transfer Protocols", Service Transfer Protocols",
draft-ietf-crips-iris-common-transport-00 (work in progress), draft-ietf-crips-iris-common-transport-00 (work in progress),
April 2005. April 2005.
[8] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", [8] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers",
RFC 1166, July 1990. RFC 1166, July 1990.
Author's Address
Andrew L. Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
Email: andy@hxr.us
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
are contained within parenthesis. are contained within parenthesis.
skipping to change at page 24, line 5 skipping to change at page 23, line 5
S: </versions> S: </versions>
Figure 7: Example 4 Figure 7: 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
Andrew L. Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
Email: andy@hxr.us
URI: http://www.verisignlabs.com/
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 27 change blocks. 
52 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/