draft-ietf-crisp-iris-lwz-00.txt   draft-ietf-crisp-iris-lwz-01.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: April 8, 2005 October 8, 2004 Expires: July 26, 2005 January 25, 2005
A Lightweight UDP Transport for the the Internet Registry A Lightweight UDP Transport for the the Internet Registry
Information Service Information Service
draft-ietf-crisp-iris-lwz-00 draft-ietf-crisp-iris-lwz-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 April 8, 2005. This Internet-Draft will expire on July 26, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document describes a lightweight UDP transport for the Internet This document describes a lightweight UDP transport for the Internet
Registry Information Service (IRIS). 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. UDP Transport . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Use of IRIS-LWZ . . . . . . . . . . . . . . . . . . . . . 5 3.1 Use of IRIS-LWZ . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 IRIS-LWZ Packet Formats . . . . . . . . . . . . . . . 5 3.1.1 IRIS-LWZ Packet Formats . . . . . . . . . . . . . . . 5
3.1.2 IRIS-LWZ Transactions . . . . . . . . . . . . . . . . 6 3.2 Formal XML Syntax . . . . . . . . . . . . . . . . . . . . 9
3.2 IRIS-LWZ Operations . . . . . . . . . . . . . . . . . . . 7 3.3 IRIS Transport Mapping Definitions . . . . . . . . . . . . 10
3.2.1 Requests . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Responses . . . . . . . . . . . . . . . . . . . . . . 8 3.3.2 Application Protocol Label . . . . . . . . . . . . . . 11
3.3 Formal XML Syntax . . . . . . . . . . . . . . . . . . . . 10 3.4 Registrations . . . . . . . . . . . . . . . . . . . . . . 11
3.4 IRIS Transport Mapping Definitions . . . . . . . . . . . . 11 3.4.1 URI Scheme Registration . . . . . . . . . . . . . . . 11
3.4.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . 11 3.4.2 Well-known UDP Port Registration . . . . . . . . . . . 11
3.4.2 Application Protocol Label . . . . . . . . . . . . . . 11 3.4.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12
3.5 Registrations . . . . . . . . . . . . . . . . . . . . . . 12 4. Internationalization Considerations . . . . . . . . . . . . . 13
3.5.1 URI Scheme Registration . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
3.5.2 Well-known UDP Port Registration . . . . . . . . . . . 12 5.1 XML Namespace URN Registration . . . . . . . . . . . . . . 14
3.5.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12 5.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 14
4. Internationalization Considerations . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Normative References . . . . . . . . . . . . . . . . . . . . . 15
5.1 XML Namespace URN Registration . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
7.2 Informative References . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
1. Introduction 1. Introduction
Using S-NAPTR, IRIS has the ability to define the use of multiple Using S-NAPTR, IRIS has the ability to define the use of multiple
transports for different types of registry services, all at the transports for different types of registry services, all at the
descretion of the server operator. The UDP transport defined in this descretion of the server operator. The UDP transport defined in this
document is completely modular and may be used by any registry types. document is completely modular and may be used by any registry types.
2. Document Terminology 2. Document Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [12]. document are to be interpreted as described in RFC2119 [8].
3. UDP Transport 3. UDP Transport
The binding of this UDP transport to IRIS is called IRIS-LWZ (for The binding of this UDP transport to IRIS is called IRIS-LWZ (for
IRIS Lightweight using Compression). IRIS Lightweight using Compression).
IRIS-LWZ is composed of two parts, a 1 byte payload header and an XML IRIS-LWZ is composed of two parts, a binary payload descriptor and an
request/response transaction payload. The XML 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 algorithm.
3.1 Use of IRIS-LWZ 3.1 Use of IRIS-LWZ
3.1.1 IRIS-LWZ Packet Formats 3.1.1 IRIS-LWZ Packet Formats
The UDP packet format for IRIS-LWZ is as follows: The UDP packet format for IRIS-LWZ is as follows:
0 8 16 31 +--------+--------------+----------+--------+------------+---------+
+--------------------+--------------------+ field | source | destination | checksum | UDP | payload | payload |
| Src Port | Dst Port | | port | port | | length | descriptor | |
+--------------------+--------------------+ +--------+--------------+----------+--------+------------+---------+
| Checksum | Length | octets 2 2 2 2 1..261 0..n
+--------------------+--------------------+
| LWZ-HEADER | |
+------------+ |
| Data: XML instance |
| compliant with IRIS-LWZ |
| schema defined above |
+-----------------------------------------+
Each IRIS-LWZ query and response is contained in a single UDP packet. Each IRIS-LWZ query and response is contained in a single UDP packet.
If no length information is contained in the IRIS-LWZ query, servers
should assume a packet size limitation of 512 bytes.
Each bit in the 1 byte payload header has the following meaning: 3.1.1.1 Payload Descriptor
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
payload may be interpreted as another version.
bit 6 - payload is deflate compressed - if 1, the payload is
compressed using DEFLATE.
bits 5 through 3 - reserved
bit 2 - deflate not supported - if 1, do not respond with a
payload compressed using DEFLATE.
bit 1 - reserved
bit 0 - protocol error - meaning that there was something not
understood in the payload (e.g. a version mis-match, malformed
XML, etc...).
3.1.2 IRIS-LWZ Transactions
3.1.2.1 Client behaviour
To initiate an IRIS-LWZ query, a client sends a UDP datagram to the
identified IRIS-LWZ port on the destination server.
The client then waits for a reply from the server on the same port
from which it sent the query packet. The timeout waiting for a reply
is at the discretion of the client.
As an example, the client may send the following XML to the server:
<request
xmlns="urn:ietf:params:xml:ns:iris-lwz"
serverName="com" length="1280">
<request xmlns="urn:ietf:params:xml:ns:iris1">
<searchSet>
<lookupEntity
registryType="dreg1"
entityClass="contact-handle"
entityName="mak21" />
</searchSet>
</request>
</request>
3.1.2.2 Server behaviour
Upon receipt of an IRIS-LWZ query, the server will apply DEFLATE
decompression to the payload if appropriate, carry out whatever
processing is appropriate, create a valid IRIS-LWZ XML response
instance to the query, and apply DEFLATE to that instance if
necessary and appropriate. If the resulting size is greater than the
maximum size provided in the query (or 512 bytes if no maximum size
was provided), the server will respond with a IRIS-LWZ XML indicating
the response was too large. The response is sent as a UDP datagram
to the source address and port of the original query.
The server's responsibility for addressing a query ends with the
transmission of the UDP response datagram.
3.2 IRIS-LWZ Operations
The XML in the following sections is descriptive of the formal XML
syntax described in Section 3.3.
For each request type, there is one or more response types. The
following shows a brief summary:
o <getProfiles>
* <profiles>
o <request>
* an IRIS response.
* <error> containing <profiles>
* <error> containing <length>
3.2.1 Requests
IRIS-LWZ requests use the formal syntax specified in Section 3.3.
There are two types of IRIS-LWZ requests:
o a profile request
o an IRIS query request
The profile request simply uses the <getProfiles> element.
<getProfiles
xmlns="urn:ietf:params:xml:ns:iris-lwz" />
An IRIS request is wrapped in an <request> element. This element has
an OPTIONAL 'length' attribute containing a positive integer. This
attribute indicates the allowable length of the response in bytes.
It allows clients that have an understanding of their UDP path to
specify how long the response should be. Clients that do not care
about UDP fragmentation may set this number arbitrarily high. If
this attribute is not present, servers MUST assume a length of 512
bytes.
The following is an example of an IRIS request with a query in the
'dchk1' registry-type.
<request The payload descriptor has two different formats, one for a request
xmlns="urn:ietf:params:xml:ns:iris-lwz" and one for a response. However, each format shares a common 1 octet
serverName="com" length="1280"> payload header described in Section 3.1.1.1.3.
<request xmlns="urn:ietf:params:xml:ns:iris1"> 3.1.1.1.1 Payload Request Descriptor
<searchSet> The payload descriptor for request packets has the following format:
<lookupEntity
registryType="dchk1"
entityClass="domain-name"
entityName="example.com" />
</searchSet> +--------+-------------+-------------------+-----------+-----------+
field | header | transaction | maximum response | authority | authority |
| | ID | length | length | |
+--------+-------------+-------------------+-----------+-----------+
octets 1 2 2 1 0..255
</request> These fields have the following meanings:
header - as described in Section 3.1.1.1.3.
transaction ID - a 16 bit value identifying the transaction. This
value will be returned in the payload response descriptor (Section
3.1.1.1.2) and can be used by clients to match requests with
responses. Clients SHOULD pick the value randomly and SHOULD NOT
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).
</request> maximum response length - the total length of the UDP packet (i.e.
UDP header length + payload descriptor length + XML payload
length) that should not be exceeded when responding to this
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
(Section 3.1.1.1.3.1.2).
authority length - the length of the authority field in this
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.2.2 Responses 3.1.1.1.2 Payload Response Descriptor
The IRIS-LWZ responses come in two flavors: The payload descriptor for response packets consists of a payload
o a <profiles> response header (Section 3.1.1.1.3) and a transaction ID.
o a <response> response
The <profiles> response MUST be returned by the server when a client +--------+-------------+
issues a <getProfiles> request. The <profiles> element contains field | header | transaction |
<profile> children. Each <profile> child element contains an IRIS | | ID |
profile as defined by IRIS-BEEP [8]. +--------+-------------+
octets 1 2
The following is an example of a <profiles> response. The transaction ID MUST be the value of the transaction ID of the
corresponding request. If the corresponding request did not contain
a transaction ID, servers MUST use a transaction ID will all bits set
to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see
Section 3.1.1.1.3.1.3).
<profiles 3.1.1.1.3 Payload Header
xmlns="urn:ietf:params:xml:ns:iris-lwz" >
<profile>
http://iana.org/beep/iris1/dchk1
</profile>
</profiles>
The <response> response MUST be sent by the server to the client in Each bit in the 1 byte payload header has the following meaning:
reply to an <request>. It contains one of three types of content: bit 7 - version - If 0, the protocol is the version defined in
o an IRIS result response this document. If 1, the rest of the bits in the header and the
o an error indicating the IRIS request was for an unsupported payload may be interpreted as another version.
profile. bit 6 - request/response flag - If 0, this packet is a request
o an error indicating the IRIS response was too large to send. (Section 3.1.1.1.1) packet. If 1, this packet is a response
(Section 3.1.1.1.2) packet.
bits 5 - payload deflated - If 1, the payload is compressed using
the DEFLATE algorithm.
bit 4 - deflate supported - 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 3 - 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).
An <response> containing an IRIS response simply contains the IRIS 3.1.1.1.3.1 Errors
response to the appropriate IRIS request. The following is an
example of 'dchk1' IRIS response.
<response Though the payload descriptor header is the same for both request and
xmlns="urn:ietf:params:xml:ns:iris-lwz"> 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.
<response xmlns="urn:ietf:params:xml:ns:iris1"> The error values in binary are as follows:
00 - no error - the payload is a response to the request.
01 - version error (see Section 3.1.1.1.3.1.1).
10 - size error (see Section 3.1.1.1.3.1.2).
11 - other error (see Section 3.1.1.1.3.1.3).
<resultSet> 3.1.1.1.3.1.1 Version Error
<domain
xmlns="urn:ietf:params:xml:ns:dchk1">
<domainName>example.com</domainName>
<status>
<activeAndOnHold/>
</domain>
</resultSet>
</response> This error indicates that either version of the header descriptor or
of the payload of the corresponding request is not understood by the
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.
</response> The <versions> element has child elements that describe the
relationship between transport bindings, protocol versions, and data
models. Each of these child elements has a 'protocolId' attribute
identifying the protocol they represent. In the context of IRIS, the
protocol identifiers for these elements are as follows:
<transportBinding> - the value "iris.lwz1" to indicate the
protocol specified in this document.
<application> - the XML namespace identifier for IRIS.
<dataModel> - the XML namespace identifier for IRIS registries.
When a client makes an IRIS request for a profile that is not The following is an example of an XML instance describing the version
supported by the server, the server MUST return an <response> error.
indicating that an error has occured. This is done with the <error>
child element. To signal this condition, the <error> element MUST
contain the <profiles> element. Here is an example:
<response <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
xmlns="urn:ietf:params:xml:ns:iris-lwz" > <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>
<error> The protocols identified by the <transportBinding> element MUST only
<profiles> indicate protocols running on the same port and IP transport as the
<profile> sender of the error. In other words, while a server operator may
http://iana.org/beep/iris1/dchk1 also be running IRIS over BEEP, this XML instance is only intended to
</profile> instrument version negotiation for LWZ.
</profiles>
</error>
</response> 3.1.1.1.3.1.2 Size Error
When a client makes an IRIS request that yields a response too large This error indicates that the size of the response exceeded the value
to fit in the negotiated UDP packet, the server MUST respond with an of the maximum response length specified in the corresponding
<response> indicating that a size error has occured. This is done request. This response MUST have a payload consisting of an XML
with the <error> child element. To signal this condition, the instance conforming to the formal definition in Section 3.2 with a
<error> element MUST contain a <length> element. The content of the <responseSize> root element. A server may indicate one of two
<length> element is a positive integer stating the size of the IRIS 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. response.
Upon receiving this error, a client has the following options: The following is an example of an XML instance describing the size
error.
o Requery with another transport. <responseSize xmlns="urn:ietf:params:xml:ns:iris-transport">
o Requery over IRIS-LWZ using a larger 'length' indicator. <octets>1211</octets>
o Signal an error to the user. </responseSize>
The following is an example of a length error: 3.1.1.1.3.1.3 Other Error
<response This error indicates conditions where descriptive text is to be
xmlns="urn:ietf:params:xml:ns:iris-lwz" > 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.
<error> The following is an example of an XML instance describing this type
<length>2652</length> of error.
</error>
</response> <error xmlns="urn:ietf:params:xml:ns:iris-transport"
type="system">
<description language="en">unavailable, come back later</description>
</error>
3.3 Formal XML Syntax 3.2 Formal XML Syntax
The following is the XML Schema used to define IRIS-LWZ operations. The following is the XML Schema used to define IRIS-LWZ operations.
See the following specifications: [1], [2], [3], [4].
<?xml version="1.0"?> <?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema" <schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:irislwz="urn:ietf:params:xml:ns:iris-lwz" xmlns:iristrans="urn:ietf:params:xml:ns:iris-transport"
xmlns:iris="urn:ietf:params:xml:ns:iris1" targetNamespace="urn:ietf:params:xml:ns:iris-transport"
targetNamespace="urn:ietf:params:xml:ns:iris-lwz"
elementFormDefault="qualified" > elementFormDefault="qualified" >
<import namespace="urn:ietf:params:xml:ns:iris1" />
<annotation> <annotation>
<documentation> <documentation>
Lightweight (LWZ) Transport for A schema for describing errors
Internet Registry Information Service (IRIS) for use by multiple transports.
Schema v1
</documentation> </documentation>
</annotation> </annotation>
<element name="getProfiles"> <element name="versions">
<complexType> <complexType>
</complexType> <sequence>
</element> <element name="transportBinding">
<element name="profiles">
<complexType> <complexType>
<sequence> <sequence>
<element name="profile" type="anyURI"/> <element name="application">
<complexType>
<sequence>
<element name="dataModel">
<complexType>
<attribute name="protocolId" type="NMTOKEN" />
<attribute name="extensionIds" type="NMTOKENS" />
</complexType>
</element>
</sequence> </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> </complexType>
</element> </element>
<element name="request">
<complexType>
<sequence>
<element ref="iris:request" />
</sequence> </sequence>
<attribute name="length" type="positiveInteger" />
<attribute name="serverName" type="string"
use="required" />
</complexType> </complexType>
</element> </element>
<element name="response"> <element name="responseSize">
<complexType> <complexType>
<choice> <choice>
<element name="exceedsMaximum">
<complexType/>
</element>
<element name="octets" type="positiveInteger" />
</choice>
</complexType>
</element>
<element name="error"> <element name="error">
<complexType> <complexType>
<choice> <sequence>
<element ref="irislwz:profiles" /> <element name="description">
<element name="length" type="positiveInteger" /> <complexType>
<element name="invalidRequest" type="string" /> <simpleContent>
<element name="systemError" type="string" /> <extension base="string">
</choice> <attribute name="language" type="lang"/>
</extension>
</simpleContent>
</complexType> </complexType>
</element> </element>
<element ref="iris:response" /> </sequence>
</choice> <attribute type="token" name="type"/>
</complexType> </complexType>
</element> </element>
</schema> </schema>
3.4 IRIS Transport Mapping Definitions 3.3 IRIS Transport Mapping Definitions
This section lists the definitions required by IRIS [5] for transport This section lists the definitions required by IRIS [5] for transport
mappings. mappings.
3.4.1 URI Scheme 3.3.1 URI Scheme
The URI scheme name specific to this transport MUST be "iris.lwz". The URI scheme name specific to this transport MUST be "iris.lwz".
3.4.2 Application Protocol Label 3.3.2 Application Protocol Label
The application protocol label MUST be "iris.lwz". The application protocol label MUST be "iris.lwz".
3.5 Registrations 3.4 Registrations
3.5.1 URI Scheme Registration 3.4.1 URI Scheme Registration
URL scheme name: iris.lwz URL scheme name: iris.lwz
URL scheme syntax: defined in Section 3.4.1 and [5]. URL scheme syntax: defined in Section 3.3.1 and [5].
Character encoding considerations: as defined in RFC2396 [6]. Character encoding considerations: as defined in RFC2396 [6].
Intended usage: identifies an IRIS entity made available using Intended usage: identifies an IRIS entity made available using
compressed XML over UDP compressed XML over UDP
Applications using this scheme: defined in IRIS [5]. Applications using this scheme: defined in IRIS [5].
Interoperability considerations: n/a Interoperability considerations: n/a
Security Considerations: defined in Section 6. Security Considerations: defined in Section 6.
Relevant Publications: IRIS [5]. Relevant Publications: IRIS [5].
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.5.2 Well-known UDP Port Registration 3.4.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.1.1 and Section 3.2. 3.1.1 and Section 3.1.1.1.
Functions: defined in IRIS [5]. Functions: defined in IRIS [5].
Use of Broadcast/Multicast: none Use of Broadcast/Multicast: none
Proposed Name: IRIS over LWZ Proposed Name: IRIS over LWZ
Short name: iris.lwz Short name: iris.lwz
Contact Information: Andrew Newton <andy@hxr.us> Contact Information: Andrew Newton <andy@hxr.us>
3.5.3 S-NAPTR Registration 3.4.3 S-NAPTR Registration
Application Protocol Label: iris.lwz Application Protocol Label: iris.lwz
Intended usage: identifies an IRIS server using compressed XML over Intended usage: identifies an IRIS server using compressed XML over
UDP UDP
Interoperability considerations: n/a Interoperability considerations: n/a
Security Considerations: defined in Section 6. Security Considerations: defined in Section 6.
Relevant Publications: IRIS [5]. Relevant Publications: IRIS [5].
Contact Information: Andrew Newton <andy@hxr.us> Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG Author/Change controller: the IESG
skipping to change at page 15, line 10 skipping to change at page 14, line 10
4. Internationalization Considerations 4. Internationalization Considerations
Implementers should be aware of considerations for Implementers should be aware of considerations for
internationalization in IRIS [5]. internationalization in IRIS [5].
5. IANA Considerations 5. IANA Considerations
5.1 XML Namespace URN Registration 5.1 XML Namespace URN Registration
This document makes use of a proposed XML namespace and schema This document makes use of a proposed XML namespace and schema
registry specified in XML_URN [18]. Accordingly, the following registry specified in XML_URN [9]. Accordingly, the following
registration information is provided for the IANA: registration information is provided for the IANA:
o URN/URI: o URN/URI:
* urn:ietf:params:xml:ns:iris-lwz * urn:ietf:params:xml:ns:iris-trans
o Contact: o Contact:
* Andrew Newton <andy@hxr.us> * Andrew Newton <andy@hxr.us>
o XML: o XML:
* The XML Schema specified in Section 3.3 * The XML Schema specified in Section 3.2
5.2 S-NAPTR Registration 5.2 S-NAPTR Registration
Registrations with the IANA are described in Section 3.5. Registrations with the IANA are described in Section 3.4.
6. Security Considerations 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 that mechanisms for authentication or encryption. Any application with
needs that 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 protocol with an application transport that
provides such capabilities (e.g. BEEP [7]. provides such capabilities (e.g. BEEP [7]).
7. References
7.1 Normative References 7 Normative References
[1] World Wide Web Consortium, "Extensible Markup Language (XML) [1] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>. <http://www.w3.org/TR/1998/REC-xml-19980210>.
[2] World Wide Web Consortium, "Namespaces in XML", W3C XML [2] World Wide Web Consortium, "Namespaces in XML", W3C XML
Namespaces, January 1999, Namespaces, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>. <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
XML Schema, October 2000, XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>. <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.
[4] World Wide Web Consortium, "XML Schema Part 1: Structures", [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
W3C XML Schema, October 2000, XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>. <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[5] Newton, A. and M. Sanz, "Internet Registry Information [5] Newton, A. and M. Sanz, "Internet Registry Information Service",
Service", draft-ietf-crisp-iris-core-05 (work in progress), RFC 3891, January 2004.
January 2004.
[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
1998.
[7] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC [7] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001. 3080, March 2001.
[8] Newton, A. and M. Sanz, "Internet Registry Information Service [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
(IRIS) over Blocks Extensible Exchange Protocol (BEEP)", Levels", RFC 2119, BCP 14, March 1997.
draft-ietf-crisp-iris-beep-05 (work in progress), January 2004.
[9] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[10] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[11] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[12] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[13] International Organization for Standardization, "Codes for the
representation of names of countries, 3rd edition", ISO
Standard 3166, August 1988.
[14] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989.
[15] International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-T Recommendation
E.164, 1991.
[16] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[17] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (IDN)", RFC 3491, March
2003.
[18] Mealling, M., "The IETF XML Registry", [9] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-03 (work in progress), draft-mealling-iana-xmlns-registry-03 (work in progress),
November 2001. November 2001.
7.2 Informative References
[19] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
Requirements", RFC 3707, February 2004.
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
skipping to change at page 19, line 41 skipping to change at page 17, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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