[standards-jig] JNG Ramblings.

Ryan Eatmon reatmon at jabber.org
Tue Aug 13 22:05:58 UTC 2002

This fits quite nicely with the idea I had while talking with temas 
about this.

Basically, the reasons that binary are good:
- useful for carrying other programs data
- negotiating binary connections
- payloading binary data

Reasons that we want binary in Jabber, and part of the stream:
- leverage the server centric model for firewall traversal.
- easier peer-to-peer binary conversations even if they are both behind 

Some of this was being discussed for PASS/DSPS, so my idea was, don't 
merge the binary into the XML stream, instead create a second stream 
with a generic enough framing protocol that it can payload other things, 
and still maintain the JID idea of a recipient.

So basically, the XML remains XML, and all current clients will not 
break.  But for those that want to speak and transfer things in binary, 
you can connect to another port on the server, and converse in binary. 
 The best of both worlds.  Both are streaming, both understand sending a 
packet to reatmon at jabber.org/Home, but they do not mix.

Now that's something I'd get behind and champion.

Jeremie wrote:

>It's been an interesting debate, again :)
>Although I don't have time at the moment (for other RL reasons) I just
>want to mention that this entire debate is missing one of the most
>important "philosophical" aspects of Jabber, aside from all the protocols
>and bits: this is a world of many protocols, and we need not uniformly
>move to any single one to achieve our goals.
>JNG doesn't have to be just one protocol, nor does it have to decide
>between just binary, just xml, or any other such dividing nonsense.  At
>one point, pre-1.0, the goal of the project had little to do with the xml
>protocol we're now using and was focused purely on interoperability and
>functionality, expecting that whatever protocols being used to achieve
>those would be many, not one.
>I think the larger picture here to make sure of is that JNG is an
>architectural set of guidelines and frameworks that lend themselves to
>working openly with each other via many protocols, XMPP, binary,
>SIP/SIMPLE, even SMTP, HTTP, etc.  "WE" don't need to win any Internet
>protocol battle, instead "EVERYONE" can win if we help any and all
>protocols evolve to work together more openly.
>That philosophy aside, this is a much more difficult long-term problem,
>dealing with identity, security, delivery, server-server discoverability,
>conversion rules, and so on.  We could take the first step by working
>towards even two protocols that cooperate (existing XMPP and a binary-safe
>one) either as alternatives (each feature can in some fashion be delivered
>in the other, although maybe less "efficiently") or as full peers (each is
>used for certian features with little overlap).  Having a strong XMPP now
>has helped first and foremost demonstrate the utility of open
>interoperability, we need to be ready to let go of that strength to
>embrace what it demonstrates and grow these features into other domains.
>Anyway, just some thoughts for the mix ;)
>Standards-JIG mailing list
>Standards-JIG at jabber.org


Ryan Eatmon                   reatmon at jabber.org 
Jabber.org - Perl Team    jid:reatmon at jabber.org

More information about the Standards mailing list