draft-ietf-crisp-iris-lwz-01.txt   draft-ietf-crisp-iris-lwz-02.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: July 26, 2005 January 25, 2005 Expires: October 31, 2005 April 29, 2005
A Lightweight UDP Transport for the the Internet Registry A Lightweight UDP Transfer Protocol for the the Internet Registry
Information Service Information Service
draft-ietf-crisp-iris-lwz-01 draft-ietf-crisp-iris-lwz-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. 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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 26, 2005. This Internet-Draft will expire on October 31, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a lightweight UDP transport for the Internet This document describes a lightweight UDP transfer protocol for the
Registry Information Service (IRIS). Internet Registry Information Service (IRIS).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4
3. UDP Transport . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Use of IRIS-LWZ . . . . . . . . . . . . . . . . . . . . . 5 3.1 Payload Descriptor . . . . . . . . . . . . . . . . . . . . 5
3.1.1 IRIS-LWZ Packet Formats . . . . . . . . . . . . . . . 5 3.1.1 Payload Request Descriptor . . . . . . . . . . . . . . 5
3.2 Formal XML Syntax . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Payload Response Descriptor . . . . . . . . . . . . . 6
3.3 IRIS Transport Mapping Definitions . . . . . . . . . . . . 10 3.1.3 Payload Header . . . . . . . . . . . . . . . . . . . . 6
3.3.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . 10 4. Internationalization Considerations . . . . . . . . . . . . . 10
3.3.2 Application Protocol Label . . . . . . . . . . . . . . 11 5. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 11
3.4 Registrations . . . . . . . . . . . . . . . . . . . . . . 11 5.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 URI Scheme Registration . . . . . . . . . . . . . . . 11 5.2 Application Protocol Label . . . . . . . . . . . . . . . . 11
3.4.2 Well-known UDP Port Registration . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
3.4.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12 6.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 12
4. Internationalization Considerations . . . . . . . . . . . . . 13 6.1.1 URI Scheme Registration . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1.2 Well-known UDP Port Registration . . . . . . . . . . . 12
5.1 XML Namespace URN Registration . . . . . . . . . . . . . . 14 6.1.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12
5.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Normative References . . . . . . . . . . . . . . . . . . . . . 14
7. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 20
1. Introduction 1. Introduction
Using S-NAPTR, IRIS has the ability to define the use of multiple Using S-NAPTR [4], IRIS has the ability to define the use of multiple
transports for different types of registry services, all at the application transports or transfer protocols for different types of
descretion of the server operator. The UDP transport defined in this registry services, all at the descretion of the server operator. The
document is completely modular and may be used by any registry types. UDP transfer protocol defined in this document is completely modular
and may be used by any registry types.
2. Document Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [8].
3. UDP Transport
The binding of this UDP transport to IRIS is called IRIS-LWZ (for The binding of this UDP transfer protocol to IRIS is called IRIS-LWZ
IRIS Lightweight using Compression). (for IRIS Lightweight using Compression).
IRIS-LWZ is composed of two parts, a binary payload descriptor and an IRIS-LWZ is composed of two parts, a binary payload descriptor and an
request/response transaction payload. The request/response request/response transaction payload. The request/response
transaction payload may be compressed using the DEFLATE algorithm. transaction payload may be compressed using the DEFLATE [1]
algorithm.
3.1 Use of IRIS-LWZ 2. Document Terminology
3.1.1 IRIS-LWZ Packet Formats The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [6].
3. Packet Format
The UDP packet format for IRIS-LWZ is as follows: The UDP packet format for IRIS-LWZ is as follows:
+--------+--------------+----------+--------+------------+---------+ +------+------+----------+--------+------------+---------+
field | source | destination | checksum | UDP | payload | payload | field | src | dest | checksum | UDP | payload | payload |
| port | port | | length | descriptor | | | port | port | | length | descriptor | |
+--------+--------------+----------+--------+------------+---------+ +------+------+----------+--------+------------+---------+
octets 2 2 2 2 1..261 0..n octets 2 2 2 2 1..261 0..n
Each IRIS-LWZ query and response is contained in a single UDP packet. (where "src port" means source port and "dest port" means destination
port).
3.1.1.1 Payload Descriptor Each IRIS-LWZ query or response is contained in a single UDP packet.
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.1.1.3. payload header described in Section 3.1.3.
3.1.1.1.1 Payload Request Descriptor 3.1.1 Payload Request Descriptor
The payload descriptor for request packets has the following format: The payload descriptor for request packets has the following format:
+--------+-------------+-------------------+-----------+-----------+ +--------+-------------+----------+-----------+-----------+
field | header | transaction | maximum response | authority | authority | field | header | transaction | maximum | authority | authority |
| | ID | length | length | | | | ID | response | length | |
+--------+-------------+-------------------+-----------+-----------+ | | | length | | |
+--------+-------------+----------+-----------+-----------+
octets 1 2 2 1 0..255 octets 1 2 2 1 0..255
These fields have the following meanings: These fields have the following meanings:
header - as described in Section 3.1.1.1.3.
header - as described in Section 3.1.3.
transaction ID - a 16 bit value identifying the transaction. This transaction ID - a 16 bit value identifying the transaction. This
value will be returned in the payload response descriptor (Section value will be returned in the payload response descriptor
3.1.1.1.2) and can be used by clients to match requests with (Section 3.1.2) and can be used by clients to match requests with
responses. Clients SHOULD pick the value randomly and SHOULD NOT responses. Clients SHOULD pick the value randomly and SHOULD NOT
use sequences of 16 bit values. Clients MUST NOT set all the bits use sequences of 16 bit values. Clients MUST NOT set all the bits
in this value to 1 (i.e. use a value of 0xFFFF). in this value to 1 (i.e. use a value of 0xFFFF).
maximum response length - the total length of the UDP packet (i.e. maximum response length - the total length of the UDP packet (i.e.
UDP header length + payload descriptor length + XML payload UDP header length + payload descriptor length + XML payload
length) that should not be exceeded when responding to this length) that should not be exceeded when responding to this
request. If the server cannot provide a response that is equal to request. If the server cannot provide a response that is equal to
or less than this value, then it MUST respond with a size error or less than this value, then it MUST respond with size
(Section 3.1.1.1.3.1.2). information (Section 3.1.3.1.2).
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 no more and no less octets describing the
authority against wich this request is to be executed. See [5]
for the definition and description of an authority.
3.1.1.1.2 Payload Response Descriptor authority - a string of octets describing the authority against
wich this request is to be executed. See [3] for the definition
and description of an authority. The number of octets in this
string MUST be no more and no less than the number specified by
the authority length.
3.1.2 Payload Response Descriptor
The payload descriptor for response packets consists of a payload The payload descriptor for response packets consists of a payload
header (Section 3.1.1.1.3) and a transaction ID. header (Section 3.1.3) and a transaction ID.
+--------+-------------+ +--------+-------------+
field | header | transaction | field | header | transaction |
| | ID | | | ID |
+--------+-------------+ +--------+-------------+
octets 1 2 octets 1 2
The transaction ID MUST be the value of the transaction ID of the The transaction ID MUST be the value of the transaction ID of the
corresponding request. If the corresponding request did not contain corresponding request. If the corresponding request did not contain
a transaction ID, servers MUST use a transaction ID will all bits set a transaction ID, servers MUST use a transaction ID with all bits set
to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see
Section 3.1.1.1.3.1.3). Section 3.1.3.1.3).
3.1.1.1.3 Payload Header 3.1.3 Payload Header
Each bit in the 1 byte payload header has the following meaning: Each bit in the 1 byte payload header has the following meaning:
bit 7 - version - If 0, the protocol is the version defined in
this document. If 1, the rest of the bits in the header and the bits 7 and 6 - version number ('V' flag) - If 0 (both bits are
payload may be interpreted as another version. zero), the protocol is the version defined in this document.
bit 6 - request/response flag - If 0, this packet is a request Otherwise, the rest of the bits in the header and the payload may
(Section 3.1.1.1.1) packet. If 1, this packet is a response be interpreted as another version.
(Section 3.1.1.1.2) packet.
bits 5 - payload deflated - If 1, the payload is compressed using bit 5 - request/response flag ('RR' flag) - If 0, this packet is a
the DEFLATE algorithm. request (Section 3.1.1) packet. If 1, this packet is a response
bit 4 - deflate supported - If 1, the sender of this packet (Section 3.1.2) packet.
supports compression using the DEFLATE algorithm. When this bit
is 0 in a request, the payload of the response MUST NOT be bits 4 - payload deflated ('PD' flag) - If 1, the payload is
compressed with DEFLATE. compressed using the DEFLATE [1] algorithm.
bit 3 - reserved - This MUST be 0.
bit 3 - deflate supported ('DS' flag) - If 1, the sender of this
packet supports compression using the DEFLATE algorithm. When
this bit is 0 in a request, the payload of the response MUST NOT
be compressed with DEFLATE.
bit 2 - reserved - This MUST be 0. bit 2 - reserved - This MUST be 0.
bits 1 and 0 - The value of these bits indicate errors (Section
3.1.1.1.3.1).
3.1.1.1.3.1 Errors bits 1 and 0 - The value of these bits indicate payload types
(Section 3.1.3.1) ('PT' flag).
Though the payload descriptor header is the same for both request and 3.1.3.1 Payload types
response packets, errors only have context in responses. When an
error is indicated, the payload is not empty but contains information
relating to the error. This is described below.
The error values in binary are as follows: A payload type indicates the type of content in the UDP packet
00 - no error - the payload is a response to the request. following the payload descriptor. Some payload types have no meaning
01 - version error (see Section 3.1.1.1.3.1.1). in request packets, and some payload types differ in meaning between
10 - size error (see Section 3.1.1.1.3.1.2). requests and responses. Some payload types indicate an empty
11 - other error (see Section 3.1.1.1.3.1.3). payload.
3.1.1.1.3.1.1 Version Error The payload type values in binary are as follows:
This error indicates that either version of the header descriptor or 00 - xml payload ('xml' type). The payload is either an IRIS-
of the payload of the corresponding request is not understood by the based XML request or an IRIS-based XML response.
receiver. This response MUST have a payload consisting of an XML
instance conforming to the formal definition in Section 3.2 with a
<versions> root element.
The <versions> element has child elements that describe the 01 - version info ('vi' type). In a request packet, this payload
relationship between transport bindings, protocol versions, and data type indicates that the server is to respond with version
models. Each of these child elements has a 'protocolId' attribute information (Section 3.1.3.1.1), and that the payload is empty.
identifying the protocol they represent. In the context of IRIS, the In a response packet, this payload type indicates that the payload
protocol identifiers for these elements are as follows: is version information (Section 3.1.3.1.1).
<transportBinding> - the value "iris.lwz1" to indicate the
10 - size info ('si' type). This payload type has no meaning in a
request packet and is a descriptor error. In a response packet,
this payload type indicates that the payload is size information
(Section 3.1.3.1.2).
11 - other info ('oi' type). This payload type has no meaning in
a request packet and is a descriptor error. In a response packet,
this payload type indicates that the payload is other information
(Section 3.1.3.1.3).
3.1.3.1.1 Version Information
A payload type with version information ('vi') MUST be comformant to
the XML defined in [7] and use the <versions> element as the root
element.
In the context of IRIS-LWZ, the protocol identifiers for these
elements are as follows:
<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.
<application> - the XML namespace identifier for IRIS [3].
<dataModel> - the XML namespace identifier for IRIS registries. <dataModel> - the XML namespace identifier for IRIS registries.
The following is an example of an XML instance describing the version This document defines no extension identifiers and no authentication
error. mechanism identifiers.
<versions xmlns="urn:ietf:params:xml:ns:iris-transport"> Servers SHOULD send version information in the following cases:
<transportBinding protocolId="iris.lwz">
<application protocolId="urn:ietf:params:xml:ns:iris1">
<dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
<dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
</application>
</transportBinding>
</versions>
The protocols identified by the <transportBinding> element MUST only 1. In response to a version information request (i.e. the PT flag
indicate protocols running on the same port and IP transport as the is set to 'vi').
sender of the error. In other words, while a server operator may
also be running IRIS over BEEP, this XML instance is only intended to
instrument version negotiation for LWZ.
3.1.1.1.3.1.2 Size Error 2. The version in a payload descriptor header does not match a
version the server supports.
This error indicates that the size of the response exceeded the value 3. The IRIS-based XML payload does not match a version the server
of the maximum response length specified in the corresponding supports.
request. This response MUST have a payload consisting of an XML
instance conforming to the formal definition in Section 3.2 with a
<responseSize> root element. A server may indicate one of two
response size conditions by specifying the following child elements:
<exceedsMaximum> - this child element simply indicates that the
response size exceeded the maximum response size specified in the
corresponding request.
<octets> - this child element indicates that the response size
exceeded the maximum response size specified in the corresponding
request and provided the number of octets needed to provide a
response.
The following is an example of an XML instance describing the size The protocols identified by the <transferProtocol> element MUST only
error. indicate protocols running on the same socket as the sender of the
corresponding request. In other words, while a server operator may
also be running IRIS-XPC, this XML instance is only intended to
describe version negotiation for IRIS-LWZ.
<responseSize xmlns="urn:ietf:params:xml:ns:iris-transport"> 3.1.3.1.2 Size Information
<octets>1211</octets>
</responseSize>
3.1.1.1.3.1.3 Other Error A payload type with size information ('si') MUST be comformant to the
XML defined in [7] and use the <responseSize> element as the root
element.
This error indicates conditions where descriptive text is to be 3.1.3.1.3 Other Information
provided to properly diagnose the error. This response MUST have a
payload consisting of an XML instance conforming to the formal
definition in Section 3.2 with a <error> root element. This root
element may have <description> child elements describing the error,
each with a 'language' attribute indicated the language in which the
error is described. The <error> element has a 'type' attribute
indicating the type of error. The values for this attribute are as
follows:
'descriptor' - indicates there was an error decoding the
descriptor.
'payload' - indicates there was an error interpretting the
payload.
'system' - indicates that the receiver cannot process the request
due to a condition not related to this protocol.
'authority' - indicates that the intended authority specified in
the corresponding request is not served by the receiver.
'noDeflationSupport' - indicates that the receiver does not
support payloads that have been compressed with DEFLATE.
The following is an example of an XML instance describing this type A payload type with other information ('oi') MUST be comformant to
of error. the XML defined in [7] and use the <other> element as the root
element.
<error xmlns="urn:ietf:params:xml:ns:iris-transport" The values for the 'type' attribute of <other> are as follows:
type="system">
<description language="en">unavailable, come back later</description>
</error>
3.2 Formal XML Syntax 'descriptor-error' - indicates there was an error decoding the
descriptor. Servers SHOULD send a descriptor error in the
following cases:
The following is the XML Schema used to define IRIS-LWZ operations. 1. When a request is received with a payload type indicating size
See the following specifications: [1], [2], [3], [4]. information (i.e. the PT flag is 'si').
<?xml version="1.0"?> 2. When a request is received with a payload type indicating
<schema xmlns="http://www.w3.org/2001/XMLSchema" other information (i.e. the PT flag is 'oi').
xmlns:iristrans="urn:ietf:params:xml:ns:iris-transport"
targetNamespace="urn:ietf:params:xml:ns:iris-transport"
elementFormDefault="qualified" >
<annotation> 3. When a request is sent with an invalid transaction ID.
<documentation>
A schema for describing errors
for use by multiple transports.
</documentation>
</annotation>
<element name="versions"> 4. When reserved bits in the payload descriptor are set to
<complexType> values other than zero.
<sequence>
<element name="transportBinding">
<complexType>
<sequence>
<element name="application">
<complexType>
<sequence>
<element name="dataModel">
<complexType>
<attribute name="protocolId" type="NMTOKEN" />
<attribute name="extensionIds" type="NMTOKENS" />
</complexType>
</element>
</sequence>
<attribute name="protocolId" type="NMTOKEN" />
<attribute name="extensionIds" type="NMTOKENS" />
</complexType>
</element>
</sequence>
<attribute name="protocolId" type="NMTOKEN" />
<attribute name="extensionIds" type="NMTOKENS" />
<attribute name="authenticationIds" type="NMTOKENS" />
</complexType>
</element>
</sequence>
</complexType>
</element>
<element name="responseSize"> 'payload-error' - indicates there was an error interpretting the
<complexType> payload. Servers MUST send a payload error if they receive XML
<choice> (i.e. the PT flag is set to 'xml') and the XML cannot be parsed.
<element name="exceedsMaximum">
<complexType/>
</element>
<element name="octets" type="positiveInteger" />
</choice>
</complexType>
</element>
<element name="error"> 'system-error' - indicates that the receiver cannot process the
<complexType> request due to a condition not related to this protocol. Servers
<sequence> SHOULD send a system-error when they are capable of responding to
<element name="description"> requests but not capable of processing requests.
<complexType>
<simpleContent>
<extension base="string">
<attribute name="language" type="lang"/>
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
<attribute type="token" name="type"/>
</complexType>
</element>
</schema> 'authority-error' - indicates that the intended authority
specified in the corresponding request is not served by the
receiver. Servers SHOULD send an authority error when they
receive a request directed to an authority other than those they
serve.
3.3 IRIS Transport Mapping Definitions 'no-inflation-support-error' - indicates that the receiver does
not support payloads that have been compressed with DEFLATE [1].
Servers MUST send this error when they receive a request that has
been compressed with DEFLATE but they do not support inflation.
This section lists the definitions required by IRIS [5] for transport 4. Internationalization Considerations
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
character encodings other than UTF-8 or UTF-16.
5. IRIS Transport Mapping Definitions
This section lists the definitions required by IRIS [3] for transport
mappings. mappings.
3.3.1 URI Scheme 5.1 URI Scheme
The URI scheme name specific to this transport MUST be "iris.lwz". See Section 6.1.1.
3.3.2 Application Protocol Label 5.2 Application Protocol Label
The application protocol label MUST be "iris.lwz". See Section 6.1.3.
3.4 Registrations 6. IANA Considerations
3.4.1 URI Scheme Registration 6.1 Registrations
6.1.1 URI Scheme Registration
URL scheme name: iris.lwz URL scheme name: iris.lwz
URL scheme syntax: defined in Section 3.3.1 and [5]. URL scheme syntax: defined in Section 5.1 and [3].
Character encoding considerations: as defined in RFC2396 [6]. Character encoding considerations: as defined in RFC2396 [5].
Intended usage: identifies an IRIS entity made available using Intended usage: identifies an IRIS entity made available using XML
compressed XML over UDP over UDP
Applications using this scheme: defined in IRIS [5]. Applications using this scheme: defined in IRIS [3].
Interoperability considerations: n/a Interoperability considerations: n/a
Security Considerations: defined in Section 6. Security Considerations: defined in Section 7.
Relevant Publications: IRIS [5]. 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
3.4.2 Well-known UDP Port Registration 6.1.2 Well-known UDP Port Registration
Protocol Number: UDP Protocol Number: UDP
Message Formats, Types, Opcodes, and Sequences: defined in Section Message Formats, Types, Opcodes, and Sequences: defined in Section 3
3.1.1 and Section 3.1.1.1. and Section 3.1.
Functions: defined in IRIS [5]. Functions: defined in IRIS [3].
Use of Broadcast/Multicast: none Use of Broadcast/Multicast: none
Proposed Name: IRIS over 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>
3.4.3 S-NAPTR Registration 6.1.3 S-NAPTR Registration
Application Protocol Label: iris.lwz
Intended usage: identifies an IRIS server using compressed XML over Application Protocol Label (see [4]): iris.lwz
UDP Intended usage: identifies an IRIS server using XML over UDP
Interoperability considerations: n/a Interoperability considerations: n/a
Security Considerations: defined in Section 6. Security Considerations: defined in Section 7.
Relevant Publications: IRIS [5]. 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
4. Internationalization Considerations 7. Security Considerations
Implementers should be aware of considerations for
internationalization in IRIS [5].
5. IANA Considerations
5.1 XML Namespace URN Registration
This document makes use of a proposed XML namespace and schema
registry specified in XML_URN [9]. Accordingly, the following
registration information is provided for the IANA:
o URN/URI:
* urn:ietf:params:xml:ns:iris-trans
o Contact:
* Andrew Newton <andy@hxr.us>
o XML:
* The XML Schema specified in Section 3.2
5.2 S-NAPTR Registration
Registrations with the IANA are described in Section 3.4.
6. 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 protocol with an application transport that IPSec), or use the IRIS transfer protocols that provides such
provides such capabilities (e.g. BEEP [7]). capabilities.
7 Normative References
[1] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[2] World Wide Web Consortium, "Namespaces in XML", W3C XML 8. Normative References
Namespaces, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C [1] Deutsch, P., "DEFLATE Compressed Data Format Specification
XML Schema, October 2000, version 1.3", RFC 1951, May 1996.
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.
[4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C [2] The Unicode Consortium, "The Unicode Standard, Version 3",
XML Schema, October 2000, ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[5] 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.
[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource [4] Daigle, L. and A. Newton, "Domain-Based Application Service
Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
[7] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3080, March 2001. Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[8] 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.
[9] Mealling, M., "The IETF XML Registry", [7] Newton, A., "A Common Schema for Internet Registry Information
draft-mealling-iana-xmlns-registry-03 (work in progress), Service Transfer Protocols",
November 2001. draft-ietf-crips-iris-common-transport-00 (work in progress),
April 2005.
Author's Address Author's Address
Andrew L. Newton Andrew L. Newton
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Sterling, VA 20166 Sterling, VA 20166
USA USA
Phone: +1 703 948 3382 Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; andy@hxr.us Email: anewton@verisignlabs.com; andy@hxr.us
URI: http://www.verisignlabs.com/ URI: http://www.verisignlabs.com/
Appendix A. Examples
This section gives examples of IRIS-LWZ exchanges. Lines beginning
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.
Following the "C:" or "S:", the line either contains octet values in
hexadecimal notation with comments or XML fragments. No line
contains both octet values with comments and XML fragments. Comments
are contained within parenthesis.
The following example demonstrates an IRIS client requesting a lookup
of 'AUP' in the 'local' entity class of a 'dreg1' registry. The
client passes a bag with the search request. The server responds
with a 'nameNotFound' response and an explanation.
C: (request packet)
C: 0x08 (header: V=0,RR=request,PD=no,DS=yes,PT=xml)
C: 0x03 0xA4 (transaction ID=932)
C: 0x05 0xDA (maximum response size=1498)
C: 0x09 (authority length=9)
C: (authority="localhost")
C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
C: <searchSet>
C: <bag>
C: <simpleBag xmlns="http://example.com/">
C: <salt>127.0.0.1:3434</salt>
C: <md5>4LnQ1KdCahzyvwBqJis5rw==</md5>
C: </simpleBag>
C: </bag>
C: <lookupEntity
C: registryType="dreg1"
C: entityClass="local"
C: entityName="AUP" />
C: </searchSet>
C: </request>
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x03 0xA4 (transaction ID=932)
S: (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer></iris:answer>
S: <iris:nameNotFound><iris:explanation language="en-US">
S: The name 'AUP' is not found in 'local'.</iris:explanation>
S: </iris:nameNotFound></iris:resultSet></iris:response>
Figure 4: Example 1
The following example demonstrates an IRIS client requesting domain
availability information for 'milo.example.com'. The server responds
that the domain is assigned and active.
C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x0B 0xE7 (transaction ID=3047)
C: 0x0F 0xA0 (maximum response size=4000)
C: 0x0B (authority length=11)
C: (authority="example.com")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
C: <searchSet>
C: <lookupEntity
C: registryType="urn:ietf:params:xml:ns:dchk1"
C: entityClass="domain-name"
C: entityName="milo.example.com" />
C: </searchSet>
C: </request>
S: (response packet)
S: 0x20 (header: V=0,RR=response,PD=no,DS=no,PT=xml)
S: 0x0B 0xE7 (transaction ID=3047)
S: (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S: <iris:resultSet><iris:answer><domain
S: authority="example.com" registryType="dchk1"
S: entityClass="domain-name" entityName="tcs-com-1"
S: temporaryReference="true"
S: xmlns="urn:ietf:params:xml:ns:dchk1"><domainName>
S: milo.example.com</domainName><status><assignedAndActive/>
S: </status></domain></iris:answer>
S: </iris:resultSet></iris:response>
Figure 5: Example 2
The following example demonstrates an IRIS client requesting domain
availability information for felix.example.net, hobbes.example.net,
and daffy.example.net. The client does not support responses
compressed with DEFLATE and the maximum UDP packet it can safely
receive is 498 octets. The server responds with size information
indicating that it would take 1211 octets to provide an answer.
C: (request packet)
C: 0x00 (header: V=0,RR=request,PD=no,DS=no,PT=xml)
C: 0x7E 0x8A (transaction ID=32394)
C: 0x01 0xF2 (maximum response size=498)
C: 0x0B (authority length=11)
C: (authority="example.net")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
C: (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris1.xsd">
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="felix.example.net" />
C: </searchSet>
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="hobbes.example.net" />
C: </searchSet>
C: <searchSet>
C: <lookupEntity registryType="dchk1" entityClass="domain-name"
C: entityName="daffy.example.net" />
C: </searchSet>
C: </request>
S: (response packet)
S: 0x22 (header: V=0,RR=response,PD=no,DS=no,PT=si)
S: 0x7E 0x8A (transaction ID=32394)
S: (Size Information XML response)
S: <responseSize xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <octets>1211</octets>
S: </responseSize>
Figure 6: Example 3
The following example illustrates an IRIS client requesting the
version information from a server, and the server returning the
verion information.
C: (request packet)
C: 0x01 (header: V=0,RR=request,PD=no,DS=no,PT=vi)
C: 0x2E 0x9C (transaction ID=11932)
C: 0x01 0xF2 (maximum response size=498)
C: 0x0B (authority length=11)
C: (authority="example.net")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
S: (response packet)
S: 0x21 (header: V=0,RR=response,PD=no,DS=no,PT=vi)
S: 0x2E 0x9C (transaction ID=11932)
S: (Version Information XML response)
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S: <transferProtocol protocolId="iris.lwz">
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:dreg1"/>
S: </application>
S: </transferProtocol>
S: </versions>
Figure 7: Example 4
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
 End of changes. 

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