[Standards-JIG] JEP-0017 Framing: Why was it rejected?
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  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 .
> 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