Network Working Group J. Miller Internet-Draft The Jabber.org Project Expires: December 6, 2000 June 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. Miller Expires December 6, 2000 [Page 1] Internet-Draft XML Streams June 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Connecting . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Creating SOCKET . . . . . . . . . . . . . . . . . . . . . . 4 3. XML Document . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 The stream Namespace . . . . . . . . . . . . . . . . . . . . 5 3.1.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2 Default Namespace . . . . . . . . . . . . . . . . . . . . . 5 3.1.3 Root Element . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.4 DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.5 Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Closing the Connection . . . . . . . . . . . . . . . . . . . 7 4.1 STREAM Close . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 SOCKET Close . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 XML Processing Errors . . . . . . . . . . . . . . . . . . . 8 5.2 Network Errors . . . . . . . . . . . . . . . . . . . . . . . 8 5.3 Application Errors . . . . . . . . . . . . . . . . . . . . . 8 5.4 STREAM Error . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 A. XML Streams DTD . . . . . . . . . . . . . . . . . . . . . . 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 Miller Expires December 6, 2000 [Page 2] Internet-Draft XML Streams June 2000 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. Miller Expires December 6, 2000 [Page 3] Internet-Draft XML Streams June 2000 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. Miller Expires December 6, 2000 [Page 4] Internet-Draft XML Streams June 2000 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 Miller Expires December 6, 2000 [Page 5] Internet-Draft XML Streams June 2000 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. Miller Expires December 6, 2000 [Page 6] Internet-Draft XML Streams June 2000 4. Closing the Connection 4.1 STREAM Close Sending a closing 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 and would close the STREAM. Miller Expires December 6, 2000 [Page 7] Internet-Draft XML Streams June 2000 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: Invalid Namespace Miller Expires December 6, 2000 [Page 8] Internet-Draft XML Streams June 2000 6. Examples 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: Miller Expires December 6, 2000 [Page 9] Internet-Draft XML Streams June 2000 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, . Author's Address Jeremie Miller The Jabber.org Project 414 DeLong St. Cascade, IA 52033 US Phone: 319-852-3464 EMail: jeremie@jabber.org Miller Expires December 6, 2000 [Page 10] Internet-Draft XML Streams June 2000 Appendix A. XML Streams DTD Miller Expires December 6, 2000 [Page 11] Internet-Draft XML Streams June 2000 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. Miller Expires December 6, 2000 [Page 12]