[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
network. 

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.

ralphm




More information about the Standards mailing list