TOC 
Network Working GroupJ. Miller
Internet-DraftThe Jabber.org Project
Expires: December 6, 2000June 7, 2000

XML Streams
xmlstream

Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

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

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

This Internet-Draft will expire on December 6, 2000.

Copyright Notice

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

Abstract

This memo describes a simple transport layer to contiguously move XML[1] formatted data structures in real-time bidirectionally between applications.


 TOC 

Table of Contents
 TOC 

1. Introduction

This memo describes a simple transport layer to contiguously move XML[1] formatted data structures in real-time bidirectionally between applications. While existing protocols like HTTP and FTP may be well suited for this application, often the extranneous overhead created by existing protocols is unnecessary to simply transmit XML data. Many existing protocols are not designed to maintain stateful persistent streams over an extended period of time.

1.1 Goals

The goals of the protocol described in this memo are as follows:

  • Create a stateful communication channel between applications.
  • Transfer valid XML formatted data bi-directionaly over the channel.
  • Optimize for longevity of the channel.
  • Optimize for time sensitive data.
  • Reduce implementation requirements for the originating application.

    • 1.2 Terms

    The following terms will be used in this memo:

  • SOCKET: Standard TCP/IP network socket
  • TRANSPORT LAYER: Carrier protocol over a SOCKET (examples: HTTP/FTP)
  • STREAM: XML based TRANSPORT LAYER as defined in this document
  • APPLICATION: Software utilizing a STREAM
  • DATA: XML formatted elements within a STREAM

    • 1.3 Synopsis

    The solution presented in this memo is very simple. Use SOCKET and a TRANSPORT LAYER which is a normal XML Document. The SOCKET and XML Document are directly associated, when the SOCKET opens or closes so does the XML Document. Essentially, open a SOCKET, exchange an XML Document, and close the SOCKET. All data on the SOCKET is a single XML Document.


     TOC 

    2. Connecting

    2.1 Creating SOCKET

    The APPLICATION opens a standard SOCKET or listens for incoming SOCKETs. The APPLICATION may choose any appropriate port for the SOCKETs.


     TOC 

    3. XML Document

    The entire data stream across the SOCKET is a single XML Document. The XML 1.0 Specification[1] fully applies to this data stream, there are no exceptions or alterations. XML Namespaces[2] are used to seperate the required STREAM information from the DATA carried by the STREAM.

    3.1 The stream Namespace

    The "stream" namespace[2] defines the valid root element and attributes that are used to open a STREAM between the APPLICATIONs.

    3.1.1 Attributes

  • to - The to="" attribute is analogous to an HTTP Host: header, and contains a valid DNS host address. It can be used by the receiving APPLICATION to determine the target virtual name on multihosted IPs. This attribute is required to be sent by the APPLICATION opening the STREAM.
  • from - The from="" attribute contains a valid DNS host address that should resolve to source SOCKET IP address. An APPLICATION may require this attribute and require that it resolves to the source SOCKET IP address. This attribute is also required to be sent by the receiving APPLICATION in response to a newly opened STREAM to identify itself.
  • id - The id="" attribute is a unique idenitifer for this STREAM. It is optional and it's use is specific to the APPLICATION.

    • 3.1.2 Default Namespace

    The default Namespace must be explicitly stated within the root tag. This Namespace identifies all of the DATA within the STREAM.

    3.1.3 Root Element

    A simple example of a valid Root Element for a STREAM: 

    <stream:stream
  to="host.foo.org"
  from="host.bar.org"
  xmlns="http://foo/namespace"
  xmlns:stream="http://www.ietf.org/internet-drafts/draft-miller-xmlstreams-00.txt">

    The stream:stream sets the current namespace to "stream" which includes the to and from attributes. The xmlns="" attribute sets the default namespace to http://foo/namespace which applies to all children.

    A larger example including multiple namespaces: 

    <stream:stream
  to="host.foo.org"
  from="host.bar.org"
  xmlns="http://store.com/billing-schema"
  xmlns:edi="http://ecommerce.org/schema"
  xmlns:books="urn:loc.gov:books"
  xmlns:stream="http://www.ietf.org/internet-drafts/draft-miller-xmlstreams-00.txt">

    3.1.4 DATA

    All of the DATA within the STREAM must be well-formed XML as would be expected in any normal XML Document. All of this DATA is application specific and not of concern to the STREAM. The DATA can be in any stated namespace or in the default namespace.

    3.1.5 Parsing

    The XML must be parsed continually as data is available on the SOCKET. This can be accomplished with a non-buffered parser or chunk parser such as . Often it is adventagous to the APPLICATION to break the DATA by top-level elements which are made available individually via the or a similiar API.


     TOC 

    4. Closing the Connection

    4.1 STREAM Close

    Sending a closing </stream:stream> XML tag would be followed immediately by a SOCKET close on both sides of the STREAM.

    4.2 SOCKET Close

    A standard SOCKET close implies a </stream:stream> and would close the STREAM.


     TOC 

    5. Errors

    5.1 XML Processing Errors

    If the STREAM is found to not be well-formed XML at any point in the processing, the APPLICATION is required to appropriately close the STREAM. The APPLICATION may optionally send an error in the namespace appropriate for that conversation.

    5.2 Network Errors

    If there is a network error, the SOCKET and STREAM are no longer valid.

    5.3 Application Errors

    APPLICATION errors should be handled appropriately by the APPLICATION in its namespace. If the STREAM needs to be closed because of an error, the APPLICATION should STREAM close.

    5.4 STREAM Error

    A convenience error element is in the stream namespace. This error element only contains CDATA and may be used by the APPLICATION as a way to send a STREAM level error message. It would be appropriate to use this element when the namespace negotiation between APPLICATIONs failed and there is no common namespace to express an error in.

    Simple STREAM Error Example: 

    <stream:error>Invalid Namespace</stream:error>

     TOC 

    6. Examples

    Fictional Namespaces: The namespaces used in the following examples are fictional (except the stream namespace).

    Simple example of a full STREAM: 

    <?xml version="1.0"?>
<stream:stream
  to="host.foo.org"
  from="host.bar.org"
  xmlns="world:hello"
  xmlns:stream="http://etherx.jabber.org/streams">
  <hello>world</hello>
</stream:stream>

    Another example STREAM utilizing more namespaces: 

    <?xml version="1.0"?>
<stream:stream
  to="server.com"
  from="host.isp.net"
  xmlns="http://isp.net/billing-schema"
  xmlns:edi="http://ecommerce.org/edi"
  xmlns:stream="http://etherx.jabber.org/streams">
  <transaction customer="jean@isp.net"><edi:ticket id="A532F910"/></transaction>
  <transaction customer="amy@isp.net"><edi:ticket id="DD642F18"/></transaction>
  <transaction customer="jerry@isp.net"><edi:ticket id="655387E2"/></transaction>
</stream:stream>

     TOC 

    References

    [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C xml, February 1998.
    [2] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, January 1999.
     TOC 

    Author's Address

      Jeremie Miller
      The Jabber.org Project
      414 DeLong St.
      Cascade, IA 52033
      US
    Phone:  319-852-3464
    EMail:  jeremie@jabber.org
     TOC 

    Appendix A. XML Streams DTD

    <!ELEMENT stream (error?)>
<!ATTLIST stream
  to              CDATA       #REQUIRED
  from            CDATA       #IMPLIED
  id              CDATA       #IMPLIED
  xmlns           CDATA       #REQUIRED
  xmlns:stream    CDATA       #REQUIRED 'http://www.ietf.org/internet-drafts/draft-miller-xmlstreams-00.txt'
  >
<!ELEMENT error (PCDATA)>

     TOC 

    Full Copyright Statement

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

    This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

    The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    Acknowledgement

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