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

Hi Mark,

Please find my comments inline.

Best Regards,
Louay

> -----Original Message-----
> From: Vickers, Mark [mailto:Mark_Vickers@cable.comcast.com]
> Sent: Freitag, 25. April 2014 01:38
> 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:
I am not sure if we always don't need a Spec. I think it depends from the feature you want to offer. Some Browser features don't need a spec like "print", "save", etc. since they are not accessible from external websites but other features need spec.: An example is the Second Screen Presentation API (https://www.w3.org/community/webscreens/wiki/Main_Page ) which allow external website to display content (html pages) on displays (Chromecast, AppleTV, Miracast, etc.) in same network. Google plans to implement this API in chrome to connect to the Chromecast. The Extension is not needed anymore. 
> 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-00
> >> 98/minutes-2011-07-20.html#item07
> >>
> >> [5]
> >> http://lists.w3.org/Archives/Public/public-device-apis/2014Mar/att-00
> >> 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 07:08:12 UTC