[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4993

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


       A Lightweight UDP Transport for the  the Internet Registry
                          Information  Service
                      draft-ietf-crisp-iris-lwz-00

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, 2005.

Copyright Notice

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

Abstract

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










Newton                   Expires April 8, 2005                  [Page 1]


Internet-Draft                  iris-lwz                    October 2004


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   IRIS Transport Mapping Definitions . . . . . . . . . . . . 11
       3.4.1   URI Scheme . . . . . . . . . . . . . . . . . . . . . . 11
       3.4.2   Application Protocol Label . . . . . . . . . . . . . . 11
     3.5   Registrations  . . . . . . . . . . . . . . . . . . . . . . 12
       3.5.1   URI Scheme Registration  . . . . . . . . . . . . . . . 12
       3.5.2   Well-known UDP Port Registration . . . . . . . . . . . 12
       3.5.3   S-NAPTR Registration . . . . . . . . . . . . . . . . . 12
   4.  Internationalization Considerations  . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     5.1   XML Namespace URN Registration . . . . . . . . . . . . . . 15
     5.2   S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 17
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 18
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
       Intellectual Property and Copyright Statements . . . . . . . . 19






















Newton                   Expires April 8, 2005                  [Page 2]


Internet-Draft                  iris-lwz                    October 2004


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 April 8, 2005                  [Page 3]


Internet-Draft                  iris-lwz                    October 2004


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














































Newton                   Expires April 8, 2005                  [Page 4]


Internet-Draft                  iris-lwz                    October 2004


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 payload header 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        |
   +--------------------+--------------------+
   |   Checksum         |    Length          |
   +--------------------+--------------------+
   | LWZ-HEADER |                            |
   +------------+                            |
   |       Data:  XML instance               |
   |           compliant with IRIS-LWZ       |
   |           schema defined above          |
   +-----------------------------------------+

   Each IRIS-LWZ query and response is contained in a single UDP packet.
   If no length information is contained in the IRIS-LWZ query, servers
   should assume a packet size limitation of 512 bytes.

   Each bit in the 1 byte payload header has the following meaning:
      bit 7 - version -  if 0, the protocol is the version defined in
      this document.  If 1, the rest of the bits in the header and the
      payload may be interpreted as another version.
      bit 6 - payload is deflate compressed - if 1, the payload is
      compressed using DEFLATE.
      bits 5 through 3 - reserved
      bit 2 - deflate not supported - if 1, do not respond with a
      payload compressed using DEFLATE.
      bit 1 - reserved
      bit 0 - protocol error - meaning that there was something not
      understood in the payload (e.g.  a version mis-match, malformed
      XML, etc...).






Newton                   Expires April 8, 2005                  [Page 5]


Internet-Draft                  iris-lwz                    October 2004


3.1.2  IRIS-LWZ Transactions

3.1.2.1  Client behaviour

   To initiate an IRIS-LWZ query, a client sends a UDP datagram to the
   identified IRIS-LWZ port on the destination server.

   The client then waits for a reply from the server on the same port
   from which it sent the query packet.  The timeout waiting for a reply
   is at the discretion of the client.

   As an example, the client may send the following XML to the server:

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

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

       <searchSet>
         <lookupEntity
           registryType="dreg1"
           entityClass="contact-handle"
           entityName="mak21" />
       </searchSet>

     </request>

   </request>


3.1.2.2  Server behaviour

   Upon receipt of an IRIS-LWZ query, the server will apply DEFLATE
   decompression to the payload if appropriate, carry out whatever
   processing is appropriate, create a valid IRIS-LWZ XML response
   instance to the query, and apply DEFLATE to that instance if
   necessary and appropriate.  If the resulting size is greater than the
   maximum size provided in the query (or 512 bytes if no maximum size
   was provided), the server will respond with a IRIS-LWZ XML indicating
   the response was too large.  The response is sent as a UDP datagram
   to the source address and port of the original query.

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






Newton                   Expires April 8, 2005                  [Page 6]


Internet-Draft                  iris-lwz                    October 2004


3.2  IRIS-LWZ Operations

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

   For each request type, there is one or more response types.  The
   following shows a brief summary:
   o  <getProfiles>
      *  <profiles>
   o  <request>
      *  an IRIS response.
      *  <error> containing <profiles>
      *  <error> containing <length>

3.2.1  Requests

   IRIS-LWZ requests use the formal syntax specified in Section 3.3.
   There are two types of IRIS-LWZ requests:
   o  a profile request
   o  an IRIS query request

   The profile request simply uses the <getProfiles> element.

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

   An IRIS request is wrapped in an <request> element.  This element has
   an OPTIONAL 'length' attribute containing a positive integer.  This
   attribute indicates the allowable length of the response in bytes.
   It allows clients that have an understanding of their UDP path to
   specify how long the response should be.  Clients that do not care
   about UDP fragmentation may set this number arbitrarily high.  If
   this attribute is not present, servers MUST assume a length of 512
   bytes.

   The following is an example of an IRIS request with a query in the
   'dchk1' registry-type.














Newton                   Expires April 8, 2005                  [Page 7]


Internet-Draft                  iris-lwz                    October 2004


   <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 in two flavors:
   o  a <profiles> response
   o  a <response> 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 [8].

   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>

   The <response> response MUST be sent by the server to the client in
   reply to an <request>.  It contains one of three types of content:
   o  an IRIS result 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 <response> containing an IRIS response simply contains the IRIS
   response to the appropriate IRIS request.  The following is an



Newton                   Expires April 8, 2005                  [Page 8]


Internet-Draft                  iris-lwz                    October 2004


   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, the server MUST return an <response>
   indicating that an error has occured.  This is done with the <error>
   child element.  To signal this condition, the <error> element MUST
   contain the <profiles> element.  Here is an example:

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

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

   </response>

   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
   <response> 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:



Newton                   Expires April 8, 2005                  [Page 9]


Internet-Draft                  iris-lwz                    October 2004


   o  Requery with another transport.
   o  Requery over IRIS-LWZ using a larger 'length' indicator.
   o  Signal an error to the user.

   The following is an example of a length error:

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

     <error>
       <length>2652</length>
     </error>

   </response>


3.3  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) Transport for
         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>



Newton                   Expires April 8, 2005                 [Page 10]


Internet-Draft                  iris-lwz                    October 2004


     </element>

     <element name="request">
       <complexType>
         <sequence>
           <element ref="iris:request" />
         </sequence>
         <attribute name="length" type="positiveInteger" />
         <attribute name="serverName" type="string"
           use="required" />
       </complexType>
     </element>

     <element name="response">
       <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>


3.4  IRIS Transport Mapping Definitions

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

3.4.1  URI Scheme

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

3.4.2  Application Protocol Label

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





Newton                   Expires April 8, 2005                 [Page 11]


Internet-Draft                  iris-lwz                    October 2004


3.5  Registrations

3.5.1  URI Scheme Registration

   URL scheme name: iris.lwz

   URL scheme syntax: defined in Section 3.4.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  Well-known UDP Port Registration

   Protocol Number: UDP

   Message Formats, Types, Opcodes, and Sequences: defined in Section
   3.1.1 and Section 3.2.

   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  S-NAPTR Registration

   Application Protocol Label: iris.lwz

   Intended usage: identifies an IRIS server using compressed XML over
   UDP



Newton                   Expires April 8, 2005                 [Page 12]


Internet-Draft                  iris-lwz                    October 2004


   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 April 8, 2005                 [Page 13]


Internet-Draft                  iris-lwz                    October 2004


4.  Internationalization Considerations

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















































Newton                   Expires April 8, 2005                 [Page 14]


Internet-Draft                  iris-lwz                    October 2004


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].  Accordingly, the following
   registration information is provided for the IANA:
   o  URN/URI:
      *  urn:ietf:params:xml:ns:iris-lwz
   o  Contact:
      *  Andrew  Newton <andy@hxr.us>
   o  XML:
      *  The XML Schema specified in Section 3.3

5.2  S-NAPTR Registration

   Registrations with the IANA are described in Section 3.5.


































Newton                   Expires April 8, 2005                 [Page 15]


Internet-Draft                  iris-lwz                    October 2004


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












































Newton                   Expires April 8, 2005                 [Page 16]


Internet-Draft                  iris-lwz                    October 2004


7.  References

7.1  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),
         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



Newton                   Expires April 8, 2005                 [Page 17]


Internet-Draft                  iris-lwz                    October 2004


         representation of names of countries,  3rd edition", ISO
         Standard 3166, August 1988.

   [14]  Braden, R., "Requirements for Internet Hosts - Application and
         Support", STD 3, RFC 1123, October 1989.

   [15]  International Telecommunications  Union, "The International
         Public Telecommunication Numbering  Plan", ITU-T Recommendation
         E.164, 1991.

   [16]  Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
         Domain Names in Applications  (IDNA)", RFC 3490, March 2003.

   [17]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
         for Internationalized  Domain Names (IDN)", RFC 3491, March
         2003.

   [18]  Mealling, M., "The IETF XML Registry",
         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/













Newton                   Expires April 8, 2005                 [Page 18]


Internet-Draft                  iris-lwz                    October 2004


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).  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 April 8, 2005                 [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/