XML Streams

XML Streams are a solution for a specific problem within Jabber: continuously transferring dynamically generated XML data bidirectionally over a single TCP socket. They have been designed and implemented to solve that single problem and reduce the complexity of the solution at an absolute minimum.

The goals of the protocol described in this memo are as follows: Create a stateful communication channel between applications. Transfer dynamically generated 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.

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

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.

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

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

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

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.

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

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

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.

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.

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

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

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.

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

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.

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: Invalid Namespace ]]>

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

Simple example of a full STREAM: world ]]>

Another example STREAM utilizing more namespaces: ]]>