Network Working Group                                          A. Newton
Internet-Draft                                            VeriSign, Inc.
Expires: April 8, July 26, 2005                                  January 25, 2005                                   October 8, 2004

       A Lightweight UDP Transport for the  the Internet Registry
                          Information  Service
                      draft-ietf-crisp-iris-lwz-00
                      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 April 8, July 26, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). (2005).  All Rights Reserved.

Abstract

   This document describes a lightweight UDP transport for the Internet
   Registry Information Service (IRIS).

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.1.2   IRIS-LWZ Transactions  . . . . . . . . . . . . . . . .  6
     3.2   IRIS-LWZ Operations  . . . . . . . . . . . . . . . . . . .  7
       3.2.1   Requests . . . . . . . . . . . . . . . . . . . . . . .  7
       3.2.2   Responses  . . . . . . . . . . . . . . . . . . . . . .  8
     3.3   Formal XML Syntax  . . . . . . . . . . . . . . . . . . . . 10
     3.4  9
     3.3   IRIS Transport Mapping Definitions . . . . . . . . . . . . 11
       3.4.1 10
       3.3.1   URI Scheme . . . . . . . . . . . . . . . . . . . . . . 11
       3.4.2 10
       3.3.2   Application Protocol Label . . . . . . . . . . . . . . 11
     3.5
     3.4   Registrations  . . . . . . . . . . . . . . . . . . . . . . 12
       3.5.1 11
       3.4.1   URI Scheme Registration  . . . . . . . . . . . . . . . 12
       3.5.2 11
       3.4.2   Well-known UDP Port Registration . . . . . . . . . . . 12
       3.5.3 11
       3.4.3   S-NAPTR Registration . . . . . . . . . . . . . . . . . 12
   4.  Internationalization Considerations  . . . . . . . . . . . . . 14 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15 14
     5.1   XML Namespace URN Registration . . . . . . . . . . . . . . 15 14
     5.2   S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 15 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16 15
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.1  Normative References . . . . . . . . . . . . . . . . . . . . 17
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 18 15
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 16
       Intellectual Property and Copyright Statements . . . . . . . . 19 17

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.

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 [12]. [8].

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 1 byte binary payload header descriptor and an XML
   request/response transaction payload.  The XML 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:

   0            8       16                   31
   +--------------------+--------------------+
   |    Src Port        |    Dst Port

         +--------+--------------+----------+--------+------------+---------+
   field |
   +--------------------+--------------------+ source |   Checksum destination  |    Length checksum |
   +--------------------+--------------------+  UDP   | LWZ-HEADER  payload   | payload |
   +------------+
         |  port  |       Data:  XML instance     port     |          |           compliant with IRIS-LWZ length | descriptor |           schema defined above         |
   +-----------------------------------------+
         +--------+--------------+----------+--------+------------+---------+
   octets    2           2            2         2        1..261      0..n

   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

3.1.1.1  Payload Descriptor

   The payload descriptor has two different formats, one for a packet size limitation of 512 bytes.

   Each bit in the request
   and one for a response.  However, each format shares a common 1 byte 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 meaning:
      bit 7 - version -  if 0, the protocol is the version defined in
      this document.  If 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).

      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 - payload request/response flag - If 0, this packet is deflate compressed 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 If 1, the payload is compressed using DEFLATE.
      bits 5 through 3 - reserved
      the DEFLATE algorithm.
      bit 2 4 - deflate not supported - if If 1, do not respond with 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 using with DEFLATE.
      bit 1 3 - reserved - This MUST be 0.
      bit 0 2 - protocol error reserved - This MUST be 0.
      bits 1 and 0 - 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 value of these bits indicate errors (Section
      3.1.1.1.3.1).

3.1.1.1.3.1  Errors

   Though the server on payload descriptor header is 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 both request and
   response packets, errors only have context in responses.  When an IRIS-LWZ query, the server will apply DEFLATE
   decompression to
   error is indicated, the payload if appropriate, carry out whatever
   processing is appropriate, create a valid IRIS-LWZ XML response
   instance to the query, and apply DEFLATE not empty but contains information
   relating to that instance if
   necessary and appropriate.  If the resulting size error.  This is greater than the
   maximum size provided described below.

   The error values in the query (or 512 bytes if binary are as follows:
      00 - no maximum size
   was provided), the server will respond with a IRIS-LWZ XML indicating error - the response was too large.  The response payload is sent as a UDP datagram response to the source address and port 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 original query.

   The server's responsibility for addressing a query ends with the
   transmission header descriptor or
   of the UDP response datagram.

3.2  IRIS-LWZ Operations

   The XML in the following sections is descriptive payload of the formal XML
   syntax described in Section 3.3.

   For each corresponding request type, there is one or more not understood by the
   receiver.  This response types.  The
   following shows MUST have a brief summary:
   o  <getProfiles>
      *  <profiles>
   o  <request>
      * payload consisting of an IRIS response.
      *  <error> containing <profiles>
      *  <error> containing <length>

3.2.1  Requests

   IRIS-LWZ requests use XML
   instance conforming to the formal syntax specified definition in Section 3.3.
   There are two types of IRIS-LWZ requests:
   o 3.2 with a profile request
   o  an IRIS query request

   The profile request simply uses the <getProfiles>
   <versions> root element.

   <getProfiles
     xmlns="urn:ietf:params:xml:ns:iris-lwz" />

   An IRIS request is wrapped in an <request> element.  This

   The <versions> element has
   an OPTIONAL 'length' attribute containing child elements that describe the
   relationship between transport bindings, protocol versions, and data
   models.  Each of these child elements has a positive integer.  This 'protocolId' attribute indicates
   identifying the allowable length of protocol they represent.  In the response in bytes.
   It allows clients that have an understanding context of their UDP path to
   specify how long IRIS, 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
   protocol identifiers for these elements are as follows:
      <transportBinding> - the
   'dchk1' registry-type.

   <request
     xmlns="urn:ietf:params:xml:ns:iris-lwz"
     serverName="com" length="1280">

     <request xmlns="urn:ietf:params:xml:ns:iris1">

       <searchSet>
         <lookupEntity
           registryType="dchk1"
           entityClass="domain-name"
           entityName="example.com" />

       </searchSet>

     </request>

   </request>

3.2.2  Responses

   The IRIS-LWZ responses come value "iris.lwz1" to indicate the
      protocol specified in two flavors:
   o  a <profiles> response
   o  a <response> response

   The <profiles> response MUST be returned by this document.
      <application> - the server when a client
   issues a <getProfiles> request.  The <profiles> element contains
   <profile> children.  Each <profile> child element contains an XML namespace identifier for IRIS.
      <dataModel> - the XML namespace identifier for IRIS
   profile as defined by IRIS-BEEP [8]. registries.

   The following is an example of a <profiles> response.

   <profiles
     xmlns="urn:ietf:params:xml:ns:iris-lwz" >
     <profile>
       http://iana.org/beep/iris1/dchk1
     </profile>
   </profiles> 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 <response> response MUST be sent protocols identified by the server to <transportBinding> element MUST only
   indicate protocols running on the client in
   reply to an <request>.  It contains one of three types same port and IP transport as the
   sender of content:
   o  an IRIS result response
   o  an error indicating the error.  In other words, while a server operator may
   also be running IRIS request was over BEEP, this XML instance is only intended to
   instrument version negotiation for an unsupported
      profile.
   o  an LWZ.

3.1.1.1.3.1.2  Size Error

   This error indicating indicates that the size of the IRIS response was too large to send.

   An <response> containing exceeded the value
   of the maximum response length specified in the corresponding
   request.  This response MUST have a payload consisting of an IRIS 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 contains indicates that the IRIS
      response to size exceeded the appropriate IRIS 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 'dchk1' IRIS response.

   <response
     xmlns="urn:ietf:params:xml:ns:iris-lwz">

     <response xmlns="urn:ietf:params:xml:ns:iris1">

       <resultSet>
         <domain
           xmlns="urn:ietf:params:xml:ns:dchk1">
           <domainName>example.com</domainName>
           <status>
             <activeAndOnHold/>
         </domain>
       </resultSet>

     </response>

   </response>

   When a client makes an IRIS request for a profile that is not
   supported by the server, XML instance describing the server MUST return an <response>
   indicating that an error has occured. 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 done with the <error>
   child element.  To signal this condition, to be
   provided to properly diagnose the <error> element error.  This response MUST
   contain the <profiles> element.  Here is an example:

   <response
     xmlns="urn:ietf:params:xml:ns:iris-lwz" >

     <error>
       <profiles>
         <profile>
           http://iana.org/beep/iris1/dchk1
         </profile>
       </profiles>
     </error>

   </response>

   When have a client makes
   payload consisting of an IRIS request that yields a response too large XML instance conforming to fit in the negotiated UDP packet, the server MUST respond formal
   definition in Section 3.2 with an
   <response> indicating that a size error has occured.  This is done
   with the <error> child root element.  To signal this condition, the
   <error>  This root
   element MUST contain may have <description> child elements describing the error,
   each with a <length> element.  The content of 'language' attribute indicated the
   <length> element language in which the
   error is described.  The <error> element has a positive integer stating 'type' attribute
   indicating the size type of the IRIS
   response.

   Upon receiving error.  The values for this error, a client has attribute are as
   follows:
      'descriptor' - indicates there was an error decoding the following options:

   o  Requery with another transport.
   o  Requery over IRIS-LWZ using a larger 'length' indicator.
   o  Signal
      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 user. receiver does not
      support payloads that have been compressed with DEFLATE.

   The following is an example of a length error:

   <response
     xmlns="urn:ietf:params:xml:ns:iris-lwz" >

     <error>
       <length>2652</length> an XML instance describing this type
   of error.

   <error xmlns="urn:ietf:params:xml:ns:iris-transport"
     type="system">
     <description language="en">unavailable, come back later</description>
   </error>

   </response>

3.3

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:irislwz="urn:ietf:params:xml:ns:iris-lwz"
           xmlns:iris="urn:ietf:params:xml:ns:iris1"
           targetNamespace="urn:ietf:params:xml:ns:iris-lwz"
           xmlns:iristrans="urn:ietf:params:xml:ns:iris-transport"
           targetNamespace="urn:ietf:params:xml:ns:iris-transport"
           elementFormDefault="qualified" >

     <import namespace="urn:ietf:params:xml:ns:iris1" />

     <annotation>
       <documentation>
         Lightweight (LWZ) Transport
         A schema for
         Internet Registry Information Service (IRIS)
         Schema v1 describing errors
         for use by multiple transports.
       </documentation>
     </annotation>

     <element name="getProfiles"> name="versions">
       <complexType>
       </complexType>
     </element>
         <sequence>
           <element name="profiles"> name="transportBinding">
             <complexType>
               <sequence>
                 <element name="profile" type="anyURI"/>
         </sequence>
       </complexType>
     </element>

     <element name="request"> name="application">
                   <complexType>
                     <sequence>
                       <element ref="iris:request" name="dataModel">
                         <complexType>
                           <attribute name="protocolId" type="NMTOKEN" />
                           <attribute name="extensionIds" type="NMTOKENS" />
                         </complexType>
                       </element>
                     </sequence>
                     <attribute name="length" type="positiveInteger" name="protocolId" type="NMTOKEN" />
                     <attribute name="serverName" type="string"
           use="required" name="extensionIds" type="NMTOKENS" />
                   </complexType>
                 </element>
               </sequence>
               <attribute name="protocolId" type="NMTOKEN" />
               <attribute name="extensionIds" type="NMTOKENS" />
               <attribute name="authenticationIds" type="NMTOKENS" />
             </complexType>
           </element>
         </sequence>
       </complexType>
     </element>

     <element name="response">
       <complexType>
         <choice>
           <element name="error"> name="responseSize">
       <complexType>
         <choice>
           <element ref="irislwz:profiles" /> name="exceedsMaximum">
             <complexType/>
           </element>
           <element name="length" name="octets" type="positiveInteger" />
                 <element name="invalidRequest" type="string" />
                 <element name="systemError" type="string" />
         </choice>
       </complexType>
     </element>

     <element ref="iris:response" />
         </choice> 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.4

3.3  IRIS Transport Mapping Definitions

   This section lists the definitions required by IRIS [5] for transport
   mappings.

3.4.1

3.3.1  URI Scheme

   The URI scheme name specific to this transport MUST be "iris.lwz".

3.4.2

3.3.2  Application Protocol Label

   The application protocol label MUST be "iris.lwz".

3.5

3.4  Registrations

3.5.1

3.4.1  URI Scheme Registration

   URL scheme name: iris.lwz

   URL scheme syntax: defined in Section 3.4.1 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.5.2

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.2. 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>

3.5.3

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

4.  Internationalization Considerations

   Implementers should be aware of considerations for
   internationalization in IRIS [5].

5.  IANA Considerations

5.1  XML Namespace URN Registration

   This document makes use of a proposed XML namespace and schema
   registry specified in XML_URN [18]. [9].  Accordingly, the following
   registration information is provided for the IANA:
   o  URN/URI:
      *  urn:ietf:params:xml:ns:iris-lwz  urn:ietf:params:xml:ns:iris-trans
   o  Contact:
      *  Andrew  Newton <andy@hxr.us>
   o  XML:
      *  The XML Schema specified in Section 3.3 3.2

5.2  S-NAPTR Registration

   Registrations with the IANA are described in Section 3.5. 3.4.

6.  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 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.  References

7.1 [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", draft-ietf-crisp-iris-core-05 (work in progress),
        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]   Newton, A. and M. Sanz, "Internet Registry Information Service
         (IRIS) over  Blocks Extensible Exchange Protocol (BEEP)",
         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]

   [9]  Mealling, M., "The IETF XML Registry",
        draft-mealling-iana-xmlns-registry-03 (work in progress),
        November 2001.

7.2  Informative References

   [19]  Newton, A., "Cross Registry Internet Service Protocol (CRISP)
         Requirements", RFC 3707, February 2004.

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/

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 (2004). (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.