RE: [all] [HNTF] Opera's device discovery proposal?

Dear Mr. Rich Tibbett,

The technical proposal aligns with the use case ISSUE-24 very much and meets most of its requirements, I think.

http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/LocalLink#Use_Case:_Local_Link_of_Web_Applications

Sony thinks such ad-hoc local discovery API is very powerful to expand the horizon of the web not only to home networked CE devices but also any kind of networked devices in the world. Indeed, the API would be an enabler of the ubiquitous web which can be accessed by user-agents.

I am very pleased to discuss the use cases and requirements in details regarding to the Local Network Service Messaging APIs. I also suggest you to invoke not only Web and TV IG's members and Device API WG's members but also other members in the discussion because the APIs is general enough to impact on any kind of industries.

Best Regards,

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi　(Tatsuya.Igarashi@jp.sony.com)
NS Development Dept. Technology Development Group 
Sony Corporation
(Voice) +81-3-5435-3252　(Fax) +81-3-5435-3274





> -----Original Message-----
> From: public-web-and-tv-request@w3.org
> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Rich Tibbett
> Sent: Friday, July 15, 2011 6:42 PM
> To: Kazuyuki Ashimura
> Cc: TV and WEB
> Subject: Re: [all] [HNTF] Opera's device discovery proposal?
> 
> Hi Kazuyuki, all,
> 
> Thanks for bringing this to the attention of this Interest Group.
> 
> To clarify, this is a full formal technical proposal from Opera Software
> ASA and is not a personal submission (I just happen to edit that
> proposal on behalf of Opera).
> 
> The proposal is largely informed from the good work that has taken place
> in this Interest Group and in the Home Networking Task Force that was
> created. I've been a subscriber to this IG since its inception and have
> diligently studied everything discussed and contributed. That includes
> emails, wikis, meeting minutes, API proposals, code releases (etc). As
> we progressed it was useful to see that our proposal as it progressed
> seemed to be meeting the requirements and use cases that the HNTF produced.
> 
> Giuseppe, whom you will all know, and I have been collaborating on this
> for some time along with the rest of the Opera team. Giuseppe will
> continue to work actively in this group. Please feel free to discuss
> anything high-level here. My hope is for all technical discussion to
> happen in a chartered W3C Working Group. That working group is currently
> the Device APIs working group until further notice. Please feel free to
> provide any and all feedback (bad e.g. 'we would sooner stick pins in
> our eyes than work with this proposal' OR good e.g. 'we support this
> proposal with/without modifications') to the public-device-apis@w3.org
> list directly.
> 
> Thanks for all your work to date and I look forward to seeing this group
> produce more interesting requirements in the future.
> 
> Best regards,
> 
> Rich Tibbett
> 
> Kazuyuki Ashimura wrote:
> > Hi group, esp. the HNTF,
> >
> > I've found an interesting proposal by Rich Tibbett from Opera on local
> > device discovery that was sent to the Device APIs public mailing list
> > [a and below].
> >
> > Here he points out several issues with the existing approaches, e.g.,
> > CORS [b, c], and proposes a new idea named "Local Network Service
> > Messaging" [d].  Also he mentions our Use Case discussion within the
> > HNTF in his message below.
> >
> > So I was wondering if you all were aware of this proposal, and would
> > ask you for opinion about this.
> >
> > Please note that Rich's disclaimer saying:
> >> Disclaimer: This API proposal does not represent the consensus of any
> >> standards group and should not be referenced as anything other than an
> >> unofficial draft which is a work in progress.
> >
> > [a]
> http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0073.ht
> ml
> > [b] http://www.w3.org/TR/cors/
> > [c] http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing
> > [d]
> http://people.opera.com/richt/release/specs/discovery/Overview.html
> >
> > Thanks,
> >
> > Kazuyuki
> >
> >
> > [ Rich Tibbett from Opera<richt@opera.com>  ]
> >> PROBLEM:
> >>
> >> A number of devices connected within a local network today advertise
> >> service API endpoints to the network, the primary purpose of which is
> to
> >> allow other devices within the same local network to connect, control
> >> and interact with those services through the provided interfaces.
> >>
> >> It is possible today to build native applications that can both discover
> >> and communicate with such local-networked services. There is currently
> >> no standard or, indeed, any particularly easy way to discover or
> >> interact with local devices and services from a web application without
> >> significant technical hackery on the part of the user (see 'current
> >> practice' below).
> >>
> >> We need a way for a user agent, acting as a broker between a user and
> a
> >> web application to discover services via common discovery protocols
> >> (i.e. SSDP and DNS-SD) within the local network, allow web applications
> >> to request a particular service type (or class of service) that it
> >> wishes to interact with and then for a user to authorize that
> >> connectivity based on services found in their local network matching
> the
> >> requested service type. The solution should then enable communication
> to
> >> occur between the authorized web application and the local-networked
> >> service, bypassing or overriding the same-origin policy rule if
> >> necessary to allow for safe and secure cross-domain communication.
> >>
> >>
> >> CURRENT PRACTICE:
> >>
> >> Assuming the user is able to obtain a local-networked service's host
> and
> >> port information, which in itself is a hard task for both technical and
> >> non-technical users alike, the user must then provide that host and port
> >> information to the web application by entering such information in e.g.
> >> a web form and submitting said form. Having got this far the web
> >> application, despite having all the information required to communicate
> >> with a local-networked device/service, is then likely to encounter
> >> another issue, namely the same-origin policy rule which prevents a web
> >> application from communicating with a networked device that does not
> >> share the same host and port origin combination as itself.
> >>
> >> As a solution to this, CORS has been developed to enable cross-origin
> >> messaging from web applications. Within the home network, if the target
> >> networked device happened to provide the HTTP header
> >> [Access-Control-Allow-Origin: *] then there is little problem with the
> >> browser now being able to communicate with the provided host and port.
> >>
> >> However, the majority of local-networked services do not implement CORS
> >> and because [Access-Control-Allow-Origin: *] is generally a bad idea
> to
> >> enable within a local network, it is not really the ideal future-facing
> >> solution within local networks to ensure access is granted only to web
> >> applications that a user has explicitly authorized access to.
> >>
> >> In the vast majority of use cases (from e.g. [1]) communication from
> a
> >> web application to a local-networked service is blocked or inherently
> >> insecure today due to one or more of the issues above being present in
> >> modern web browsers.
> >>
> >> The current practice therefore does not fulfill the requirements of the
> >> initial problem and so we began to consider alternative approaches.
> >>
> >>
> >> PROPOSED SOLUTION:
> >>
> >> To counter the issues identified in the current practice above we
> >> developed a low-level API, produced incrementally over the course of
> the
> >> last few months, that allows a web application to request a particular
> >> service type (or class of service type) and for the user to then be able
> >> to authorize and connect a discovered matching service to the requesting
> >> web application. This enables a user-authorized web application to
> >> control, interact and synchronize content (and otherwise generally
> >> communicate) with home-networked services, negating the operational
> >> issues present in browsers today.
> >>
> >> The proposed solution is available, in its full form, here:
> >>
> >> http://people.opera.com/richt/release/specs/discovery/Overview.html
> >>
> >> A note on CORS: this API is intended to work with or without CORS
> >> support enabled in local-networked services. That is to say, CORS in
> >> combination with e.g. HTTP authentication schemes, assuming such a model
> >> is deployed widely in the future, may provide a good user authorization
> >> model for this API (perhaps even to the point of negating the need for
> >> any specialized Service Discovery user interfaces at all). As it stands,
> >> the proposed solution is intended to work with existing services
> >> deployed within local networks without shoe-horning all communications
> >> in to a future-only CORS model.
> >>
> >> Opera plan to produce an experimental implementation of this API in the
> >> coming weeks and I plan to keep this group updated on its progress.
> >>
> >> In the mean time, you can provide any feedback on this proposal at
> >> public-device-apis@w3.org. I hope we will also see other API proposals
> >> submitted to this group in the coming months.
> >>
> >> Disclaimer: This API proposal does not represent the consensus of any
> >> standards group and should not be referenced as anything other than an
> >> unofficial draft which is a work in progress.
> >>
> >> Best regards,
> >>
> >> Rich Tibbett
> >>
> >>
> >> [1]
> >>
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions#Use
> _Cases
> >
>

Received on Tuesday, 19 July 2011 05:29:02 UTC