- From: Rich Tibbett <richt@opera.com>
- Date: Fri, 20 Sep 2013 20:43:49 +1000
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: Giuseppe Pascale <giuseppep@opera.com>, FABLET Youenn <Youenn.Fablet@crf.canon.fr>, "public-device-apis@w3.org" <public-device-apis@w3.org>, public-web-and-tv <public-web-and-tv@w3.org>
On Fri, Sep 20, 2013 at 6:18 PM, Dominique Hazael-Massieux <dom@w3.org> wrote: > Le vendredi 20 septembre 2013 à 17:28 +1000, Rich Tibbett a écrit : >> So there are a number of directions we could take this in: >> >> 1. Focus the specification around a CORS-only solution. CORS is an >> accepted mechanism to allow cross-origin communication on the web and >> could work well in the local network environment also. The problem >> with adopting a CORS-only approach is we have zero devices currently >> ready to step in to this brave new world with us. A specification that >> allows you to connect with precisely zero network services will not be >> useful. > > I think that no matter what, the spec should support a CORS-based > approach. A CORS approach only? As I said, there are no services I'm aware of that would work with that today so we would also have to see if device vendors are interested in releasing CORS-based devices and services. I know we have a few device vendors on this list so it would be good to hear their opinions at this point. > >> 2. Support whitelisting of specific local network services in the user >> agent, at the user's request to enable communication with those >> services. Even if we went with a CORS-only approach (see (1.) above), >> this could be a practical fallback to support existing/legacy network >> services. This would provide non-CORS-enabled services with the same >> privileges as CORS-enabled services from the user agent without the >> service itself needing to support CORS implicitly (as also proposed in >> the current NSD API specification). > > I support the idea (at least in theory — it would remain to be seen > whether any user agent would feel confident to support such a > whitelist); but given that this is an exception mechanism, I'm not even > sure it needs to be specified — since the user agent is ultimately > responsible for managing the same origin policy, user-specified > exceptions to that policy (which such a whitelist would be) seem beyond > what we need to define for interoperability. Or did you have in mind > some specific aspects that would need to be spec-d here? It may warrant a note in the spec to say that a user agent MAY whitelist non-CORS-enabled network services and that if it does so it MUST pass through XHR/WebSocket messages to the network service endpoints as if they were CORS enabled. Other than that, I don't anticipate any other issues with interoperability. > > Dom >
Received on Friday, 20 September 2013 10:44:16 UTC