One document matched: draft-newton-iris-lightweight-00.txt
Network Working Group A. Newton
Internet-Draft L. Daigle
Expires: August 23, 2003 VeriSign, Inc.
February 22, 2003
Lightweight Internet Registry Information Service
draft-newton-iris-lightweight-00.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 August 23, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The memo defines a lightweight version of the Internet Registry
Information Service (IRIS) layered on UDP.
Newton & Daigle Expires August 23, 2003 [Page 1]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of IRIS-LW . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Server Discovery . . . . . . . . . . . . . . . . . . . . . . 3
2.2 IRIS-LW Packet Formats . . . . . . . . . . . . . . . . . . . 4
2.3 IRIS-LW Transactions . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Client behaviour . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2 Server behaviour . . . . . . . . . . . . . . . . . . . . . . 6
3. IRIS-LW Operations . . . . . . . . . . . . . . . . . . . . . 6
3.1 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 15
Newton & Daigle Expires August 23, 2003 [Page 2]
Internet-Draft draft-newton-iris-lightweight-00 February 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
version 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 protocol.
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 that this method can
meet some of their needs. This memo describes a procedure allowing
an Internet registry to deploy both versions of IRIS. 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 by this lightweight version
are the same as used in the full version 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-LW".
2. Use of IRIS-LW
2.1 Server Discovery
As defined above, IRIS-LW is intended as a complement to the full
IRIS protocol. While there may be cases where IRIS-LW suffices to
handle all legitimate queries for a service, the expected use case is
to have an IRIS-LW server providing rapid short answers to a subset
of queries to a service, with a fallback to a standard IRIS server
for full service.
Newton & Daigle Expires August 23, 2003 [Page 3]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
This can be reflected in SRV records for the service. A client
seeking the short answer service will look up the SRV record for
_iris-lw._udp in the target domain:
_iris-lw._udp.example.com.
;; Pref Weight Port Target
IN SRV 10 0 10001 bigiron.example.com
IN SRV 20 0 10001 secondary.example.com
IN SRV 30 0 10001 nuclearfallout.example.com.au
A client seeking the full service, or a client that has been
redirected by the IRIS-LW server (because the full answer is not
available from the IRIS-LW server) will look up the SRV record for
_iris._tcp in the target domain:
_iris._tcp.example.com.
;; Pref Weight Port Target
IN SRV 10 0 10001 www.example.com
IN SRV 20 0 10001 www1.example.com
IN SRV 30 0 10001 nuclearfallout.example.com.au
These examples are meant to illustrate the expectation that the UDP
based servers may be part of a high (transaction) volume server
cluster maintained independently of the domain's main WWW, e-mail, or
other (TCP) services.
2.2 IRIS-LW Packet Formats
The UDP packet format for IRIS-LW is as follows:
0 16 31
+--------------------+--------------------+
| Src Port | Dst Port |
+--------------------+--------------------+
| Checksum | Length |
+--------------------+--------------------+
| Data: GZIP'ed XML instance |
| compliant with IRIS-LW |
| schema defined above |
| |
(...)
| |
+-----------------------------------------+
Again, each IRIS-LW query and response is contained in a single UDP
packet. If no length information is contained in the IRIS-LW query,
servers should assume a packet size limitation of 512 bytes.
Newton & Daigle Expires August 23, 2003 [Page 4]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
2.3 IRIS-LW Transactions
2.3.1 Client behaviour
To initiate an IRIS-LW query, a client sends a UDP datagram to the
identified IRIS-LW port on the destination server. As outlined
above, the UDP packet payload is the byte sequence obtained by
applying GZIP to a valid IRIS-LW 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:
<lwRequest
xmlns="urn:ietf:params:xml:ns:iris-lw1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lw1
iris-lw.xsd urn:ietf:params:xml:ns:iris1 iris.xsd"
length="1280">
<request xmlns="urn:ietf:params:xml:ns:iris1">
<searchSet>
<lookupEntity
registryType="dreg1"
entityClass="contact-handle"
entityName="mak21" />
</searchSet>
</request>
</lwRequest>
After GZIP compression, the client sends a UDP payload similar to the
following:
Newton & Daigle Expires August 23, 2003 [Page 5]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
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.3.2 Server behaviour
Upon receipt of an IRIS-LW query, the server will un-GZIP the UDP
packet payload, carry out whatever processing is appropriate, create
a valid IRIS-LW 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-LW
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-LW 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>
Newton & Daigle Expires August 23, 2003 [Page 6]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
o <lwRequest>
* an IRIS response.
* <error> containing <profiles>
* <error> containing <length>
3.1 Requests
IRIS-LW requests use the formal syntax specified in Section 4. There
are two types of IRIS-LW requests:
o a profile request
o an IRIS request
The profile request simply uses the <getProfiles> element.
<getProfiles
xmlns="urn:ietf:params:xml:ns:iris-lw1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lw1
iris-lw.xsd urn:ietf:params:xml:ns:iris1 iris.xsd" />
An IRIS request is wrapped in an <lwRequest> 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.
Newton & Daigle Expires August 23, 2003 [Page 7]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
<lwRequest
xmlns="urn:ietf:params:xml:ns:iris-lw1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lw1
iris-lw.xsd urn:ietf:params:xml:ns:iris1 iris.xsd
urn:ietf:params:xml:ns:dreg1 dreg.xsd"
length="1280">
<request xmlns="urn:ietf:params:xml:ns:iris1">
<searchSet>
<dreg:findDomainsByRegistrant
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:findDomainsByRegistrant>
</searchSet>
</request>
</lwRequest>
3.2 Responses
The IRIS-LW responses come in two flavors:
o a <profiles> response
o a <lwResponse> 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.
Newton & Daigle Expires August 23, 2003 [Page 8]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
<profiles
xmlns="urn:ietf:params:xml:ns:iris-lw1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lw1
iris-lw.xsd urn:ietf:params:xml:ns:iris1 iris.xsd" >
<profile>
http://iana.org/beep/transient/crisp/iris1/dreg1
</profile>
</profiles>
The <lwResponse> response MUST be sent by the server to the client in
reply to an <lwRequest>. 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 <lwResponse> containing an IRIS response simply contains the IRIS
response to the appropriate IRIS request. The following is an
example of 'dreg1' IRIS response.
<lwResponse
xmlns="urn:ietf:params:xml:ns:iris-lw1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lw1
iris-lw.xsd urn:ietf:params:xml:ns:iris1 iris.xsd
urn:ietf:params:xml:ns:dreg1 dreg.xsd" >
<response xmlns="urn:ietf:params:xml:ns:iris1"
xmlns:iris="urn:ietf:params:xml:ns:iris1">
<resultSet>
<answer>
<domain
xmlns="urn:ietf:params:xml:ns:dreg1"
xmlns:dreg="urn:ietf:params:xml:ns:dreg1"
authority="com" registryType="dreg1"
entityClass="domain-handle" entityName="tcs-com-1" >
<domainName>thecobblershoppe.com</domainName>
<nameServers>
<iris:entity
authority="com" registryType="dreg1"
entityClass="host-handle" entityName="research7" />
<iris:entity
authority="com" registryType="dreg1"
entityClass="host-handle" entityName="nsol184" />
Newton & Daigle Expires August 23, 2003 [Page 9]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
</nameServers>
<registrant/>
<domainContacts/>
<activationStatus>assignedAndActive</activationStatus>
<iris:seeAlso>
<iris:entity
authority="com" registryType="dreg1"
entityClass="service-definition" entityName="notice" />
</iris:seeAlso>
</domain>
</answer>
</resultSet>
</response>
</lwResponse>
When a client makes an IRIS request for a profile that is not
supported by the server, the server MUST return an <lwResponse>
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:
<lwResponse
xmlns="urn:ietf:params:xml:ns:iris-lw1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lw1
iris-lw.xsd urn:ietf:params:xml:ns:iris1 iris.xsd" >
<error>
<profiles>
<profile>
http://iana.org/beep/transient/crisp/iris1/dreg1
</profile>
</profiles>
</error>
</lwResponse>
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
<lwResponse> 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.
Newton & Daigle Expires August 23, 2003 [Page 10]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
o Requery over IRIS-LW using a larger 'length' indicator.
o Signal an error.
The following is an example of a length error:
<lwResponse
xmlns="urn:ietf:params:xml:ns:iris-lw1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iris-lw1
iris-lw.xsd urn:ietf:params:xml:ns:iris1 iris.xsd" >
<error>
<length>2652</length>
</error>
</lwResponse>
4. Formal XML Syntax
The following is the XML Schema used to define IRIS-LW operations.
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:irislw="urn:ietf:params:xml:ns:iris-lw1"
xmlns:iris="urn:ietf:params:xml:ns:iris1"
targetNamespace="urn:ietf:params:xml:ns:iris-lw1"
elementFormDefault="qualified" >
<import namespace="urn:ietf:params:xml:ns:iris1" />
<annotation>
<documentation>
Lightweight (LW)
Internet Registry Information Service (IRIS)
Schema v1
</documentation>
</annotation>
<element name="getProfiles">
<complexType>
</complexType>
</element>
<element name="profiles">
<complexType>
<sequence>
Newton & Daigle Expires August 23, 2003 [Page 11]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
<element name="profile" type="anyURI"/>
</sequence>
</complexType>
</element>
<element name="lwRequest">
<complexType>
<sequence>
<element ref="iris:request" />
</sequence>
<attribute name="length" type="positiveInteger" />
</complexType>
</element>
<element name="lwResponse">
<complexType>
<choice>
<element name="error">
<complexType>
<choice>
<element ref="irislw:profiles" />
<element name="length" type="positiveInteger" />
</choice>
</complexType>
</element>
<element ref="iris:response" />
</choice>
</complexType>
</element>
</schema>
5. IANA Considerations
This will eventually include anything necessary to make "iris-lw" a
valid protocol token for use with SRV records.
6. Security Considerations
IRIS-LW 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 full IRIS protocol.
References
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
Newton & Daigle Expires August 23, 2003 [Page 12]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
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/>.
Authors' Addresses
Andrew Newton
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
Newton & Daigle Expires August 23, 2003 [Page 13]
Internet-Draft draft-newton-iris-lightweight-00 February 2003
Leslie Daigle
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
Newton & Daigle Expires August 23, 2003 [Page 14]
Internet-Draft draft-newton-iris-lightweight-00 February 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 August 23, 2003 [Page 15]
Internet-Draft draft-newton-iris-lightweight-00 February 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 August 23, 2003 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 04:16:34 |