[apps-discuss] Aggregated service discovery

[Cyrus Daboo <[e-mail]>]

Hi folks,
Today many protocols define their own "service discovery" protocols (e.g., 
<http://tools.ietf.org/html/rfc6186>, 
<https://datatracker.ietf.org/doc/draft-daboo-srv-caldav/>, 
<http://tools.ietf.org/html/rfc6125>).

>From a client perspective, these each work fine individually. But more 
often than not, a client device actually wants to be able to discover all 
services a "service provider" has available or provisioned for the user. 
i.e., a user expects email, calendar, contacts, IM, directory etc to be 
setup in one step by the client, rather than having to go and setup each 
service separately. Whilst a client can present a single UI for such an 
"aggregated service discovery" it still has to go use separate discovery 
protocols for each service. This is expensive - lots of separate DNS 
lookups, etc.

Several proprietary systems offer and "aggregated service discovery" 
protocol - in its simplest form a GET on a well known URI that returns an 
XML document listing available services and other useful configuration 
information.

It is time we had such a protocol for the IETF standard suite of protocols. 
In particular implementors involved in the Calendaring and Scheduling 
Consortium are very keen to see a good solution to this problem. So I am 
starting a discussion on this here to solicit some ideas about how best to 
approach this, with a view to writing a draft.

The obvious, and simplest approach, is the HTTP GET on a .well-known URI 
returning an XML or JSON document with a standard "schema".

Another possibility is to leverage the webfinger work. I'd like to hear 
from webfinger experts as to whether a use case like this would be a 
reasonable solution. Some concerns I have are the security "scope". 
Obviously service discovery is something that a user does for themselves 
and their service information should be private, which seems somewhat 
contrary to the primary user case for webfinger whether other users are 
looking up the information.

Security, simplicity and efficiency are the key goals for this protocol.

Comments, ideas?

-- 
Cyrus Daboo