[standards-jig] JEP-0017: Naive Packet Framing Protocol

David Waite mass at akuma.org
Wed Jan 30 17:34:55 UTC 2002

There are unfortunately a number of issues I see with this proposal (but 
by now, most people probably think I used to the bastard kid who would 
always knock over other people's block towers ;-))

1. I cannot think of a way to protect against misframing (number not 
representing the full packet, representing more than one packet) other 
than by trusting the remote party to indicate framing correctly. This 
would seem to indicate that you must have a degree of trust of the 
remote party to trust their framing, so client to server and server to 
server connections are out of bounds - this could only be used within a 
particular server architecture.

There is also routing information associated with a user's session, 
which replaces the 'from' address with the correct one for the session, 
and adds a 'to' address if none was specified (to a user's account.)

2. If namespaces were properly handled by Jabber, this would mean that 
there was other data outside of a packet which was required for correct 
handling of the packet, being the namespaces and prefixes declared on 
the root element. This sort of framing and full use of namespaces seem 
to be mutually exclusive - you would either need to rewrite packets to 
contain all namespaces they need as defined by the document representing 
the connection between the packets, or ignore namespaces declared at the 

The two solutions which come to mind for this are to either:
- represent packets as documents instead of first-level elements under 
the root, or
- to use a single document per communication between of two entities, 
and frame all transmission of that with something similar to BEEP.

-David Waite

Mike Lin wrote:

>Hi everyone. 
>Julian Missig and myself have written an initial version of JEP-0017:
>Naive Packet Framing Protocol. The JEP describes an experimental
>technique that performs packet framing in a way that should provide
>backwards-compatible performance and code simplicity advantages over the
>current method, which relies on the inherent XML structure of Jabber
>packets (and thus requires the entire packet to be XML-parsed). 
>In its current form, the protocol described by the JEP is not meant for
>production implementations so much as a starting point for formally
>examining the framing problem.
>So, with that, have a look, and let us know what you think :-)
>Standards-JIG mailing list
>Standards-JIG at jabber.org

More information about the Standards mailing list