< draft-ietf-crisp-iris-lwz-07.txt		draft-ietf-crisp-iris-lwz-08.txt >
	Network Working Group A. Newton		Network Working Group A. Newton
	Internet-Draft VeriSign, Inc.		Internet-Draft VeriSign, Inc.
	Expires: July 13, 2007 January 9, 2007		Intended status: Standards Track March 5, 2007
			Expires: September 6, 2007
	A Lightweight UDP Transfer Protocol for the the Internet Registry		A Lightweight UDP Transfer Protocol for the the Internet Registry
	Information Service		Information Service
	draft-ietf-crisp-iris-lwz-07		draft-ietf-crisp-iris-lwz-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July 13, 2007.		This Internet-Draft will expire on September 6, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes a lightweight UDP transfer protocol for the		This document describes a lightweight UDP transfer protocol for the
	Internet Registry Information Service (IRIS). This transfer protocol		Internet Registry Information Service (IRIS). This transfer protocol
	uses a single packet for every request and response, and optionally		uses a single packet for every request and response, and optionally
	employs compression over the contents of the packet.		employs compression over the contents of the packet.
	Table of Contents		Table of Contents
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 26 ¶
	3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5		3.1. Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5
	3.1.1. Payload Request Descriptor . . . . . . . . . . . . . . 5		3.1.1. Payload Request Descriptor . . . . . . . . . . . . . . 5
	3.1.2. Payload Response Descriptor . . . . . . . . . . . . . 6		3.1.2. Payload Response Descriptor . . . . . . . . . . . . . 6
	3.1.3. Payload Header . . . . . . . . . . . . . . . . . . . . 7		3.1.3. Payload Header . . . . . . . . . . . . . . . . . . . . 7
	3.1.4. Payload Types . . . . . . . . . . . . . . . . . . . . 7		3.1.4. Payload Types . . . . . . . . . . . . . . . . . . . . 7
	3.1.5. Version Information . . . . . . . . . . . . . . . . . 8		3.1.5. Version Information . . . . . . . . . . . . . . . . . 8
	3.1.6. Size Information . . . . . . . . . . . . . . . . . . . 9		3.1.6. Size Information . . . . . . . . . . . . . . . . . . . 9
	3.1.7. Other Information . . . . . . . . . . . . . . . . . . 9		3.1.7. Other Information . . . . . . . . . . . . . . . . . . 9
	4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Internationalization Considerations . . . . . . . . . . . . . 12		5. Internationalization Considerations . . . . . . . . . . . . . 13
	6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 13		6. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 14
	6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13		6.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 14
	6.2. Application Protocol Label . . . . . . . . . . . . . . . . 13		6.2. Application Protocol Label . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 14		7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 15
	7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 14		7.1.1. URI Scheme Registration . . . . . . . . . . . . . . . 15
	7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 14		7.1.2. Well-known UDP Port Registration . . . . . . . . . . . 15
	7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 15		7.1.3. S-NAPTR Registration . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 16		9. Normative References . . . . . . . . . . . . . . . . . . . . . 18
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19
	Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 23		Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 24
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
	Intellectual Property and Copyright Statements . . . . . . . . . . 25		Intellectual Property and Copyright Statements . . . . . . . . . . 26
	1. Introduction		1. Introduction
	Using Straightforward Name Authority Pointers [4], IRIS has the		Using Straightforward Name Authority Pointers [4], IRIS has the
	ability to define the use of multiple application transports or		ability to define the use of multiple application transports or
	transfer protocols for different types of registry services, all at		transfer protocols for different types of registry services, all at
	the descretion of the server operator. The UDP transfer protocol		the descretion of the server operator. The UDP transfer protocol
	defined in this document is completely independent of the registry		defined in this document is completely independent of the registry
	types for which it can carry data.		types for which it can carry data.
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	+------------+---------+		+------------+---------+
	field | payload | payload |		field | payload | payload |
	| descriptor | |		| descriptor | |
	+------------+---------+		+------------+---------+
	octets 3 or 6..261* 0..n		octets 3 or 6..261* 0..n
	* In request packets, the payload descriptor can vary in length		* In request packets, the payload descriptor can vary in length
	from 6 to 261 octets (i.e. 6..261). In response packets, the		from 6 to 261 octets (i.e. 6..261). In response packets, the
	payload descriptor is always 3 octets.		payload descriptor is always 3 octets.
			IRIS-LWZ Packet
	(where "src port" means source port and "dest port" means destination		(where "src port" means source port and "dest port" means destination
	port).		port).
	Each IRIS-LWZ query or response is contained in a single UDP packet.		Each IRIS-LWZ query or response is contained in a single UDP packet.
	Servers MUST be prepared to accepted packets as large as 4000 octets,		Servers MUST be prepared to accepted packets as large as 4000 octets,
	and clients MUST NOT send packets larger than 4000 octets.		and clients MUST NOT send packets larger than 4000 octets.
	3.1. Payload Descriptor		3.1. Payload Descriptor
	The payload descriptor has two different formats, one for a request		The payload descriptor has two different formats, one for a request
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 46 ¶
	The payload descriptor for request packets varies from 6 to 261		The payload descriptor for request packets varies from 6 to 261
	octets in lenght and has the following format:		octets in lenght and has the following format:
	+--------+-------------+----------+-----------+-----------+		+--------+-------------+----------+-----------+-----------+
	field | header | transaction | maximum | authority | authority |		field | header | transaction | maximum | authority | authority |
	| | ID | response | length | |		| | ID | response | length | |
	| | | length | | |		| | | length | | |
	+--------+-------------+----------+-----------+-----------+		+--------+-------------+----------+-----------+-----------+
	octets 1 2 2 1 0..255		octets 1 2 2 1 0..255
			Request Payload Descriptor
	These fields have the following meanings:		These fields have the following meanings:
	header - as described in Section 3.1.3.		o header - as described in Section 3.1.3.
	transaction ID - a 16 bit value identifying the transaction. This		o transaction ID - a 16 bit value identifying the transaction. This
	value will be returned in the payload response descriptor		value will be returned in the payload response descriptor
	(Section 3.1.2) and can be used by clients to match requests with		(Section 3.1.2) and can be used by clients to match requests with
	responses. Clients SHOULD NOT use sequential values (See		responses. Clients SHOULD NOT use sequential values (See
	Section 8). Clients MUST NOT set all the bits in this value to 1		Section 8). Clients MUST NOT set all the bits in this value to 1
	(i.e. use a value of 0xFFFF).		(i.e. use a value of 0xFFFF).
	maximum response length - the total length of the UDP packet (i.e.		o maximum response length - the total length of the UDP packet (i.e.
	UDP header length + payload descriptor length + XML payload		UDP header length + payload descriptor length + XML payload
	length) that should not be exceeded when responding to this		length) that should not be exceeded when responding to this
	request. If the server cannot provide a response that is equal to		request. If the server cannot provide a response that is equal to
	or less than this value, then it MUST respond with size		or less than this value, then it MUST respond with size
	information (Section 3.1.6).		information (Section 3.1.6).
	authority length - the length of the authority field in this		o authority length - the length of the authority field in this
	payload descriptor.		payload descriptor.
	authority - a string of octets describing the authority against		o authority - a string of octets describing the authority against
	wich this request is to be executed. See [3] for the definition		wich this request is to be executed. See [3] for the definition
	and description of an authority. The number of octets in this		and description of an authority. The number of octets in this
	string MUST be no more and no less than the number specified by		string MUST be no more and no less than the number specified by
	the authority length.		the authority length.
	3.1.2. Payload Response Descriptor		3.1.2. Payload Response Descriptor
	The payload descriptor for response packets is always 3 octets and		The payload descriptor for response packets is always 3 octets and
	consists of a payload header (Section 3.1.3) and a transaction ID.		consists of a payload header (Section 3.1.3) and a transaction ID.
	+--------+-------------+		+--------+-------------+
	field | header | transaction |		field | header | transaction |
	| | ID |		| | ID |
	+--------+-------------+		+--------+-------------+
	octets 1 2		octets 1 2
			Response Payload Descriptor
	The purpose of the transaction ID is to allow clients to match		The purpose of the transaction ID is to allow clients to match
	requests to responses. A value of 0xFFFF is reserved for server use.		requests to responses. A value of 0xFFFF is reserved for server use.
	The value of the transaction ID is as follows:		The value of the transaction ID is as follows:
	1. If the transaction ID in the corresponding request could not be		1. If the transaction ID in the corresponding request could not be
	read due to truncation, servers MUST use a transaction ID with		read due to truncation, servers MUST use a transaction ID with
	all bits set to 1 (i.e. a value of OxFFFF) and send a descriptor		all bits set to 1 (i.e. a value of OxFFFF) and send a descriptor
	error (see Section 3.1.7).		error (see Section 3.1.7).
	2. If the transaction ID in the corresponding request is a value of		2. If the transaction ID in the corresponding request is a value of
	0xFFFF, servers MUST us a transaction ID of 0xFFFF and send a		0xFFFF, servers MUST use a transaction ID of 0xFFFF and send a
	descriptor error (see Section 3.1.7).		descriptor error (see Section 3.1.7).
	3. Otherwise, the transaction ID MUST be the value of the		3. Otherwise, the transaction ID MUST be the value of the
	transaction ID of the corresponding request.		transaction ID of the corresponding request.
	3.1.3. Payload Header		3.1.3. Payload Header
	The bits of the payload header are ordered according to RFC 1166		The bits of the payload header are ordered according to RFC 1166
	[10], where bit 0 is the most significant and bit 7 is the least		[10], where bit 0 is the most significant and bit 7 is the least
	significant. Each bit in the one octet payload header has the		significant. Each bit in the one octet payload header has the
	following meaning:		following meaning:
	bits 0 and 1 - version number ('V' field) - If 0 (both bits are		o bits 0 and 1 - version number ('V' field) - If 0 (both bits are
	zero), the protocol is the version defined in this document.		zero), the protocol is the version defined in this document.
	Otherwise, the rest of the bits in the header and the payload may		Otherwise, the rest of the bits in the header and the payload may
	be interpreted as another version.		be interpreted as another version.
	bit 2 - request/response flag ('RR' flag) - If 0, this packet is a		o bit 2 - request/response flag ('RR' flag) - If 0, this packet is a
	request (Section 3.1.1) packet. If 1, this packet is a response		request (Section 3.1.1) packet. If 1, this packet is a response
	(Section 3.1.2) packet.		(Section 3.1.2) packet.
	bits 3 - payload deflated ('PD' flag) - If 1, the payload is		o bits 3 - payload deflated ('PD' flag) - If 1, the payload is
	compressed using the DEFLATE [1] algorithm.		compressed using the DEFLATE [1] algorithm.
	bit 4 - deflate supported ('DS' flag) - If 1, the sender of this		o bit 4 - deflate supported ('DS' flag) - If 1, the sender of this
	packet supports compression using the DEFLATE algorithm. When		packet supports compression using the DEFLATE algorithm. When
	this bit is 0 in a request, the payload of the response MUST NOT		this bit is 0 in a request, the payload of the response MUST NOT
	be compressed with DEFLATE.		be compressed with DEFLATE.
	bit 5 - reserved - This MUST be 0.		o bit 5 - reserved - This MUST be 0.
	bits 6 and 7 - The value of these bits indicate payload types		o bits 6 and 7 - The value of these bits indicate payload types
	(Section 3.1.4) ('PT' field).		(Section 3.1.4) ('PT' field).
	3.1.4. Payload Types		3.1.4. Payload Types
	A payload type indicates the type of content in the UDP packet		A payload type indicates the type of content in the UDP packet
	following the payload descriptor. Some payload types have no meaning		following the payload descriptor. Some payload types have no meaning
	in request packets, and some payload types differ in meaning between		in request packets, and some payload types differ in meaning between
	requests and responses. Some payload types indicate an empty		requests and responses. Some payload types indicate an empty
	payload.		payload.
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	The intent of IRIS-LWZ is to utilize UDP for IRIS requests and		The intent of IRIS-LWZ is to utilize UDP for IRIS requests and
	responses when UDP is appropriate. Not all IRIS requests and		responses when UDP is appropriate. Not all IRIS requests and
	responses will be able to utilize UDP and may require the use of		responses will be able to utilize UDP and may require the use of
	other transfer protocols (i.e. IRIS-XPC [9] and/or BEEP). The		other transfer protocols (i.e. IRIS-XPC [9] and/or BEEP). The
	following strategy SHOULD be used:		following strategy SHOULD be used:
	1. If a request requires authentication, confidentiality, or other		1. If a request requires authentication, confidentiality, or other
	security, use another transfer protocol. IRIS-XPC [9] is		security, use another transfer protocol. IRIS-XPC [9] is
	RECOMMENDED.		RECOMMENDED.
	2. If a request is less than or equal to 4000 octets, send it		2. The maximum packet size should be calculated as follows:
	uncompressed.
	3. If a request can be compressed to a size less than or equal to		1. If the path MTU is unknown, the maximum packet size MUST be
	4000 octets, send the request using compression. Otherwise use		1500 octets.
	another transfer protocol. In cases where another transfer
	protocol is needed, IRIS-XPC [9] is RECOMMENDED.
	4. If a request yields a size error, send the request with another		2. If the path MTU is known, the maximum packet size MUST NOT
			exceed the path MTU and MUST NOT exceed 4000 octets.
			3. If a request is less than or equal to the maximum packet size,
			send it uncompressed.
			4. If a request can be compressed to a size less than or equal to
			the maximum packet size, send the request using compression.
			Otherwise use another transfer protocol. In cases where another
			transfer protocol is needed, IRIS-XPC [9] is RECOMMENDED.
			5. If a request yields a size error, send the request with another
	transfer protocol. IRIS-XPC [9] is RECOMMENDED.		transfer protocol. IRIS-XPC [9] is RECOMMENDED.
			If a client does not know the path MTU or does not use the packet
			size recommendations above, the client MUST allocate or have
			allocated dedicated network resources that will ensure fairness to
			other network packets and avoid packet fragmentation.
	For retransmission of requests considered to be unanswered, a client		For retransmission of requests considered to be unanswered, a client
	SHOULD retransmit using a timeout value initially set to 1 second.		SHOULD retransmit using a timeout value initially set to 1 second.
	This timeout value SHOULD be doubled for every retransmission, and it		This timeout value SHOULD be doubled for every retransmission, and it
	a client SHOULD not retransmit any request once the timeout value has		a client SHOULD not retransmit any request once the timeout value has
	reached 60 seconds.		reached 60 seconds. If the next query the client sends is to the
			same server, it SHOULD start with the last timeout value used.
	Additionally, if a client intends thousands of requests to the same		Clients that use timeout values other than the recommendations above
	server in a short amount of time, this protocol offers no real		MUST allocate or have allocated dedicate network resources that will
	advantage over IRIS-XPC [9]. In such a case, IRIS-XPC should be used		ensure fairness to other network packets and avoid network
	as it would be similarly effecient and would offer greater reponse		congestion.
	sizes and allow better security.
			Clients MUST NOT have more than one outstanding request (i.e. a
			unanswered request that has not timed out) at a time unless they
			allocate or have been allocated dedicated network bandwidth and
			resources reserved specifically for this purpose.
			Finally, if a client intends multiple requests to the same server in
			a short amount of time, this protocol offers no real advantage over
			IRIS-XPC [9]. In such a case, IRIS-XPC should be used as it would be
			similarly effecient and would offer greater reponse sizes and allow
			better security.
	5. Internationalization Considerations		5. Internationalization Considerations
	XML processors are obliged to recognize both UTF-8 and UTF-16 [2]		XML processors are obliged to recognize both UTF-8 and UTF-16 [2]
	encodings. Use of the XML defined by [8] MUST NOT use any other		encodings. Use of the XML defined by [8] MUST NOT use any other
	character encodings other than UTF-8 or UTF-16.		character encodings other than UTF-8 or UTF-16.
	6. IRIS Transport Mapping Definitions		6. IRIS Transport Mapping Definitions
	This section lists the definitions required by IRIS [3] for transport		This section lists the definitions required by IRIS [3] for transport
	skipping to change at page 19, line 39 ¶		skipping to change at page 20, line 39 ¶
	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		Figure 4: 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)
	skipping to change at page 20, line 38 ¶		skipping to change at page 21, line 38 ¶
	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		Figure 5: 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)
	skipping to change at page 21, line 38 ¶		skipping to change at page 22, line 38 ¶
	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		Figure 6: 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.		verion 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)
	skipping to change at page 22, line 26 ¶		skipping to change at page 23, line 26 ¶
	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		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		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/
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
			OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 25, line 29 ¶		skipping to change at page 26, line 45 ¶
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2007). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 33 change blocks.
	65 lines changed or deleted		96 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/