[discovery] Wide-Area Network Service Discovery and Interaction

At the F2F I was asked to explain the potential of the Local Service 
Messaging proposal [1] to be extended to also cover a web-wide 
intents-based mechanism of discovering and communicating with web-based 
service endpoints. While this is not yet included in the current 
proposal [1], it may become part of the proposal in upcoming iterations 
and is presented here to obtain feedback on the raw idea from interested 
parties before that specification work happens.

To begin, the objective as defined in the new DAP charter [2] is:

"[Define an] API that allows web applications to register themselves as 
handlers/providers based on data string identifiers and an API that 
enables other web applications to discover these handlers/providers and 
gain permission to interact with them."

Adding such a layer to the Local Service Messaging proposal is logically 
proposed as follows:

1. As the user navigates the web, the UA will perform background 
mDNS/DNS-SD discovery processes against each visited domain.

2. If any zeroconf services are advertised on each domain then store 
those services in the 'list of available services' table as defined in 
the current proposal. Only advertised services prefixed with '_web._tcp' 
(in a rtl configuration) will be valid in the wide-area discovery 
process to avoid domain-based services from hijacking or masquerading as 
local services.

3. When a web page requests access to a particular service, make 
available both the local-area services + the wide-area services 
previously discovered and match against the full list. The web page can 
also provide a hint to a particular domain to which it would like to 
give special preference (e.g. 'local' or 'x.com'). If that domain has 
not yet been searched, perform a zeroconf discovery process against the 
preferred domain at run time. Resulting services from preferred domains 
would be listed at the top of the resulting services presented to the user.

4. If the user authorizes one of the suggested services, provide the 
endpoint details to that page in the same way as defined in the current 
spec [1]. UAs will be capable of storing user preferences (e.g. 
preferred or default services per service type, blocked domains, etc) to 
subsequently automate this process going forward.

In summary, the idea is not to provide a registration API for wide-area 
(web-based) services but to layer service registration with the UA on 
top of a well-known and well-defined discovery suite (zeroconf) - 
automating that discovery process in the background while the user is 
naturally navigating different web domains. For web site owners the 
additional responsibility will be to declare DNS records detailing the 
web service endpoints that they provide against whatever service 
identifiers they wish (e.g. _contacts._web_._tcp). Any other web page 
can then request particular service types and connect their web page to 
any given local-area or wide-area service endpoint based on the 
requested service type irrespective of its location.

If anything is unclear please ask away on this mailing list but I hope 
that this is somewhat helpful in showing the potential of the Local 
Service Messaging proposal.

- Rich

[1] http://people.opera.com/richt/release/specs/discovery/Overview.html

[2] http://www.w3.org/2011/07/DeviceAPICharter

Received on Monday, 15 August 2011 09:39:25 UTC