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

XML Streams

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

The list of Internet-Draft Shadow Directories can be accessed at

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

Copyright Notice

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


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


Table of Contents


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.


    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.


    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:


    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:


    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.


    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.


    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>


    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"?>

    Another example STREAM utilizing more namespaces:

    <?xml version="1.0"?>
      <transaction customer=""><edi:ticket id="A532F910"/></transaction>
      <transaction customer=""><edi:ticket id="DD642F18"/></transaction>
      <transaction customer=""><edi:ticket id="655387E2"/></transaction>



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


    Author's Address

      Jeremie Miller
      The Project
      414 DeLong St.
      Cascade, IA 52033
    Phone:  319-852-3464


    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 ''
    <!ELEMENT error (PCDATA)>


    Full Copyright Statement