Re: DAP Request: Feedback on Applicability and implementation plans for Network Service Discovery

I agree. Enabling both use cases would be ideal.

-Clarke

On 4/24/14, 7:12 PM, "Clift, Graham" <Graham.Clift@am.sony.com> wrote:

>Mark,
>
>I see. Pushing content to devices is the easier path to start with. I was
>also thinking about a way of being able to search for and pull content
>into the web page too by abstracting the url to that content, which is a
>trickier proposition but I think still doable.
>
>Regards
>
>Graham
>
>-----Original Message-----
>From: Vickers, Mark [mailto:Mark_Vickers@cable.comcast.com]
>Sent: Thursday, April 24, 2014 6:05 PM
>To: Clift, Graham
>Cc: Daniel Davis; public-web-and-tv; frederick.hirsch@nokia.com;
>public-device-apis@w3.org; Dominique Hazaël-Massieux; Rich Tibbett; Amol
>Bhagwat
>Subject: Re: DAP Request: Feedback on Applicability and implementation
>plans for Network Service Discovery
>
>Graham,
>
>I think that's exactly what I'm suggesting. For example, to print today,
>the external website-based Web app calls window.print(), which is an
>abstract request for a printing device that "abstract[s] away all the
>device/content discovery in the UA such that the application never knows
>anything about what [printer] is on the LAN". The UA then does discovery
>and handles the printing protocol.
>
>The new  Second Screen PresentationCG is similarly proposing a new
>abstraction, navigator.presentation.requestShow(), that enables a website
>to play video to a TV or other display, while hiding AirPlay, ChromeCast
>or HDMI protocols.
>
>As I say below, I think this approach can be extended, safely, from files
>and printing to any LAN service.
>
>Thanks,
>mav
>
>
>
>On Apr 24, 2014, at 5:52 PM, Clift, Graham <Graham.Clift@am.sony.com>
>wrote:
>
>> I would go along with Mark's idea but maybe take a few steps further.
>> 
>> It would be very interesting to see a proposal for NSD that provided
>>the richness that a CORS enabled NSD solution offers but without the
>>dependency on CORS or without any dependency on the users faith in
>>privacy/security of an application when it accesses the LAN.
>> 
>> One way I see (and maybe there is something already in the space) is to
>>abstract away all the device/content discovery in the UA such that the
>>application never knows anything about what is on the LAN but has an
>>abstract reference to it that only the UA understands how to translate
>>and that the UA can present to the user for selection when instructed to
>>by the application, the result of the selection then being sent to the
>>application again as an abstract reference. The application can only
>>know that there is some device there that can play a piece of content,
>>or that there is some kind of content out there that meets a search
>>criteria that it itself can play. However it never sees device names,
>>friendly names,  content names and so on. When playing content the url
>>is even abstracted such that only the UA can translate (underneath the
>>video element for example) into a real location for the content.
>> 
>> Done this way I don't see why there would be concerns over CORS or
>>privacy/fingerprinting.
>> 
>> Regards
>> 
>> Graham
>> 
>> -----Original Message-----
>> From: Vickers, Mark [mailto:Mark_Vickers@cable.comcast.com]
>> Sent: Thursday, April 24, 2014 4:38 PM
>> To: Daniel Davis
>> Cc: public-web-and-tv; frederick.hirsch@nokia.com;
>> public-device-apis@w3.org; Dominique Hazaël-Massieux; Rich Tibbett;
>> Amol Bhagwat
>> Subject: Re: DAP Request: Feedback on Applicability and implementation
>> plans for Network Service Discovery
>> 
>> +Amol
>> 
>>> * Are device manufacturers willing to support CORS in order to enable
>>>NSD support?
>> 
>> A key thing would be to work with organizations that define home
>>networking protocols (UPnP, DLNA, .) to review the spec and see if they
>>want to add a CORS requirement to their specifications. Giuseppe has
>>initiated those conversations.
>> 
>> Of course, this only gives access to the subset of future devices that
>>add CORS support. It doesn't give access to any existing home network
>>devices.
>> 
>> As I've mentioned before, there is another, universally deployed model
>>that allows full access to any existing LAN devices without a new W3C
>>spec and safely avoids the security issue. Instead of giving external
>>websites access to the LAN (which drives the security requirements), the
>>user agent can provide access to the LAN. Since the device running the
>>user agent is already behind the firewall on the LAN, it can access the
>>LAN services without extra security. The user agent needs to provide a
>>user interface for any specific or general LAN access. Examples of this
>>are:
>> 1. How every browser prints a web page to a LAN printer 2. How every
>> browser saves website files to a LAN storage device 3. How Safari's
>> Bonjour menu browses LAN devices
>> 
>> This approach could be applied to any given LAN service and implemented
>>by:
>> a. Browser vendors (e.g. 1-3 above)
>> b. Browser extensions (e.g. GoogleCast extension, which plays video to
>> ChromeCast devices or vGet Chrome Extension, which plays videos to
>> discovered UPnP/DLNA devices) c. External spec groups by mandating
>> user agent behavior (e.g. DLNA CVP-2, which specifies that user agents
>> must implement DLNA protocols to discover and connect to LAN-based
>> video service gateways, which provide the URL for the browser. Since
>> the user agent finds the resources before the browser is started,
>> there was no need to add any LAN access APIs like NSD.)
>> 
>> I still think this a superior model for integrating the LAN into the
>>Web.
>> 
>> Thanks,
>> mav
>> 
>> On Apr 16, 2014, at 11:55 PM, Daniel Davis <ddavis@w3.org> wrote:
>> 
>>> Hello Web and TV IG members,
>>> 
>>> Unfortunately there wasn't much time to discuss this on yesterday's
>>> call but we'd still like feedback to Frederick's questions below and
>>> your thoughts on the Network Service Discovery (NSD) API.
>>> 
>>> For example:
>>> * What would be necessary to keep interest in the API going?
>>> * Are device manufacturers willing to support CORS in order to enable
>>> NSD support?
>>> * Are stakeholders willing to work with user agent vendors for
>>> implementation?
>>> 
>>> and similar comments.
>>> 
>>> Thank you in advance,
>>> Daniel
>>> 
>>> On 10/04/14 04:58, Frederick.Hirsch@nokia.com wrote:
>>>> Dear Web & TV Interest Group Chairs and members:
>>>> 
>>>> The Device APIs working group [1] has produced a "Network Service
>>>>Discovery" draft [2] in which the Web & TV Interest Group [3] has
>>>>shown interest [4].
>>>> 
>>>> "This specification defines a mechanism for an HTML document to
>>>>discover and subsequently communicate with HTTP-based services
>>>>advertised via common discovery protocols within the current network."
>>>> 
>>>> This allows a web page to discover and establish communication with
>>>>services on a local network. The specification takes into account
>>>>Zeroconf, SSDP and DIAL.  The specification does not define the
>>>>application communications once the connection is established.
>>>> 
>>>> We are concerned that we will not have adequate implementer interest
>>>> in this specification to justify progressing it further [5][6][7],
>>>>and are thus wondering if the the Web & TV Interest Group, as a
>>>>"customer" of this work would be willing to work with us on obtaining
>>>>implementers input and feedback on this specification. Without proper
>>>>interest from implementers the Device APIs Working Group would have no
>>>>other option than to stop work on it.
>>>> 
>>>> We are seeking feedback from the Web & TV Interest group and
>>>>implementers to the following questions:
>>>> 
>>>> 1. Does this specification address use cases and needs of concern to
>>>>you? 
>>>> 
>>>> 2. In particular, in light of the recent additional requirement of
>>>>CORS [8] support from local network services, it is likely that this
>>>>specification would only work with recently updated devices. Do you
>>>>plan to deploy CORS support in your UPnP/DIAL/Zeroconf based devices?
>>>> 
>>>> 3. Are you working on implementations of this specification? If so,
>>>>have you determined whether these implementations are likely to find
>>>>their way into a well-deployed browser?
>>>> 
>>>> 5. Can you provide any assistance in determining implementers plans,
>>>>and possibly work with implementers on providing input and feedback on
>>>>the future of this specification?
>>>> 
>>>> Feedback you give us is important to DAP taking appropriate next
>>>> steps and will be much appreciated. Please send any comment to the
>>>> DAP public list (cc'd) , public-device-apis @ w3.org
>>>> 
>>>> Thanks
>>>> 
>>>> regards, Frederick
>>>> 
>>>> Frederick Hirsch, Nokia, @fjhirsch
>>>> Chair Device APIs Working Group
>>>> 
>>>> [1] http://www.w3.org/2009/dap/
>>>> 
>>>> [2] http://www.w3.org/TR/2014/WD-discovery-api-20140220/
>>>> 
>>>> [3] http://www.w3.org/2011/webtv/
>>>> 
>>>> [4]
>>>> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/att-0
>>>> 0
>>>> 98/minutes-2011-07-20.html#item07
>>>> 
>>>> [5]
>>>> http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/att-0
>>>> 0
>>>> 24/minutes-2014-03-27.html#item08
>>>> 
>>>> [6]
>>>> https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/
>>>> n etwork$20service$20discovery/blink-dev/HT0KZKuTLxM/S3w-SdvjZfUJ
>>>> 
>>>> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=914579
>>>> 
>>>> [8] http://www.w3.org/TR/cors/
>>>> 
>>>> For tracker, this completes ACTION-687
>>>> 
>>> 
>> 
>> 
>> 
>> 
>
>
>
>

Received on Friday, 25 April 2014 04:38:47 UTC