[Standards] New XMPP Use Case: Private Media Networks
dmeyer at tzi.de
Wed May 21 18:18:55 UTC 2008
Dave Cridland wrote:
> This looks interesting. Particularly so because of the case allowing
> information flow between "public" services and "private" media
> I'm thinking particularly of data stores such as the BBC's Programmes
> thing, but this would be equally applicable to a number of cases I'd
> imagine, including being able to watch something my neighbour had
> recorded if I had their permission.
Or even better: if you want to record two shows but only have one
DVB-T receiver and your neighbour does not need his at that time, you
could use it (with his permission).
> This notion of bring these traditionally isolated networks into
> (secure) contact with the internet as a whole seems like a good
> enough reason to go this route on its own - I really like the
> symmetry between accessing your local media store and someone else's
> one remotely via essentially the same mechanism.
>> Unlike a HTTP based approach like UPnP, XMPP provides a much better
>> core for what I call a "Personal Media Network".
> I think that's basically a good plan, but one of the key features of
> UPnP is that it's Plug 'n' Play - specifically, dropping a device
> onto a network essentially makes the device attach and become
> available to the network. Your proposal misses this out, and I think
> that's a critical shortcoming.
You can not have plug and play AND security. In fact, there is a UPnP
security document but I know no device implementing it. So it has to
be plug, insert a pin, play.
> This can be addressed easily by bootstrapping via Link Local XMPP
> (XEP-0174), and using some simple authentication mechanism - akin to
> a Bluetooth pairing - to allow a push of configuration data to "make
> the jump" to client/server XMPP, although that might be somewhat
> overkill - but it allows for physically isolated networks to operate
> perfectly well, too.
Section 8.2 describes how to find an authorization node link local and
the peering in 8.3 is similar (from the users point of view) to
bluetooth peering. For link-local devices it is more or less plug and
play (which the additional pin).
> I don't entirely agree it's using XMPP in an unintended way, really -
> the use of C2C pubsub is unusual, though I like the concept.
> One thing that does immediately ring alarm bells for me, personally,
> is that the design conflates several orthogonal aspects of
> inter-device communication. There's a number of reasons I don't
> like this, in particular because if other protocols and/or profiles
> want to use these, they'd have to reference your XEP piecewise,
> which makes these new XEPs harder to follow.
> I'd encourage you to split out each concept into a distinct document:
> a) One that describes C2C PubSub - maybe, although it's potentially a
> small enough adaptation that it'll need nothing new.
LOL, if you could see my private svn you would see that I moved the
whole section 4 (Service Provider and Controller) in an extra
document, moved it back and the same again. They kept referencing each
other. :) But only moving the C2C PubSub away sounds like a good
> b) One that describes C2C security, although admittedly you may wish
> to punt on this, and simply note that it's an issue that needs
I don't understand what you mean.
> c) One that describes a media device framework using XMPP. I'd fold
> in the "pairing" bootstrap from Link-Local here, but again, this
> might need its own document if it turns out to be "too big".
and d) I guess there could be the need for one higher level bytestream
XEP. This XEP could use direct connections, a TURN or SOCKS5 server
and IBB as fallback. Having a bi-directional datastream XEP could be
very usefull and for transmitting video files, IBB is not an
option. Direct connections may be possible if one node is not behind a
NAT/firewall (e.g. a mobile phone) and also with IPv6. While my home
network is behind an IPv4 NAT, I have a /64 IPv6 network with public
IP addresses for all my devices at home.
> However, I'd reiterate that the subject matter and general concept
> seems solid to me, and well worth persuing.
I like to hear that. :)
Thanks for the feedback,
Microsoft Windows didn't get as bad as it is overnight -- it took over ten
years of careful development
More information about the Standards