[Standards] New XMPP Use Case: Private Media Networks
dave at cridland.net
Wed May 21 16:30:59 UTC 2008
On Tue May 20 20:28:34 2008, Dirk Meyer wrote:
> I wrote a first draft of a possible XMPP extension which opens new
> cases for XMPP. But before I go into details, let me introduce
> myself: my name is Dirk Meyer and I work at the TZI which is part of
> the University of Bremen. My doctor thesis is about media networks
> possible new use cases if all devices of a user can interact with
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.
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.
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.
> My first (not
> finished) draft can be found at
> Before finishing it and sending it to the XMPP council I want to
> ask on
> this list for some opinions about it. It clearly uses XMPP in a way
> XMPP was not indented to be used, but it could be the base for new
> cases (examples of such use cases are in the document).
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.
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
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".
I think that individually, these would be more readable.
However, I'd reiterate that the subject matter and general concept
seems solid to me, and well worth persuing.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards