Network Working Group A. Newton
Internet-Draft VeriSign, Inc.
Expires: July 26, 2005 January 25, 2005
A Lightweight UDP Transport for the the Internet Registry
Information Service
draft-ietf-crisp-iris-lwz-01
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
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
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 26, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes a lightweight UDP transport for the Internet
Registry Information Service (IRIS).
Newton Expires July 26, 2005 [Page 1]
Internet-Draft iris-lwz January 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4
3. UDP Transport . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Use of IRIS-LWZ . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 IRIS-LWZ Packet Formats . . . . . . . . . . . . . . . 5
3.2 Formal XML Syntax . . . . . . . . . . . . . . . . . . . . 9
3.3 IRIS Transport Mapping Definitions . . . . . . . . . . . . 10
3.3.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2 Application Protocol Label . . . . . . . . . . . . . . 11
3.4 Registrations . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 URI Scheme Registration . . . . . . . . . . . . . . . 11
3.4.2 Well-known UDP Port Registration . . . . . . . . . . . 11
3.4.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12
4. Internationalization Considerations . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5.1 XML Namespace URN Registration . . . . . . . . . . . . . . 14
5.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17
Newton Expires July 26, 2005 [Page 2]
Internet-Draft iris-lwz January 2005
1. Introduction
Using S-NAPTR, IRIS has the ability to define the use of multiple
transports for different types of registry services, all at the
descretion of the server operator. The UDP transport defined in this
document is completely modular and may be used by any registry types.
Newton Expires July 26, 2005 [Page 3]
Internet-Draft iris-lwz January 2005
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].
Newton Expires July 26, 2005 [Page 4]
Internet-Draft iris-lwz January 2005
3. UDP Transport
The binding of this UDP transport to IRIS is called IRIS-LWZ (for
IRIS Lightweight using Compression).
IRIS-LWZ is composed of two parts, a binary payload descriptor and an
request/response transaction payload. The request/response
transaction payload may be compressed using the DEFLATE algorithm.
3.1 Use of IRIS-LWZ
3.1.1 IRIS-LWZ Packet Formats
The UDP packet format for IRIS-LWZ is as follows:
+--------+--------------+----------+--------+------------+---------+
field | source | destination | checksum | UDP | payload | payload |
| port | port | | length | descriptor | |
+--------+--------------+----------+--------+------------+---------+
octets 2 2 2 2 1..261 0..n
Each IRIS-LWZ query and response is contained in a single UDP packet.
3.1.1.1 Payload Descriptor
The payload descriptor has two different formats, one for a request
and one for a response. However, each format shares a common 1 octet
payload header described in Section 3.1.1.1.3.
3.1.1.1.1 Payload Request Descriptor
The payload descriptor for request packets has the following format:
+--------+-------------+-------------------+-----------+-----------+
field | header | transaction | maximum response | authority | authority |
| | ID | length | length | |
+--------+-------------+-------------------+-----------+-----------+
octets 1 2 2 1 0..255
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).
Newton Expires July 26, 2005 [Page 5]
Internet-Draft iris-lwz January 2005
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.1.1.1.2 Payload Response Descriptor
The payload descriptor for response packets consists of a payload
header (Section 3.1.1.1.3) and a transaction ID.
+--------+-------------+
field | header | transaction |
| | ID |
+--------+-------------+
octets 1 2
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).
3.1.1.1.3 Payload Header
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
payload may be interpreted as another version.
bit 6 - request/response flag - If 0, this packet is a request
(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).
Newton Expires July 26, 2005 [Page 6]
Internet-Draft iris-lwz January 2005
3.1.1.1.3.1 Errors
Though the payload descriptor header is the same for both request and
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:
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).
3.1.1.1.3.1.1 Version Error
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.
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.
The following is an example of an XML instance describing the version
error.
<versions xmlns="urn:ietf:params:xml:ns:iris-transport">
<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
indicate protocols running on the same port and IP transport as the
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.
Newton Expires July 26, 2005 [Page 7]
Internet-Draft iris-lwz January 2005
3.1.1.1.3.1.2 Size Error
This error indicates that the size of the response exceeded the value
of the maximum response length specified in the corresponding
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
error.
<responseSize xmlns="urn:ietf:params:xml:ns:iris-transport">
<octets>1211</octets>
</responseSize>
3.1.1.1.3.1.3 Other Error
This error indicates conditions where descriptive text is to be
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
of error.
Newton Expires July 26, 2005 [Page 8]
Internet-Draft iris-lwz January 2005
<error xmlns="urn:ietf:params:xml:ns:iris-transport"
type="system">
<description language="en">unavailable, come back later</description>
</error>
3.2 Formal XML Syntax
The following is the XML Schema used to define IRIS-LWZ operations.
See the following specifications: [1], [2], [3], [4].
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:iristrans="urn:ietf:params:xml:ns:iris-transport"
targetNamespace="urn:ietf:params:xml:ns:iris-transport"
elementFormDefault="qualified" >
<annotation>
<documentation>
A schema for describing errors
for use by multiple transports.
</documentation>
</annotation>
<element name="versions">
<complexType>
<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" />
Newton Expires July 26, 2005 [Page 9]
Internet-Draft iris-lwz January 2005
</complexType>
</element>
</sequence>
</complexType>
</element>
<element name="responseSize">
<complexType>
<choice>
<element name="exceedsMaximum">
<complexType/>
</element>
<element name="octets" type="positiveInteger" />
</choice>
</complexType>
</element>
<element name="error">
<complexType>
<sequence>
<element name="description">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="language" type="lang"/>
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
<attribute type="token" name="type"/>
</complexType>
</element>
</schema>
3.3 IRIS Transport Mapping Definitions
This section lists the definitions required by IRIS [5] for transport
mappings.
3.3.1 URI Scheme
The URI scheme name specific to this transport MUST be "iris.lwz".
Newton Expires July 26, 2005 [Page 10]
Internet-Draft iris-lwz January 2005
3.3.2 Application Protocol Label
The application protocol label MUST be "iris.lwz".
3.4 Registrations
3.4.1 URI Scheme Registration
URL scheme name: iris.lwz
URL scheme syntax: defined in Section 3.3.1 and [5].
Character encoding considerations: as defined in RFC2396 [6].
Intended usage: identifies an IRIS entity made available using
compressed XML over UDP
Applications using this scheme: defined in IRIS [5].
Interoperability considerations: n/a
Security Considerations: defined in Section 6.
Relevant Publications: IRIS [5].
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
3.4.2 Well-known UDP Port Registration
Protocol Number: UDP
Message Formats, Types, Opcodes, and Sequences: defined in Section
3.1.1 and Section 3.1.1.1.
Functions: defined in IRIS [5].
Use of Broadcast/Multicast: none
Proposed Name: IRIS over LWZ
Short name: iris.lwz
Contact Information: Andrew Newton <andy@hxr.us>
Newton Expires July 26, 2005 [Page 11]
Internet-Draft iris-lwz January 2005
3.4.3 S-NAPTR Registration
Application Protocol Label: iris.lwz
Intended usage: identifies an IRIS server using compressed XML over
UDP
Interoperability considerations: n/a
Security Considerations: defined in Section 6.
Relevant Publications: IRIS [5].
Contact Information: Andrew Newton <andy@hxr.us>
Author/Change controller: the IESG
Newton Expires July 26, 2005 [Page 12]
Internet-Draft iris-lwz January 2005
4. Internationalization Considerations
Implementers should be aware of considerations for
internationalization in IRIS [5].
Newton Expires July 26, 2005 [Page 13]
Internet-Draft iris-lwz January 2005
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.
Newton Expires July 26, 2005 [Page 14]
Internet-Draft iris-lwz January 2005
6. Security Considerations
IRIS-LWZ is intended for serving public data; it provides no in-band
mechanisms for authentication or encryption. Any application with
this need must provide out of band mechanisms to provide it (e.g.,
IPSec), or use the IRIS protocol with an application transport that
provides such capabilities (e.g. BEEP [7]).
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
Namespaces, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.
[4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[5] Newton, A. and M. Sanz, "Internet Registry Information Service",
RFC 3891, January 2004.
[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[9] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-03 (work in progress),
November 2001.
Newton Expires July 26, 2005 [Page 15]
Internet-Draft iris-lwz January 2005
Author's Address
Andrew L. Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; andy@hxr.us
URI: http://www.verisignlabs.com/
Newton Expires July 26, 2005 [Page 16]
Internet-Draft iris-lwz January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
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 (2005). 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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Newton Expires July 26, 2005 [Page 17]
