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

Versions: 00

Network Working Group                                          A. Newton
Internet-Draft                                            VeriSign, Inc.
Expires: August 8, 2005                                 February 7, 2005


                  XML Pipelining with Chunks for IRIS
                     draft-newton-crisp-iris-xpc-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 August 8, 2005.

Copyright Notice

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

Abstract

   This document describes a simple TCP transport binding for the
   Internet Registry Information Service (IRIS).











Newton                   Expires August 8, 2005                 [Page 1]

Internet-Draft                  iris-xpc                   February 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Document Terminology . . . . . . . . . . . . . . . . . . . .   4
   3.   Block Header . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.   Request Block  . . . . . . . . . . . . . . . . . . . . . . .   6
   5.   Response Block . . . . . . . . . . . . . . . . . . . . . . .   7
   6.   Chunks . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1  No Data Types  . . . . . . . . . . . . . . . . . . . . . .   9
     6.2  Version Error Types  . . . . . . . . . . . . . . . . . . .   9
     6.3  Other Error Types  . . . . . . . . . . . . . . . . . . . .  10
     6.4  Basic Authentication Types . . . . . . . . . . . . . . . .  10
     6.5  SASL Types . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.6  Application Data Types . . . . . . . . . . . . . . . . . .  11
   7.   Use over TLS . . . . . . . . . . . . . . . . . . . . . . . .  12
   8.   IRIS Transport Mapping Definitions . . . . . . . . . . . . .  13
     8.1  URI Scheme . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.2  Application Protocol Label . . . . . . . . . . . . . . . .  13
   9.   Registrations  . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1  XPC URI Scheme Registration  . . . . . . . . . . . . . . .  14
     9.2  XPCS URI Scheme Registration . . . . . . . . . . . . . . .  14
     9.3  S-NAPTR XPC Registration . . . . . . . . . . . . . . . . .  15
     9.4  S-NAPTR XPCS Registration  . . . . . . . . . . . . . . . .  15
   10.  Internationalization Considerations  . . . . . . . . . . . .  16
   11.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  17
     11.1   S-NAPTR Registration . . . . . . . . . . . . . . . . . .  17
   12.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
   13.  Normative References . . . . . . . . . . . . . . . . . . . .  18
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  19
        Intellectual Property and Copyright Statements . . . . . . .  20





















Newton                   Expires August 8, 2005                 [Page 2]

Internet-Draft                  iris-xpc                   February 2005


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 TCP transport binding defined
   in this document is completely modular and may be used by any
   registry types.

   This transport binding defines simple framing for sending XML in
   chunks so that XML fragments may be acted upon (or pipelined) before
   the reception of the entire XML instance.  This document calls this
   XML pipelining with chunks or XPC.

   XPC is for use with simple request and response interactions between
   clients and servers.  Clients send requests to servers in data blocks
   and servers respond to clients with a corresponding data block.
   Request and response data blocks are sent using the TCP SEND function
   and received using the TCP RECEIVE function.

































Newton                   Expires August 8, 2005                 [Page 3]

Internet-Draft                  iris-xpc                   February 2005


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














































Newton                   Expires August 8, 2005                 [Page 4]

Internet-Draft                  iris-xpc                   February 2005


3.  Block Header

   Each data block starts with a one octet header called the block
   header.  This header has the same format for both request and
   response data blocks, though some of the bits in the header only have
   meaning in one type of data block.  Each bit in the block header has
   the following meaning:
   o  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
      block may be interpreted as another version.
   o  bit 6 - reserved - This MUST be 0.
   o  bits 5 - keep open - If 1, the client is requesting the client not
      to close the TCP session.  If 0, the client should expect the
      server to close the TCP session immediately after sending the
      corresponding response.  This bit only has context in request
      blocks.
   o  bit 4 - connection closing - If 0, the server will close the TCP
      session immediately following this block.  This bit only has
      meaning in a response block.
   o  bit 3, 2, 1, and 0 - reserved - These MUST be 0.































Newton                   Expires August 8, 2005                 [Page 5]

Internet-Draft                  iris-xpc                   February 2005


4.  Request Block

   The format for the request block is as follows:

         +--------+-----------+-----------+-------------+
   field | header | authority | authority | chunks 1..n |
         |        |  length   |           |             |
         +--------+-----------+-----------+-------------+
   octets    1         1         0..255      variable

   These fields have the following meanings:
   o  header - as described in Section 3.
   o  authority length - the length of the authority field in this
      payload descriptor.
   o  authority - a string of no more and no less octets describing the
      authority against wich this request is to be executed.  See [1]
      for the definition and description of an authority.
   o  chunks 1..n - the XML request data broken into chunks (Section 6).

































Newton                   Expires August 8, 2005                 [Page 6]

Internet-Draft                  iris-xpc                   February 2005


5.  Response Block

   The format for the response block is as follows:

         +--------+-------------+
   field | header | chunks 1..n |
         |        |             |
         +--------+-------------+
   octets    1       variable

   These fields have the following meanings:
   o  header - as described in Section 3.
   o  chunks 1..n - the XML response data broken into chunks (Section
      6).





































Newton                   Expires August 8, 2005                 [Page 7]

Internet-Draft                  iris-xpc                   February 2005


6.  Chunks

   Request and response blocks break the request and response XML data
   down into chunks.  Request and response blocks MUST always have a
   minimum of 1 chunk.  Each chunk has a one octet descriptor, and the
   first bit of the desciptor determines if a chunk is the last chunk.

   The bits of the chunk descriptor octet have the following meaning:
   o  bit 7 - last chunk -  If 0, this chuck is the last chunk in the
      block.
   o  bit 6 - completion - If 0, the data in this chunk represents the
      end of the data for the chunk type given.  If this bit is never
      set to 0 in any chunk descriptor of a block, clients and servers
      MUST NOT assume the data will continue in another block.  If the
      block transitions from one type of chunk to another with out
      signaling completion of the data, clients and servers MUST assume
      that the remaining data will not be sent in a remaining chunk.
   o  bits 5, 4, and 3 - reserved - These MUST be 0.
   o  bit 2, 1, and 0 - chunk type - determines the type of data carried
      in the chunk.  These are the binary values for the chunk types:
      *  000 - no data
      *  001 - version error
      *  010 - reserved
      *  011 - other error
      *  100 - basic authentication
      *  101 - SASL data
      *  110 - reserved
      *  111 - application data

   A block MAY have multiple types of chunks, but all chunks of the same
   type MUST be contingous in a block and MUST be ordered in the block
   in the order in which their data is to be intepretted.  Contiguous
   chunks must by ordered by type within a block in the following way:
   1.  authentication chunks - either basic authentication chunks (type
       100) or SASL data chunks (type 101), but not both.
   2.  data chunks - either no data chunks (type 000) or application
       data chunks (type 111), but not both.
   3.  error chunks - either version error (type 001) or other error
       (type 011), but not both.
   A block MUST have at least one type of the above chunks.

   The format for a chunk is as follows:









Newton                   Expires August 8, 2005                 [Page 8]

Internet-Draft                  iris-xpc                   February 2005


         +-----------+------------+--------+
   field | chunk     | chunk data | chunk  |
         | descriptor| length     | data   |
         +-----------+------------+--------+
   octets      1            2      variable

   These fields have the following meanings:
   o  chunk descriptor - as described above.
   o  chunk data length - the length of the data of the chunk
   o  chunk data - the data of the chunk

6.1  No Data Types

   Servers and clients MUST ignore data in chunk types labeled no data.
   There is no requirement for these types of chunks to be zero length.
   A client MAY send "no data" to a server, and the server MUST respond
   with either a version error or other error.

6.2  Version Error Types

   Chunks of this type contain an XML instance conformant to the schema
   identified by the namespace urn:ietf:params:xml:ns:iris-transport
   specified in IRIS-LWZ [3].  These XML instances must have the
   <versions> element as their 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 a 'protocolId' attribute
   identifying the protocol they represent.  In the context of IRIS, the
   protocol identifiers for these elements are as follows:
   o  <transportBinding> - the value "iris.xpc1" to indicate the
      protocol specified in this document.
   o  <application> - the XML namespace identifier for IRIS.
   o  <dataModel> - the XML namespace identifier for IRIS registries.

   The following is an example of an XML instance describing the version
   error.

   <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
     <transportBinding protocolId="iris.xpc1">
       <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>





Newton                   Expires August 8, 2005                 [Page 9]

Internet-Draft                  iris-xpc                   February 2005


6.3  Other Error Types

   Chunks of this type contain an XML instance conformant to the schema
   identified by the namespace urn:ietf:params:xml:ns:iris-transport
   specified in IRIS-LWZ [3].  These XML instances must have the <error>
   element as their root element.

   The following is an example of 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>


6.4  Basic Authentication Types

   The basic authentication chunk type allows a client to authenticate
   user credentials to a server.  This type of authentication is simple
   user name and plain password authentication.  Because the password is
   passed in the clear, this type of authentication MUST never be used
   over an unencrypted TCP session.

   The format for the data of this type of chunk is as follows:

         +-----------+-----------+----------+----------+
   field | user name | user name | password | password |
         | length    |           | length   |          |
         +-----------+-----------+----------+----------+
   octets      1       variable       1       variable

   These fields have the following meaning:
   o  user name length - the length of the user name
   o  user name - the name of the user being authenticated
   o  password length - the length of the password
   o  password - the password of the user being authenticated
   These fields MUST NOT span multiple chunks.

6.5  SASL Types

   The SASL chunk type allows clients and servers to exchange SASL data.

   The format for the data of this type of chunk is as follows:







Newton                   Expires August 8, 2005                [Page 10]

Internet-Draft                  iris-xpc                   February 2005


         +--------------+--------------+--------------+--------------+
   field | profile name | profile name | profile data | profile data |
         | length       |              | length       |              |
         +--------------+--------------+--------------+--------------+
   octets       1          variable           2           variable

   These fields have the following meaning:
   o  profile name length - the length of the SASL profile name
   o  profile - the name of the SASL profile
   o  profile data length - the length of the SASL data
   o  profile data - the data used for SASL
   These fields MUST NOT span multiple chunks.  Therefore it should be
   noted that SASL data length exceeding the length of the chunk minus
   the length of SASL profile name minus one is an error.

6.6  Application Data Types

   These chunks contain application data.  For IRIS, these are IRIS [1]
   XML instances.
































Newton                   Expires August 8, 2005                [Page 11]

Internet-Draft                  iris-xpc                   February 2005


7.  Use over TLS

   XPC may be tunneled over TLS [4] by establishing a TLS session
   immediately after a TCP session is opened and before any blocks are
   to be sent.  This type of session is known as XPCS.

   When using TLS, a convention must be established to allow a client to
   authenticate the validity of a server.  XPCS uses the same convention
   as described by IRIS-BEEP [2].










































Newton                   Expires August 8, 2005                [Page 12]

Internet-Draft                  iris-xpc                   February 2005


8.  IRIS Transport Mapping Definitions

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

8.1  URI Scheme

   The URI scheme name specific to XPC MUST be "iris.xpc".  The URI
   scheme name specific to XPCS MUST be "iris.xpcs".

8.2  Application Protocol Label

   The application protocol label for XPC MUST be "iris.xpc".  The
   application protocol label for XPCS MUST be "iris.xpcs".





































Newton                   Expires August 8, 2005                [Page 13]

Internet-Draft                  iris-xpc                   February 2005


9.  Registrations

9.1  XPC URI Scheme Registration

   URL scheme name: iris.xpc

   URL scheme syntax: defined in Section 8.1 and [1].

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

   Intended usage: identifies IRIS XML using chunks over TCP

   Applications using this scheme: defined in IRIS [1].

   Interoperability considerations: n/a

   Security Considerations: defined in Section 12.

   Relevant Publications: IRIS [1].

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

   Author/Change controller: the IESG

9.2  XPCS URI Scheme Registration

   URL scheme name: iris.xpcs

   URL scheme syntax: defined in Section 8.1 and [1].

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

   Intended usage: identifies IRIS XML using chunks over TLS

   Applications using this scheme: defined in IRIS [1].

   Interoperability considerations: n/a

   Security Considerations: defined in Section 12.

   Relevant Publications: IRIS [1].

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

   Author/Change controller: the IESG






Newton                   Expires August 8, 2005                [Page 14]

Internet-Draft                  iris-xpc                   February 2005


9.3  S-NAPTR XPC Registration

   Application Protocol Label: iris.xpc

   Intended usage: identifies an IRIS server using XPC

   Interoperability considerations: n/a

   Security Considerations: defined in Section 12.

   Relevant Publications: IRIS [1].

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

   Author/Change controller: the IESG

9.4  S-NAPTR XPCS Registration

   Application Protocol Label: iris.xpc

   Intended usage: identifies an IRIS server using secure XPCS

   Interoperability considerations: n/a

   Security Considerations: defined in Section 12.

   Relevant Publications: IRIS [1].

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

   Author/Change controller: the IESG




















Newton                   Expires August 8, 2005                [Page 15]

Internet-Draft                  iris-xpc                   February 2005


10.  Internationalization Considerations

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

   Planned revisions to SASL/PLAIN normalize the name of the user for
   authentication purposes.  Basic authentication is provided in XPC for
   backwards compatibility with systems that cannot perform this
   normalization.  Where possible, SASL/PLAIN SHOULD be used.










































Newton                   Expires August 8, 2005                [Page 16]

Internet-Draft                  iris-xpc                   February 2005


11.  IANA Considerations

11.1  S-NAPTR Registration

   Registrations with the IANA are described in Section 9.














































Newton                   Expires August 8, 2005                [Page 17]

Internet-Draft                  iris-xpc                   February 2005


12.  Security Considerations

   Implementers should be fully aware of the security considerations
   given by IRIS [1] and TLS [4].  With respect to server authentication
   with the use of TLS, see Section 6 of IRIS-BEEP [2].

   Clients SHOULD be prepared to use the following SASL profiles in the
   following manner:
   o  SASL/DIGEST-MD5 - for user authentication without the need of
      session encryption.
   o  SASL/OTP - for user authentication without the need of session
      encryption.
   o  TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for
      encryption.
   o  TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with
      client-side certificates - for encryption and user authentication.
   o  TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for
      encryption.  See [6].
   o  TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side
      certificates - for encryption and user authentication.  See [6].
   o  TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for
      encryption.  See [6].
   o  TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side
      certificates - for encryption and user authentication.  See [6].

   Anonymous client access SHOULD be considered in one of two methods:
   1.  When no authentication has been used.
   2.  Using the SASL anonymous profile: SASL/ANONYMOUS

   As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN
   profile without first encrypting the TCP session (e.g.  such as with
   TLS).

   The XPC basic authentication mechanism is a simple version of the
   SASL/PLAIN profile.  It is intended for use with legacy systems where
   some of the normalization methods of SASL/PLAIN may be problematic.
   Clients MUST NOT use basic authentication with first encrypting the
   TCP session (e.g.  such as with TLS).

13  Normative References

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

   [2]  Newton, A. and M. Sanz, "Using the Internet Registry Information
        Service over the Blocks Extensible Exchange Protocol", RFC 3893,
        January 2004.




Newton                   Expires August 8, 2005                [Page 18]

Internet-Draft                  iris-xpc                   February 2005


   [3]  Newton, A., "A Lightweight UDP Transport for the  the Internet
        Registry Information  Service", draft-ietf-crisp-iris-lwz-00.txt
        (work in progress), January 2004.

   [4]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
        P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
        1999.

   [5]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers  (URI): Generic Syntax", RFC 2396, August 1998.

   [6]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
        Transport Layer Security (TLS)", RFC 3268, June 2002.

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

   [8]  Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
        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 August 8, 2005                [Page 19]

Internet-Draft                  iris-xpc                   February 2005


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.




Newton                   Expires August 8, 2005                [Page 20]


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