XEP-0017: Naive Packet Framing Protocol

Abstract:An intermediate method for more efficient framing of the Jabber XML Stream.
Authors:Mike Lin, Julian Missig
Copyright:© 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Rejected
Type:Informational
Version:0.3
Last Updated:2002-02-19

WARNING: This document has been Rejected by the XMPP Council. Implementation of the protocol described herein is not recommended under any circumstances.


Table of Contents


1. Introduction
2. Framing in Jabber
3. Byte Length Framing
4. Implementation Notes
5. Example
6. Philosophical Notes and Conclusion

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

Framing is the mechanism by which a listener is able to separate a stream of information into discrete semantic units. In Jabber, each of these semantic units is a fragment of a <stream:stream> document consisting of a direct (depth=1) child element of the <stream:stream> document element, and all its attributes and child nodes. These semantic units are hereafter called packets. A Jabber session document, excluding the document element start tag and end tag which are handled as special cases, is implicitly encoded into these packets and transmitted across the network.

This document describes a framing method that may provide performance and code simplicity advantages over the framing method currently used.

2. Framing in Jabber

The current scheme for framing in Jabber relies on the inherent structure of XML to determine packet boundaries. Since each packet is a well-formed XML fragment, the start of the packet is unambiguously denoted by the element start tag at depth=1, and the end of the packet is unambiguously denoted by the corresponding close tag at depth=1.

This method of framing is elegant because all the necessary framing information is inherent in the XML; it makes framing independent of the underlying transport layer so long as that transport layer guarantees per-session FIFO delivery. However, it has significant performance and implementation disadvantages, as it requires any Jabber node (endpoint or router) to XML-parse the packet as it is still being received in order to determine the packet boundary. Many XML parsing suites are not designed to be used in this manner, and various hacks and workarounds have emerged in current Jabber software in order to adapt them for this purpose.

3. Byte Length Framing

Consider a simple method that prefixes the byte length of each packet as an XML text node at depth=1. Put more simply, the transmitting agent calculates the byte length of the element it wishes to transmit. It then transmits this integer length encoded as text, immediately followed by the element.

This technique has the following advantages:

This technique has the following disadvantages:

4. Implementation Notes

Framing data is included for the <stream:stream> and </stream:stream> tags as if they were their own packets, although they are not independently well-formed XML. These should be handled as special cases in a Jabber XML streams implementation.

The connecting agent (client) implicitly requests that the receiving agent (server) use XEP-0017 framing by transmitting XEP-0017 framing data in its own outgoing stream (the connecting agent always "goes first"). Servers should detect the presence of framing data in the client's stream (by testing whether the first character received is a digit or a <) and, if it is detected, activate outgoing framing for that session.

Regardless of the use of framing data, all nodes must verify the well-formedness of XML payloads in order to avoid propagating misframes.

5. Example

Example 1. A Trivial And Nearly Meaningless Example

94<message to="whomever@mlin.mit.edu" from="mlin@mlin.mit.edu">some opaque information</message>
  

6. Philosophical Notes and Conclusion

This framing method is not intended as a fully satisfactory or permanent solution to XML stream framing. In the "distant" (longer than one year) time span, it may be desirable to consider more thorough systems such as BEEP. The intent of this document is to establish an intermediate solution that will provide code simplicity advantages to new implementations in the near term without requiring fundamental changes to the Jabber transport or protocol (as adopting BEEP would almost certainly require).


Appendices


Appendix A: Document Information

Series: XEP
Number: 0017
Publisher: XMPP Standards Foundation
Status: Rejected
Type: Informational
Version: 0.3
Last Updated: 2002-02-19
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name:
Source Control: HTML
This document in other formats: XML  PDF


Appendix B: Author Information

Mike Lin

Email: mikelin@mit.edu
JabberID: mlin@mlin.mit.edu

Julian Missig

Email: julian@jabber.org
JabberID: julian@jabber.org


Appendix C: Legal Notices

Copyright

Permissions

Disclaimer of Warranty

Limitation of Liability

IPR Conformance


Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.


Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.


Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Appendix G: Notes


Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.3 (2002-02-19)

Continued improvement and specification. (mfl)

Version 0.2 (2002-01-31)

Added various clarifications and implementation notes. (mfl)

Version 0.1 (2002-01-23)

Initial revision. (mfl)

END