On Tue May 20 20:28:34 2008, Dirk Meyer wrote:
I wrote a first draft of a possible XMPP extension which opens new
use
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
and
possible new use cases if all devices of a user can interact with
each
other.
This looks interesting. Particularly so because of the case allowing
information flow between "public" services and "private" media
services.
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
http://www.tzi.de/~dmeyer/media-network.html
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
use
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
solving.
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.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
