[Standards] Jingle XML Streams (XEP-0247). Was: Re: upcoming XEP deferrals

Ralph Meijer jabber.org at ralphm.ik.nu
Mon Jan 25 08:44:14 UTC 2010

On Sun, 2010-01-24 at 20:53 -0700, Peter Saint-Andre wrote:
> On 1/24/10 7:12 AM, Ralph Meijer wrote:
> > On Fri, 2010-01-22 at 21:15 -0700, Peter Saint-Andre wrote:
> >> A number of XEPs are due to be deferred in the next 4-5 weeks. Here is
> >> my take...
> >>
> >> [..]
> >>
> >> 4. XEP-0247: Jingle XML Streams
> >>    http://xmpp.org/extensions/xep-0247.html
> >>
> >> IMHO we don't need this one any longer, so it can lapse without issue.
> > 
> > Just last week I suggested Dan Brickley to look into this XEP, because
> > it enables low-latency peer-to-peer XMPP traffic without requiring
> > Zeroconf support.
> > 
> > While I very much admire Zeroconf and the Serverless Messaging
> > specification (XEP-0174), using it in a heterogeneous environment can be
> > a challenge. Support for mDNS and DNS-SD are often part of the OS, and
> > have different APIs on every platform. For example, Linux-based systems
> > have Avahi.
> Right. But what's the problem? The fact that you can't write once, run
> anywhere (different APIs)? Or the fact that some platforms don't have
> support for mDNS and DNS-SD?

Both, actually.

> > Also, if you already have a path between entities through the regular
> > XMPP network, it makes perfect sense to use Jingle to establish a direct
> > XML Stream in the face of low-latency requirements. Dan's example would
> > be a media center remote control. 
> Direct over what transport? TCP? I suppose that might work on a LAN or
> home area network (HAN) or even a neighborhood area network (NAN), which
> is the use case that Dan cares about. Hmm, Dan/LAN/HAN/NAN? ;-)

:-) Yes, I believe LAN is the objective here (sitting with your mobile
phone in front of your media center). That said, end-point discovery
might still be a challenge. Definitive matching of end-points both in
and out of bound still needs to happen. Trial and error with several
candidates, like in similar audio/video streaming scenarios, is a
possibility. Some combination of Zeroconf and Jingle could probably help
as well.

> > I'm not particularly convinced about the usefulness of the required
> > implementation of IBB in XEP-0247, though. If you already have a
> > serverful path, but cannot establish a peer-to-peer stream, you can just
> > do the exchanges through regular XMPP, without envelopes.
> I think the reasoning was that we have IBB and anything else you design
> will look an awful lot like IBB, so why not re-use that?

Well, for both in-band and out-of-band structured XML exchange, in this
particular scenario, you could use the exact same stanzas, complete with
addressing. The only difference being the route. For in-band, your
stanzas go through some servers, for out-of-band over the specially
established peer-to-peer XML Stream. It seems pretty useless to encode a
stanza in base64 and wrap it in an envelope with the same addressing.
Unlike streaming binary, the fallback can simply be the regular XMPP

Anyway, the raison-d'être of this specification might be thin. Low
latency is the foremost advantage I can think of. Lack of platform
support, or ease of implementation in them, is probably not a very good
reason for new protocol. Serverless Messaging would then be the
solution, albeit without an obvious way to match entities, so far.


More information about the Standards mailing list