[Standards-JIG] JEP-0017 Framing: Why was it rejected?

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Oct 20 09:16:15 UTC 2004

On Wednesday 20 October 2004 01:26 am, Ralph Meijer wrote:
> On Tue, Oct 19, 2004 at 08:15:20PM -0400, Bob Wyman wrote:
> > Can someone please help me out here?
> >
> > I've been digging through the archives trying to figure out why JEP-0017
> > was rejected but I can't find a definitive answer in the stuff that I've
> > been finding. I would really appreciate it if someone could point me to
> > some existing document or perhaps write a short summary of the case
> > against framing in Jabber.
> This thread of the Council mailinglist [1] gives the vote on this JEP
> with a few rationales from the different members of the 2nd Council. The
> vote tally can be seen here [2].
> As the proposal changes the streaming protocol, I don't think the proposal
> would generate legal XMPP. Reading the schema in RFC 3920, I think
> character data as direct child nodes of stream:stream is not allowed.

As far as I know, extra character data can be present unless it is explicitly 
disallowed (or used for something else).  I assume the <stream> element 
doesn't have this restriction, else we'd all be violating the spec by sending 
those "whitespace pings".

To Bob: the main argument against framing is probably just that it makes the 
protocol less clean-looking.  The notion of a streamed XML document that you 
can throw right at a SAX parser is compelling.  Sure, it is possible to 
implement specs like JEP-0017 that graft on framing, but how much sense does 
it make to skip over a piece of what is supposed to be a continuous document?

The only pure way (in an XML sense) to have framing would be to create an 
alternative to xmpp-core that operates on a series of framed documents 
instead of a big streamed one.  JEP-0124 is one example of such a spec.


More information about the Standards mailing list