W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2012

Re: Extending Network Service Discovery draft with advertisement

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Mon, 12 Mar 2012 14:58:00 +0000
To: Dave Raggett <dsr@w3.org>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <E7EE29FD-DD5D-4986-AF6F-41BF6408A2AA@att.com>
To my earlier response's point, Dave's example is one that I'm having trouble mapping to the HTML5 API mentioned by Richard, except in the case where some home gateway acts as a discovery agent for devices advertising services, and then exposes them to browsers through web pages hosted on the gateway. I think this is reasonable given that gateways may offer a RUI function, and can simplify security management issues as devices/apps can register with the gateway, which then exposes their services according to gateway-owner managed policies.

But I think the multicast approach is more direct, and consistent with the ideas discussed so far in the HNTF.

Thanks,
Bryan Sullivan

On Mar 12, 2012, at 9:24 AM, "Dave Raggett" <dsr@w3.org> wrote:

> On 12/03/12 12:27, Rich Tibbett wrote:
> 
>> Perhaps you could describe in more detail the use case here? Is this
>> about web apps advertising themselves as Local Network Services? That is
>> something I'd particularly like to see proposals for so please forward
>> them here and we can discuss them further. For the most part that's
>> something that I see registerProtocolHandler doing [1].
>> 
>> Best regards,
>> 
>> Rich
>> 
>> [1]
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-navigator-registerprotocolhandler
> 
> 
> Something I've thought about is locally installed web apps that act as
> multiplayer games, and where the game players are all on the same local
> network. You need some way to locate other game players, and an
> efficient means to communicate with them.
> 
> Multicast messaging seems very promising for this purpose, firstly as a
> means to advertise your readiness to play, and secondly as an efficient
> means to distribute events to all players. In practice, multicast
> messages are limited in length, but present no problem for modest sized
> JSON encoded events.
> 
> To avoid security problems, you would limit the multicast port range and
> impose checks on the messages. The users would first need to give their
> consent.  We don't need to limit discovery to UPnP!
> 
> A further idea was to look at privacy friendly local discovery, given
> that multicast packets can typically be read by anyone on the same LAN.
> Sometimes you might care about who can see which devices/services are
> being advertised. The advertisements are encrypted to ensure that only
> intended parties can read them. This is a bit like DRM in that you need
> careful key management.
> 
> -- 
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
> 
Received on Monday, 12 March 2012 14:58:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC