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

   A Lightweight UDP Transport Transfer Protocol for the  the Internet Registry
                          Information  Service
                      draft-ietf-crisp-iris-lwz-01
                      draft-ietf-crisp-iris-lwz-02

Status of this Memo

   By submitting this Internet-Draft, I certify each author represents that any
   applicable patent or other IPR claims of which I am he or she is aware
   have been or will be disclosed, and any of which I become he or she becomes
   aware will be disclosed, in accordance with
   RFC 3668. Section 6 of BCP 79.

   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.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 26, October 31, 2005.

Copyright Notice

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

Abstract

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Document Terminology . . . . . . . . . . . . . . . . . . . . .  4
   3.  UDP Transport  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   Use of IRIS-LWZ  .   Payload Descriptor . . . . . . . . . . . . . . . . . . . .  5
       3.1.1   IRIS-LWZ Packet Formats  .   Payload Request Descriptor . . . . . . . . . . . . . .  5
     3.2   Formal XML Syntax
       3.1.2   Payload Response Descriptor  . . . . . . . . . . . . .  6
       3.1.3   Payload Header . . . . . . .  9
     3.3   IRIS Transport Mapping Definitions . . . . . . . . . . . . 10
       3.3.1   URI Scheme .  6
   4.  Internationalization Considerations  . . . . . . . . . . . . . 10
   5.  IRIS Transport Mapping Definitions . . . . . . . . 10
       3.3.2   Application Protocol Label . . . . . . 11
     5.1   URI Scheme . . . . . . . . 11
     3.4   Registrations . . . . . . . . . . . . . . . . 11
     5.2   Application Protocol Label . . . . . . 11
       3.4.1   URI Scheme Registration . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . 11
       3.4.2   Well-known UDP Port Registration . . . . . . . . . . . 11
       3.4.3   S-NAPTR Registration . . . . . 12
     6.1   Registrations  . . . . . . . . . . . . 12
   4.  Internationalization Considerations . . . . . . . . . . 12
       6.1.1   URI Scheme Registration  . . . 13
   5.  IANA Considerations . . . . . . . . . . . . 12
       6.1.2   Well-known UDP Port Registration . . . . . . . . . 14
     5.1   XML Namespace URN . . 12
       6.1.3   S-NAPTR Registration . . . . . . . . . . . . . . 14
     5.2   S-NAPTR Registration . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations
   8.  Normative References . . . . . . . . . . . . . . . . . . . 15
   7.  Normative References . . 14
       Author's Address . . . . . . . . . . . . . . . . . . . . . 15
       Author's Address . . 14
   A.  Examples . . . . . . . . . . . . . . . . . . . . . 16 . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 17 20

1.  Introduction

   Using S-NAPTR, S-NAPTR [4], IRIS has the ability to define the use of multiple
   application transports or transfer protocols for different types of
   registry services, all at the descretion of the server operator.  The
   UDP transport transfer protocol 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 [8].

3.  UDP Transport

   The binding of this UDP transport transfer protocol to IRIS is called IRIS-LWZ
   (for IRIS Lightweight using Compression).

   IRIS-LWZ is composed of two parts, a binary payload descriptor and an
   request/response transaction payload.  The request/response
   transaction payload may be compressed using the DEFLATE [1]
   algorithm.

3.1  Use of IRIS-LWZ

3.1.1  IRIS-LWZ

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

3.  Packet Formats Format

   The UDP packet format for IRIS-LWZ is as follows:

         +--------+--------------+----------+--------+------------+---------+

         +------+------+----------+--------+------------+---------+
   field | source src  | destination dest | checksum |  UDP   |  payload   | payload |
         | port | port |          | length | descriptor |         |
         +--------+--------------+----------+--------+------------+---------+
         +------+------+----------+--------+------------+---------+
   octets    2     2        2         2        1..261      0..n

   (where "src port" means source port and "dest port" means destination
   port).

   Each IRIS-LWZ query and or response is contained in a single UDP packet.

3.1.1.1

3.1  Payload Descriptor

   The payload descriptor has two different formats, one for a request
   and one for a response.  However, each format shares a common 1 octet
   payload header described in Section 3.1.1.1.3.

3.1.1.1.1 3.1.3.

3.1.1  Payload Request Descriptor

   The payload descriptor for request packets has the following format:

         +--------+-------------+-------------------+-----------+-----------+

         +--------+-------------+----------+-----------+-----------+
   field | header | transaction | maximum response  | authority | authority |
         |        |     ID      | response |  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. 3.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) 3.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
      information (Section 3.1.1.1.3.1.2). 3.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] [3] for the definition
      and description of an authority.

3.1.1.1.2  The number of octets in this
      string MUST be no more and no less than the number specified by
      the authority length.

3.1.2  Payload Response Descriptor

   The payload descriptor for response packets consists of a payload
   header (Section 3.1.1.1.3) 3.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 with 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 3.1.3.1.3).

3.1.3  Payload Header

   Each bit in the 1 byte payload header has the following meaning:
      bit

      bits 7 and 6 - version number ('V' flag) - If 0, 0 (both bits are
      zero), the protocol is the version defined in this document.  If 1,
      Otherwise, the rest of the bits in the header and the payload may
      be interpreted as another version.

      bit 6 5 - request/response flag ('RR' flag) - If 0, this packet is a
      request (Section 3.1.1.1.1) 3.1.1) packet.  If 1, this packet is a response
      (Section 3.1.1.1.2) 3.1.2) packet.

      bits 5 4 - payload deflated ('PD' flag) - If 1, the payload is
      compressed using the DEFLATE [1] algorithm.

      bit 4 3 - deflate supported ('DS' flag) - If 1, the sender of this
      packet supports compression using the DEFLATE algorithm.  When
      this bit is 0 in a request, the payload of the response MUST NOT
      be compressed with DEFLATE.

      bit 3 - reserved - This MUST be 0.
      bit 2 - reserved - This MUST be 0.

      bits 1 and 0 - The value of these bits indicate errors payload  types
      (Section
      3.1.1.1.3.1).

3.1.1.1.3.1  Errors

   Though the 3.1.3.1) ('PT' flag).

3.1.3.1  Payload types

   A payload descriptor header is type indicates the same for both type of content in the UDP packet
   following the payload descriptor.  Some payload types have no meaning
   in request and
   response packets, errors only have context and some payload types differ in meaning between
   requests and responses.  When an
   error is indicated, the  Some payload is not types indicate an empty but contains information
   relating to the error.  This is described below.
   payload.

   The error payload type values in binary are as follows:

      00 - no error xml payload ('xml' type).  The payload is either an IRIS-
      based XML request or an IRIS-based XML response.

      01 - version info ('vi' type).  In a request packet, this payload
      type indicates that the server is to respond with version
      information (Section 3.1.3.1.1), and that the payload is empty.
      In a response to packet, this payload type indicates that the request.
      01 - payload
      is version error (see Section 3.1.1.1.3.1.1). information (Section 3.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 info ('si' type).  This error payload type has no meaning in a
      request packet and is a descriptor error.  In a response packet,
      this payload type indicates that either version of the header descriptor or
   of the payload of the corresponding request is not understood by the
   receiver. size information
      (Section 3.1.3.1.2).

      11  - other info ('oi' type).  This response MUST have a payload consisting of an XML
   instance conforming to the formal definition type has no meaning in Section 3.2 with
      a
   <versions> root element.

   The <versions> element has child elements that describe the
   relationship between transport bindings, protocol versions, and data
   models.  Each of these child elements has request packet and is a 'protocolId' attribute
   identifying descriptor error.  In a response packet,
      this payload type indicates that the protocol they represent. payload is other  information
      (Section 3.1.3.1.3).

3.1.3.1.1  Version Information

   A payload type with version information ('vi') MUST be comformant to
   the XML defined in [7] and use the <versions> element as the root
   element.

   In the context of IRIS, IRIS-LWZ, the protocol identifiers for these
   elements are as follows:
      <transportBinding>

      <transferProtocol> - the value "iris.lwz1" to indicate the
      protocol specified in this document.

      <application> - the XML namespace identifier for IRIS. IRIS [3].

      <dataModel> - the XML namespace identifier for IRIS registries.

   The

   This document defines no extension identifiers and no authentication
   mechanism identifiers.

   Servers SHOULD send version information in the following cases:

   1.  In  response to a version information request (i.e. the PT flag
       is an example of an XML instance describing set to 'vi').

   2.  The version in a  payload descriptor header does not match a
       version the server supports.

   3.  The IRIS-based XML  payload does not match a 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 server
       supports.

   The protocols identified by the <transportBinding> <transferProtocol> element MUST only
   indicate protocols running on the same port and IP transport socket as the sender of the error.
   corresponding request.  In other words, while a server operator may
   also be running IRIS over BEEP, IRIS-XPC, this XML instance is only intended to
   instrument
   describe version negotiation for LWZ.

3.1.1.1.3.1.2 IRIS-LWZ.

3.1.3.1.2  Size Error

   This error indicates that the Information

   A payload type with size of the response exceeded the value
   of the maximum response length specified in the corresponding
   request.  This response information ('si') MUST have a payload consisting of an XML
   instance conforming be comformant to the formal definition
   XML defined in Section 3.2 with a [7] and use the <responseSize> element as the root
   element.

3.1.3.1.3  Other Information

   A server may indicate one of two
   response size conditions by specifying the following child elements:
      <exceedsMaximum> - this child element simply indicates that the
      response size exceeded payload type with other information ('oi') MUST be comformant to
   the maximum response size specified XML defined in [7] and use the
      corresponding request.
      <octets> - this child <other> element indicates that the response size
      exceeded the maximum response size specified in the corresponding
      request and provided as the number of octets needed to provide a
      response. root
   element.

   The following is an example values for the 'type' attribute of <other> are as follows:

      'descriptor-error' - indicates there was an XML instance describing the size
   error.

   <responseSize xmlns="urn:ietf:params:xml:ns:iris-transport">
     <octets>1211</octets>
   </responseSize>

3.1.1.1.3.1.3  Other Error

   This error indicates conditions where descriptive text is to be
   provided to properly diagnose decoding the error.  This response MUST have
      descriptor.  Servers SHOULD send a
   payload consisting of an XML instance conforming to the formal
   definition descriptor error in Section 3.2 the
      following cases:

      1.  When a request is received with a <error> root element.  This root
   element may have <description> child elements describing payload type indicating size
          information (i.e. the error,
   each PT flag is 'si').

      2.  When a request is received with a 'language' attribute indicated payload type indicating
          other information (i.e. the language PT flag is 'oi').

      3.  When a request is  sent with an invalid transaction ID.

      4.  When  reserved bits in which the
   error is described.  The <error> element has a 'type' attribute
   indicating the type of error.  The values for this attribute payload descriptor are as
   follows:
      'descriptor' - indicates there was an error decoding the
      descriptor.
      'payload' set to
          values other than zero.

      'payload-error' - indicates there was an error interpretting the
      payload.
      'system'  Servers MUST send a payload error if they receive XML
      (i.e. the PT flag is set to 'xml') and the XML cannot be parsed.

      'system-error' - indicates that the receiver cannot process the
      request due to a condition not related to this protocol.
      'authority'  Servers
      SHOULD send a system-error when they are capable of responding to
      requests but not capable of processing requests.

      'authority-error' - indicates that the intended authority
      specified in the corresponding request is not served by the
      receiver.
      'noDeflationSupport'  Servers SHOULD send an authority error when they
      receive a request directed to an authority other than those they
      serve.

      'no-inflation-support-error' - indicates that the receiver does
      not support payloads that have been compressed with DEFLATE.

   The following is an example of an XML instance describing DEFLATE [1].
      Servers MUST send this type
   of error.

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

3.2  Formal XML Syntax

   The following is the error when they receive a request that has
      been compressed with DEFLATE but they do not support inflation.

4.  Internationalization Considerations

   XML Schema used processors are obliged to define IRIS-LWZ operations.
   See recognize both UTF-8 and UTF-16 [2]
   encodings.  Use of the following specifications: [1], [2], [3], [4].

   <?xml version="1.0"?>
   <schema xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:iristrans="urn:ietf:params:xml:ns:iris-transport"
           targetNamespace="urn:ietf:params:xml:ns:iris-transport"
           elementFormDefault="qualified" >

     <annotation>
       <documentation>
         A schema for describing errors
         for use XML defined by multiple transports.
       </documentation>
     </annotation>

     <element name="versions">
       <complexType>
         <sequence>
           <element name="transportBinding">
             <complexType>
               <sequence>
                 <element name="application">
                   <complexType>
                     <sequence>
                       <element name="dataModel">
                         <complexType>
                           <attribute name="protocolId" type="NMTOKEN" />
                           <attribute name="extensionIds" type="NMTOKENS" />
                         </complexType>
                       </element>
                     </sequence>
                     <attribute name="protocolId" type="NMTOKEN" />
                     <attribute name="extensionIds" type="NMTOKENS" />
                   </complexType>
                 </element>
               </sequence>
               <attribute name="protocolId" type="NMTOKEN" />
               <attribute name="extensionIds" type="NMTOKENS" />
               <attribute name="authenticationIds" type="NMTOKENS" />
             </complexType>
           </element>
         </sequence>
       </complexType>
     </element>

     <element name="responseSize">
       <complexType>
         <choice>
           <element name="exceedsMaximum">
             <complexType/>
           </element>
           <element name="octets" type="positiveInteger" />
         </choice>
       </complexType>
     </element>

     <element name="error">
       <complexType>
         <sequence>
           <element name="description">
             <complexType>
               <simpleContent>
                 <extension base="string">
                   <attribute name="language" type="lang"/>
                 </extension>
               </simpleContent>
             </complexType>
           </element>
         </sequence>
         <attribute type="token" name="type"/>
       </complexType>
     </element>

   </schema>

3.3 [7] MUST NOT use any other
   character encodings other than UTF-8 or UTF-16.

5.  IRIS Transport Mapping Definitions

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

3.3.1

5.1  URI Scheme

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

3.3.2

   See Section 6.1.1.

5.2  Application Protocol Label

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

3.4

   See Section 6.1.3.

6.  IANA Considerations

6.1  Registrations

3.4.1

6.1.1  URI Scheme Registration

   URL scheme name: iris.lwz

   URL scheme syntax: defined in Section 3.3.1 5.1 and [5]. [3].

   Character encoding considerations: as defined in RFC2396 [6]. [5].

   Intended usage: identifies an IRIS entity made available using
   compressed XML
   over UDP

   Applications using this scheme: defined in IRIS [5]. [3].

   Interoperability considerations: n/a

   Security Considerations: defined in Section 6. 7.

   Relevant Publications: IRIS [5]. [3].

   Contact Information: Andrew Newton <andy@hxr.us>

   Author/Change controller: the IESG

3.4.2

6.1.2  Well-known UDP Port Registration

   Protocol Number: UDP

   Message Formats, Types, Opcodes, and Sequences: defined in Section
   3.1.1 3
   and Section 3.1.1.1. 3.1.

   Functions: defined in IRIS [5]. [3].

   Use of Broadcast/Multicast: none

   Proposed Name: IRIS over LWZ IRIS-LWZ

   Short name: iris.lwz

   Contact Information: Andrew Newton <andy@hxr.us>

3.4.3

6.1.3  S-NAPTR Registration

   Application Protocol Label: Label (see [4]): 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 [9].  Accordingly, the following
   registration information is provided for the IANA:
   o  URN/URI:
      *  urn:ietf:params:xml:ns:iris-trans
   o  Contact:
      * 7.

   Relevant Publications: IRIS [3].

   Contact Information: Andrew Newton <andy@hxr.us>
   o  XML:
      *  The XML Schema specified in Section 3.2

5.2  S-NAPTR Registration

   Registrations with

   Author/Change controller: the IANA are described in Section 3.4.

6. IESG

7.  Security Considerations

   IRIS-LWZ is intended for serving public data; it provides no in-band
   mechanisms for authentication or encryption.  Any application with
   this need must provide out of band mechanisms to provide it (e.g.,
   IPSec), or use the IRIS protocol with an application transport transfer protocols that provides such capabilities (e.g.  BEEP [7]).

7
   capabilities.

8.  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>.  Deutsch, P., "DEFLATE Compressed Data Format Specification
        version  1.3", RFC 1951, May 1996.

   [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  The Unicode Consortium, "XML Schema Part 1: Structures", W3C
        XML Schema, October "The Unicode Standard, Version  3",
        ISBN 0-201-61633-5, 2000,
        <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.

   [5] <The Unicode Standard, Version 3>.

   [3]  Newton, A. and M. Sanz, "Internet Registry Information Service",
        RFC 3891, January 2004.

   [6]

   [4]  Daigle, L. and A. Newton, "Domain-Based Application Service
        Location Using SRV  RRs and the Dynamic Delegation Discovery
        Service  (DDDS)", RFC 3958, January 2005.

   [5]  Berners-Lee, T., Fielding, R. 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]

   [6]  Bradner, S., "Key words for use in RFCs to  Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

   [9]  Mealling, M., "The IETF XML Registry",
        draft-mealling-iana-xmlns-registry-03

   [7]  Newton, A., "A Common Schema for Internet Registry Information
        Service Transfer Protocols",
        draft-ietf-crips-iris-common-transport-00 (work in progress),
        November 2001.
        April 2005.

Author's Address

   Andrew L. Newton
   VeriSign, Inc.
   21345 Ridgetop Circle
   Sterling, VA  20166
   USA

   Phone: +1 703 948 3382
   EMail:
   Email: anewton@verisignlabs.com; andy@hxr.us
   URI:   http://www.verisignlabs.com/

Appendix A.  Examples

   This section gives examples of IRIS-LWZ exchanges.  Lines beginning
   with "C:" denote data sent by the client to the server, and lines
   beginning with "S:" denote data sent by the server to the client.
   Following the "C:" or "S:", the line either contains octet values in
   hexadecimal notation with comments or XML fragments.  No line
   contains both octet values with comments and XML fragments.  Comments
   are contained within parenthesis.

   The following example demonstrates an IRIS client requesting a lookup
   of 'AUP' in the 'local' entity class of a 'dreg1' registry.  The
   client passes a bag with the search request.  The server responds
   with a 'nameNotFound' response and an explanation.

   C:           (request packet)
   C: 0x08      (header: V=0,RR=request,PD=no,DS=yes,PT=xml)
   C: 0x03 0xA4 (transaction ID=932)
   C: 0x05 0xDA (maximum response size=1498)
   C: 0x09      (authority length=9)
   C:           (authority="localhost")
   C: 0x6c 0x6f 0x63 0x61 0x6c 0x68 0x6f 0x73 0x74
   C:           (IRIS XML request)
   C: <request xmlns="urn:ietf:params:xml:ns:iris1"
   C:    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
   C:    <searchSet>
   C:      <bag>
   C:        <simpleBag xmlns="http://example.com/">
   C:          <salt>127.0.0.1:3434</salt>
   C:          <md5>4LnQ1KdCahzyvwBqJis5rw==</md5>
   C:        </simpleBag>
   C:      </bag>
   C:      <lookupEntity
   C:        registryType="dreg1"
   C:        entityClass="local"
   C:        entityName="AUP" />
   C:    </searchSet>
   C: </request>

   S:           (response packet)
   S: 0x20      (header: V=0,RR=response,PD=no,DS=no,PT=xml)
   S: 0x03 0xA4 (transaction ID=932)
   S:           (IRIS XML response)
   S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
   S: <iris:resultSet><iris:answer></iris:answer>
   S: <iris:nameNotFound><iris:explanation language="en-US">
   S: The name 'AUP' is not found in 'local'.</iris:explanation>
   S: </iris:nameNotFound></iris:resultSet></iris:response>

                            Figure 4: Example 1

   The following example demonstrates an IRIS client requesting domain
   availability information for 'milo.example.com'.  The server responds
   that the domain is assigned and active.

   C:           (request packet)
   C: 0x00      (header: V=0,RR=request,PD=no,DS=no,PT=xml)
   C: 0x0B 0xE7 (transaction ID=3047)
   C: 0x0F 0xA0 (maximum response size=4000)
   C: 0x0B      (authority length=11)
   C:           (authority="example.com")
   C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D
   C:           (IRIS XML request)
   C: <request xmlns="urn:ietf:params:xml:ns:iris1"
   C:   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   C:   xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
   C:   <searchSet>
   C:     <lookupEntity
   C:       registryType="urn:ietf:params:xml:ns:dchk1"
   C:       entityClass="domain-name"
   C:       entityName="milo.example.com" />
   C:   </searchSet>
   C: </request>

   S:           (response packet)
   S: 0x20      (header: V=0,RR=response,PD=no,DS=no,PT=xml)
   S: 0x0B 0xE7 (transaction ID=3047)
   S:           (IRIS XML response)
   S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
   S: <iris:resultSet><iris:answer><domain
   S: authority="example.com" registryType="dchk1"
   S: entityClass="domain-name" entityName="tcs-com-1"
   S: temporaryReference="true"
   S: xmlns="urn:ietf:params:xml:ns:dchk1"><domainName>
   S: milo.example.com</domainName><status><assignedAndActive/>
   S: </status></domain></iris:answer>
   S: </iris:resultSet></iris:response>

                            Figure 5: Example 2

   The following example demonstrates an IRIS client requesting domain
   availability information for felix.example.net, hobbes.example.net,
   and daffy.example.net.  The client does not support responses
   compressed with DEFLATE and the maximum UDP packet it can safely
   receive is 498 octets.  The server responds with size information
   indicating that it would take 1211 octets to provide an answer.

   C:           (request packet)
   C: 0x00      (header: V=0,RR=request,PD=no,DS=no,PT=xml)
   C: 0x7E 0x8A (transaction ID=32394)
   C: 0x01 0xF2 (maximum response size=498)
   C: 0x0B      (authority length=11)
   C:           (authority="example.net")
   C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74
   C:           (IRIS XML request)
   C: <request xmlns="urn:ietf:params:xml:ns:iris1"
   C:   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   C:   xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris1.xsd">
   C:   <searchSet>
   C:     <lookupEntity registryType="dchk1" entityClass="domain-name"
   C:       entityName="felix.example.net" />
   C:   </searchSet>
   C:   <searchSet>
   C:     <lookupEntity registryType="dchk1" entityClass="domain-name"
   C:       entityName="hobbes.example.net" />
   C:   </searchSet>
   C:   <searchSet>
   C:     <lookupEntity registryType="dchk1" entityClass="domain-name"
   C:       entityName="daffy.example.net" />
   C:   </searchSet>
   C: </request>

   S:           (response packet)
   S: 0x22      (header: V=0,RR=response,PD=no,DS=no,PT=si)
   S: 0x7E 0x8A (transaction ID=32394)
   S:           (Size Information XML response)
   S: <responseSize xmlns="urn:ietf:params:xml:ns:iris-transport">
   S:   <octets>1211</octets>
   S: </responseSize>

                            Figure 6: Example 3

   The following example illustrates an IRIS client requesting the
   version information from a server, and the server returning the
   verion information.

   C:           (request packet)
   C: 0x01      (header: V=0,RR=request,PD=no,DS=no,PT=vi)
   C: 0x2E 0x9C (transaction ID=11932)
   C: 0x01 0xF2 (maximum response size=498)
   C: 0x0B      (authority length=11)
   C:           (authority="example.net")
   C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x6E 0x65 0x74

   S:           (response packet)
   S: 0x21      (header: V=0,RR=response,PD=no,DS=no,PT=vi)
   S: 0x2E 0x9C (transaction ID=11932)
   S:           (Version Information XML response)
   S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
   S:   <transferProtocol protocolId="iris.lwz">
   S:     <application protocolId="urn:ietf:params:xml:ns:iris1">
   S:       <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
   S:       <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
   S:     </application>
   S:   </transferProtocol>
   S: </versions>

                            Figure 7: Example 4

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.