[standards-jig] RFC transport layer notes

Mike Lin mikelin at MIT.EDU
Tue Feb 19 18:40:21 UTC 2002

I wrote in JEP-0017 that the current method of packet framing in Jabber
makes framing "entirely independent" of the underlying transport layer.
I believe this comment magically made its way into the RFC. Anyway, it
has occurred to me that this is not quite true. The current method of
packet framing in jabber is independent of the underlying transport
layer SO LONG AS that transport layer guarantees per-session FIFO
delivery of data. This means we require of the transport layer that (1)
incoming data from multiple sessions can be distinguished into its
individual sessions, and (2) for each session, data is received in the
same order in which it was transmitted. What this boils down to is that
we would require more framing information if, for example, we wanted to
build Jabber on top of something like UDP - specifically, we would need
to include session ID and sequence number included with each packet. I'm
not saying that's a good idea, but merely illustrative of the reason why
what I originally wrote was incorrect.

By extension, however, this may give us a somewhat reasonable definition
of what our transport layer is, as something separate from our XML
stream layer: just a per-session FIFO byte stream. We happen to
implement that with TCP connections.

I believe that only if/when we start introducing JEP-0017 or BEEP for
framing, then our transport layer can rightly be defined as something
more substantative than that.


More information about the Standards mailing list