Network Working Group A. Newton
Internet-Draft L. Daigle
Expires: April 23, 2004 VeriSign, Inc.
October 24, 2003
IRIS - A Lightweight Transport
draft-newton-iris-lightweight-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 April 23, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo defines a lightweight UDP transport for the Internet
Registry Information Service (IRIS).
Newton & Daigle Expires April 23, 2004 [Page 1]
Internet-Draft iris-lwz October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of IRIS-LWZ . . . . . . . . . . . . . . . . . . . . . . 3
2.1 IRIS-LWZ Packet Formats . . . . . . . . . . . . . . . . . . 3
2.2 IRIS-LWZ Transactions . . . . . . . . . . . . . . . . . . . 4
2.2.1 Client behaviour . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Server behaviour . . . . . . . . . . . . . . . . . . . . . . 5
3. IRIS-LWZ Operations . . . . . . . . . . . . . . . . . . . . 6
3.1 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . 11
5. IRIS Transport Mapping Definitions . . . . . . . . . . . . . 12
5.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 Application Protocol Label . . . . . . . . . . . . . . . . . 12
6. Registrations . . . . . . . . . . . . . . . . . . . . . . . 12
6.1 URI Scheme Registration . . . . . . . . . . . . . . . . . . 13
6.2 Well-known UDP Port Registration . . . . . . . . . . . . . . 13
6.3 NAPSTR Registration . . . . . . . . . . . . . . . . . . . . 13
7. Other UDP Transports for IRIS . . . . . . . . . . . . . . . 14
7.1 IRIS-LWX . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2 IRIS-LWB . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 17
Newton & Daigle Expires April 23, 2004 [Page 2]
Internet-Draft iris-lwz October 2003
1. Introduction
The Internet Registry Information Service (IRIS [3]) defines a CRISP
[5] compliant administrative information service for Internet
registries. However, there exist situations where the particular
needs of an Internet registry operator may be met with a lightweight
transport of IRIS.
In order to meet the requirements of CRISP, IRIS uses BEEP [1] over
TCP to accomplish such tasks as authentication and encryption. These
tasks are almost impossible to conduct over UDP. However, there do
exist certain use cases which do not need these features. Based on
the needs and policies of an Internet registry, these profiled cases
may be conducted over a faster, more lightweight UDP-based transport.
It is not the intent of this memo to suggest an alternative to the
full IRIS protocol, but to offer an additional method for serving
IRIS data should an Internet registry determine it appropriate. And
while IRIS does specify that BEEP is its default transport, it does
allow for the deployment of more than one transport (as is common
with many IP-based protocols).
An Internet registry should determine their ability to use this
lightweight version based on the following criteria: 1) no access
controls are needed and all access is considered anonymous, 2) no
encryption or privacy is needed, and 3) the expected queries produce
results with small amounts of data. Specifically, each communication
(query or response) is required to fit in a single UDP packet.
To accomplish a lightweight administrative access service, this
slimmed down use of IRIS uses XML that has undergone GZIP [2]
compression. However, the schemas used in this lightweight transport
are the same as used in other transports of IRIS.
For the purposes of describing this profiled use of UDP in comparison
with IRIS delivered over BEEP/TCP, this document will refer to IRIS
over BEEP/TCP as "IRIS-BEEP", the core schemas and operations of IRIS
as "IRIS", and this document's specification of lightweight IRIS over
UDP as "IRIS-LWZ".
2. Use of IRIS-LWZ
2.1 IRIS-LWZ Packet Formats
The UDP packet format for IRIS-LWZ is as follows:
Newton & Daigle Expires April 23, 2004 [Page 3]
Internet-Draft iris-lwz October 2003
0 16 31
+--------------------+--------------------+
| Src Port | Dst Port |
+--------------------+--------------------+
| Checksum | Length |
+--------------------+--------------------+
| Data: GZIP'ed XML instance |
| compliant with IRIS-LWZ |
| schema defined above |
| |
(...)
| |
+-----------------------------------------+
Again, 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.
2.2 IRIS-LWZ Transactions
2.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. As outlined
above, the UDP packet payload is the byte sequence obtained by
applying GZIP to a valid IRIS-LWZ XML query instance.
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:
Newton & Daigle Expires April 23, 2004 [Page 4]
Internet-Draft iris-lwz October 2003
<lwzRequest
xmlns="urn:ietf:params:xml:ns:iris-lwz"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lwz
iris-lwz.xsd urn:ietf:params:xml:ns:iris1 iris.xsd"
serverName="com" length="1280">
<request xmlns="urn:ietf:params:xml:ns:iris1">
<searchSet>
<lookupEntity
registryType="dreg1"
entityClass="contact-handle"
entityName="mak21" />
</searchSet>
</request>
</lwzRequest>
After GZIP compression, the client sends a UDP payload similar to the
following:
0000:0000 1f 8b 08 08 87 fe 57 3e 00 03 69 72 69 73 6c 77
0000:0010 2d 6c 6f 6f 6b 75 70 2e 78 6d 6c 00 8d 91 31 6f
0000:0020 85 20 14 85 77 7f 05 61 57 c4 2e 0d d1 b7 bc 74
0000:0030 7b ed d0 d7 a1 2b 41 aa e4 21 58 ee 35 ea bf 2f
0000:0040 a2 6d d2 0e 6d 99 b8 27 df e1 70 a0 b6 f3 b3 7e
0000:0050 9f 34 60 46 c8 32 58 07 0d 9d 82 13 46 e3 9b 18
0000:0060 65 90 03 88 28 0b 07 c2 04 03 b9 9d 39 fd 24 c5
0000:0070 02 a6 a1 3d e2 28 18 9b e7 b9 98 ef 0a 1f 3a 56
0000:0080 95 25 67 af 8f 97 ab ea f5 20 73 e3 00 a5 53 3a
0000:0090 f9 c0 08 48 f2 c5 2b 89 c6 bb 3f e3 48 b4 1d fb
0000:00a0 62 81 96 fc 82 f3 04 6e 14 dd 5c 56 bb 0e fb 86
0000:00b0 f2 ea be a4 a7 2c 2a 75 d8 bb fe a3 29 8f 0e b2
0000:00c0 9d 12 5d a0 65 50 fd 55 e3 29 cd 51 b1 de df a6
0000:00d0 f1 c1 a1 c1 f5 d0 08 09 ba 33 80 61 7d 59 47 dd
0000:00e0 d0 36 8e e9 ad f6 a5 13 7b b6 12 62 ae f2 0e a5
0000:00f0 c2 bc 97 ae b5 fa 27 f4 24 87 e8 1f e4 ad e2 94
0000:0100 b0 3d b3 66 df 2e b1 75 61 47 99 d8 ac 66 5f df
0000:0110 78 ca 3e 00 27 87 1e 9e d3 01 00 00
Before compression, the payload is 467 bytes. After compression, the
payload is 284 bytes.
2.2.2 Server behaviour
Upon receipt of an IRIS-LWZ query, the server will un-GZIP the UDP
Newton & Daigle Expires April 23, 2004 [Page 5]
Internet-Draft iris-lwz October 2003
packet payload, carry out whatever processing is appropriate, create
a valid IRIS-LWZ XML response instance to the query, and apply GZIP
to that instance. 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 GZIP'ed instance of
IRIS-LWZ response 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. IRIS-LWZ Operations
The XML in the following sections is descriptive of the formal XML
syntax described in Section 4.
For each request type, there is one or more response types. The
following shows a brief summary:
o <getProfiles>
* <profiles>
o <lwzRequest>
* an IRIS response.
* <error> containing <profiles>
* <error> containing <length>
3.1 Requests
IRIS-LWZ requests use the formal syntax specified in Section 4.
There are two types of IRIS-LWZ requests:
o a profile request
o an IRIS request
The profile request simply uses the <getProfiles> element.
Newton & Daigle Expires April 23, 2004 [Page 6]
Internet-Draft iris-lwz October 2003
<getProfiles
xmlns="urn:ietf:params:xml:ns:iris-lwz"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lwz
iris-lwz.xsd urn:ietf:params:xml:ns:iris1 iris.xsd" />
An IRIS request is wrapped in an <lwzRequest> 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 SHOULD assume a length of
512 bytes.
The following is an example of an IRIS request with a query in the
'dreg1' registry-type.
<lwzRequest
xmlns="urn:ietf:params:xml:ns:iris-lwz"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lwz
iris-lwz.xsd urn:ietf:params:xml:ns:iris1 iris.xsd
urn:ietf:params:xml:ns:dreg1 dreg.xsd"
serverName="com" length="1280">
<request xmlns="urn:ietf:params:xml:ns:iris1">
<searchSet>
<bag>
AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ
c3nBl8CHdkmKuVGUy/ijmvdO5QxuSlU0R4BoCLZk/Sob22RApTn
T+ROMbXFQBrxGH08daAOy98WqpfAutWJri61JLpubIbaqhGyB48
Qt69V6OhYfFsJjvoNEOh1k2dgzXhSlzP3OMVSKRlBzGcO8=
</bag>
<dreg:findDomainsByContact
xmlns:dreg="urn:ietf:params:xml:ns:dreg1">
<dreg:baseDomain>com</dreg:baseDomain>
<dreg:commonName>
<dreg:beginsWith>
The Cobbler Shoppe
</dreg:beginsWith>
</dreg:commonName>
<dreg:role>registrant</dreg:role>
</dreg:findDomainsByContact>
</searchSet>
</request>
Newton & Daigle Expires April 23, 2004 [Page 7]
Internet-Draft iris-lwz October 2003
</lwzRequest>
3.2 Responses
The IRIS-LWZ responses come in two flavors:
o a <profiles> response
o a <lwzResponse> response
The <profiles> response MUST be returned by the server when a client
issues a <getProfiles> request. The <profiles> element contains
<profile> children. Each <profile> child element contains an IRIS
profile as defined by IRIS-BEEP [4].
The following is an example of a <profiles> response.
<profiles
xmlns="urn:ietf:params:xml:ns:iris-lwz"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lwz
iris-lwz.xsd urn:ietf:params:xml:ns:iris1 iris.xsd" >
<profile>
http://iana.org/beep/transient/crisp/iris1/dreg1
</profile>
</profiles>
The <lwzResponse> response MUST be sent by the server to the client
in reply to an <lwzRequest>. It contains one of three types of
content:
o an IRIS response
o an error indicating the IRIS request was for an unsupported
profile.
o an error indicating the IRIS response was too large to send.
An <lwzResponse> containing an IRIS response simply contains the IRIS
response to the appropriate IRIS request. The following is an
example of 'dreg1' IRIS response.
<lwzRequest
xmlns="urn:ietf:params:xml:ns:iris-lwz"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lwz
iris-lwz.xsd urn:ietf:params:xml:ns:iris1 iris.xsd
Newton & Daigle Expires April 23, 2004 [Page 8]
Internet-Draft iris-lwz October 2003
urn:ietf:params:xml:ns:dreg1 dreg.xsd"
serverName="com" length="1280">
<request xmlns="urn:ietf:params:xml:ns:iris1">
<searchSet>
<bag>
AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ
c3nBl8CHdkmKuVGUy/ijmvdO5QxuSlU0R4BoCLZk/Sob22RApTn
T+ROMbXFQBrxGH08daAOy98WqpfAutWJri61JLpubIbaqhGyB48
Qt69V6OhYfFsJjvoNEOh1k2dgzXhSlzP3OMVSKRlBzGcO8=
</bag>
<dreg:findDomainsByContact
xmlns:dreg="urn:ietf:params:xml:ns:dreg1">
<dreg:baseDomain>com</dreg:baseDomain>
<dreg:commonName>
<dreg:beginsWith>
The Cobbler Shoppe
</dreg:beginsWith>
</dreg:commonName>
<dreg:role>registrant</dreg:role>
</dreg:findDomainsByContact>
</searchSet>
</request>
</lwzRequest>
When a client makes an IRIS request for a profile that is not
supported by the server, the server MUST return an <lwzResponse>
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:
Newton & Daigle Expires April 23, 2004 [Page 9]
Internet-Draft iris-lwz October 2003
<lwzResponse
xmlns="urn:ietf:params:xml:ns:iris-lwz"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lwz
iris-lwz.xsd urn:ietf:params:xml:ns:iris1 iris.xsd" >
<error>
<profiles>
<profile>
http://iana.org/beep/transient/crisp/iris1/dreg1
</profile>
</profiles>
</error>
</lwzResponse>
When a client makes an IRIS request that yields a response too large
to fit in the negotiated UDP packet, the server MUST respond with an
<lwzResponse> indicating that a size error has occured. This is done
with the <error> child element. To signal this condition, the
<error> element MUST contain a <length> element. The content of the
<length> element is a positive integer stating the size of the IRIS
response.
Upon receiving this error, a client has the following options:
o Requery over IRIS-BEEP.
o Requery over IRIS-LWZ using a larger 'length' indicator.
o Signal an error.
The following is an example of a length error:
Newton & Daigle Expires April 23, 2004 [Page 10]
Internet-Draft iris-lwz October 2003
<lwzResponse
xmlns="urn:ietf:params:xml:ns:iris-lwz"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lwz
iris-lwz.xsd urn:ietf:params:xml:ns:iris1 iris.xsd" >
<error>
<length>2652</length>
</error>
</lwzResponse>
4. Formal XML Syntax
The following is the XML Schema used to define IRIS-LWZ operations.
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:irislwz="urn:ietf:params:xml:ns:iris-lwz"
xmlns:iris="urn:ietf:params:xml:ns:iris1"
targetNamespace="urn:ietf:params:xml:ns:iris-lwz"
elementFormDefault="qualified" >
<import namespace="urn:ietf:params:xml:ns:iris1" />
<annotation>
<documentation>
Lightweight (LWZ)
Internet Registry Information Service (IRIS)
Schema v1
</documentation>
</annotation>
<element name="getProfiles">
<complexType>
</complexType>
</element>
<element name="profiles">
<complexType>
<sequence>
<element name="profile" type="anyURI"/>
</sequence>
</complexType>
</element>
<element name="lwzRequest">
Newton & Daigle Expires April 23, 2004 [Page 11]
Internet-Draft iris-lwz October 2003
<complexType>
<sequence>
<element ref="iris:request" />
</sequence>
<attribute name="length" type="positiveInteger" />
<attribute name="serverName" type="string"
use="required" />
</complexType>
</element>
<element name="lwzResponse">
<complexType>
<choice>
<element name="error">
<complexType>
<choice>
<element ref="irislwz:profiles" />
<element name="length" type="positiveInteger" />
<element name="invalidRequest" type="string" />
<element name="systemError" type="string" />
</choice>
</complexType>
</element>
<element ref="iris:response" />
</choice>
</complexType>
</element>
</schema>
5. IRIS Transport Mapping Definitions
This section lists the definitions required by IRIS [3] for transport
mappings.
5.1 URI Scheme
The URI scheme name specific to this transport MUST be "iris.lwz".
5.2 Application Protocol Label
The application protocol label MUST be "iris.lwz".
6. Registrations
Newton & Daigle Expires April 23, 2004 [Page 12]
Internet-Draft iris-lwz October 2003
6.1 URI Scheme Registration
URL scheme name: iris.lwz
URL scheme syntax: defined in Section 5.1 and [3].
Character encoding considerations: as defined in RFC2396 [10].
Intended usage: identifies an IRIS entity made available using
compressed XML over UDP
Applications using this scheme: defined in IRIS [3].
Interoperability considerations: n/a
Security Considerations: defined in Section 9.
Relevant Publications: IRIS [3].
Contact Information: Andrew Newton <anewton@ecotroph.net>
Author/Change controller: the IESG
6.2 Well-known UDP Port Registration
Protocol Number: UDP
Message Formats, Types, Opcodes, and Sequences: defined in Section
2.1 and Section 3.
Functions: defined in IRIS [3].
Use of Broadcast/Multicast: none
Proposed Name: IRIS over LWZ
Short name: iris.lwz
Contact Information: Andrew Newton <anewton@ecotroph.net>
6.3 NAPSTR Registration
Application Protocol Label: iris.lwz
Intended usage: identifies an IRIS server using compressed XML over
UDP
Interoperability considerations: n/a
Newton & Daigle Expires April 23, 2004 [Page 13]
Internet-Draft iris-lwz October 2003
Security Considerations: defined in Section 9.
Relevant Publications: IRIS [3].
Contact Information: Andrew Newton <anewton@ecotroph.net>
Author/Change controller: the IESG
7. Other UDP Transports for IRIS
The methods used in this document to describe IRIS-LWZ could be used
for other types of UDP transports for IRIS.
7.1 IRIS-LWX
The use of GZIP to compress the payload of the UDP packet is not
entirely necessary. IRIS-LWZ specifies GZIP to reduce the size of
the payload to provide a higher probably of using UDP. However, the
path MTU of client-to-server connections is usually around 1500 bytes
in many more environments today than just 2 years ago. Therefore,
GZIP compression may not be immediately necessary.
IRIS-LWX would simply use the same XML framing methods described in
this document but send the XML without any compression or
modification.
7.2 IRIS-LWB
Besides compression, there are other methods of reducing the size of
an XML instance. One such method is to tokenize the XML element and
attribute names. WBXML is a standard that does just that. WBXML
also offers another advantage in that it is far less CPU intensive
than GZIP.
IRIS-LWB would be very similar to IRIS-LWZ, except it would use WBXML
serialization and deserialization instead of GZIP compression and
decompression.
It should be noted that the use of WBXML may not be as
straight-forward as described above. WBXML predates XML Namespaces,
heavily used by IRIS, and therefore care may be needed in
constructing the XML data. In addition, WBXML uses code pages of
tokenized names to gain its size and efficiency. Special attention
would be needed to manage these code pages to get the most
efficiency.
8. IANA Considerations
Newton & Daigle Expires April 23, 2004 [Page 14]
Internet-Draft iris-lwz October 2003
Registrations with the IANA are described in Section 6.
9. Security Considerations
IRIS-LWZ is intended for serving public data; it provides no in-band
mechanisms for authentication or encryption. Any application that
needs that 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 [1].
References
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[2] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L. and G.
Randers-Pehrson, "GZIP file format specification version 4.3",
RFC 1952, May 1996.
[3] Newton, A., "Internet Registry Information Service",
draft-ietf-crisp-iris-core-01 (work in progress), November
2002.
[4] Newton, A., "Internet Registry Information Service (IRIS) over
Blocks Exstensible Exchange Protocol (BEEP)",
draft-ietf-crisp-iris-beep-01 (work in progress), November
2002.
[5] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
Requirements", draft-ietf-crisp-requirements-00 (work in
progress), August 2002.
[6] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/
REC-xml-19980210>.
[7] World Wide Web Consortium, "Namespaces in XML", W3C XML
Namespaces, January 1999, <http://www.w3.org/TR/1999/
REC-xml-names-19990114>.
[8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C
XML Schema, October 2000, <http://www.w3.org/TR/2001/
REC-xmlschema-2-20010502/>.
[9] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C
XML Schema, October 2000, <http://www.w3.org/TR/2001/
REC-xmlschema-1-20010502/>.
Newton & Daigle Expires April 23, 2004 [Page 15]
Internet-Draft iris-lwz October 2003
[10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
Authors' Addresses
Andrew Newton
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
Leslie Daigle
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
Newton & Daigle Expires April 23, 2004 [Page 16]
Internet-Draft iris-lwz October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Newton & Daigle Expires April 23, 2004 [Page 17]
Internet-Draft iris-lwz October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Newton & Daigle Expires April 23, 2004 [Page 18]