RE: [discovery] Network Service Discovery: current status

Rich and all,

Thank you for the great work.

Being a service provider, we believe that the feature for connected device integration is very important for serving consumers in next generation of web-based home environment. It benefits all stakeholders in the ecosystem.

Thus we support the continuation of this important work item in W3C, and we look forward to more implementations in browsers on market.

Thanks
Bin

-----Original Message-----
From: Rich Tibbett [mailto:richt@opera.com] 
Sent: Thursday, September 04, 2014 5:13 AM
To: Device APIs Working Group
Subject: [discovery] Network Service Discovery: current status

Responding to feedback from the Web and TV IG [1] we began drafting a
Network Service Discovery API proposal [2] within this group. Today we
have two prototype implementations [3] [4] and tentative Intent to
Implement approval within Chromium [5].

The strongest API concerns have related to the security of sharing
existing UPnP, Zeroconf and DIAL services with web pages. We have
since added additional features to the NSD API proposal to mitigate
these issues: requiring network-based services to 'opt-in' to web
sharing by implementing appropriate CORS headers before they can be
shared with web pages. Additionally we have left open the ability for
implementers and/or users to 'whitelist' their own network services
for web sharing at their own request. In such whitelisting,
implementations would then simulate the cross-origin resource sharing
as if CORS were supported natively in the whitelisted network-based
service itself.

An additional concern related to the permissions required to obtain
access to network services discovered via this API. The NSD API
proposal requires that users actively select the services that a web
page can interact with through a runtime permission dialog. A web page
will request a well-known network service type and then the UA (when
it is aware or can discover matching services on the local network via
the CORS/whitelisting checks described above) would provide the user a
dialog to share access to selected network services with the
requesting web page.

We previously prototyped this API within Opera [4] and we then had to
put this work on hold while we switched engines from Presto to Blink.
We are now considering whether we want to implement this API in
current Opera browsers given the use cases we have that could benefit
from the availability of a _generic_ network-service discovery
interface.

So feedback from group participants - both implementers and developers
- would be welcome on the following questions:

1. Is generic network service discovery and communications
bootstrapping important for the web?

2. Does this group want to continue working on a generic network
service discovery and communications bootstrap mechanism?

3. Does this group want to continue working on this against the
current API proposal [2]?

4. Have we reasonably addressed the above security concerns for the
current API proposal [2]?

5. Does anyone have additional plans and/or a roadmap to share
relating to this feature?

Looking forward to feedback.

Best regards,

Rich

[1] http://www.w3.org/TR/hnreq/


[2] https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html


[3] http://jcdufourd.wp.mines-telecom.fr/2013/05/15/network-service-discovery-api/


[4] https://dev.opera.com/articles/network-service-discovery-api/


[5] https://groups.google.com/a/chromium.org/d/msg/blink-dev/HT0KZKuTLxM/IC4bUbmOmYcJ

Received on Monday, 15 September 2014 19:50:00 UTC