[apps-discuss] Aggregated service discovery

Cyrus Daboo <cyrus@daboo.name> Tue, 22 May 2012 15:00 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D17EA21F85EF for <apps-discuss@ietfa.amsl.com>; Tue, 22 May 2012 08:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id U2GggpTywYBF for <apps-discuss@ietfa.amsl.com>; Tue, 22 May 2012 08:00:12 -0700 (PDT)
Received: from daboo.name (daboo.name []) by ietfa.amsl.com (Postfix) with ESMTP id 0C05521F8623 for <apps-discuss@ietf.org>; Tue, 22 May 2012 08:00:11 -0700 (PDT)
Received: from localhost (localhost []) by daboo.name (Postfix) with ESMTP id 38EA627BAA87 for <apps-discuss@ietf.org>; Tue, 22 May 2012 11:00:11 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([]) by localhost (daboo.name []) (amavisd-new, port 10024) with ESMTP id Wvci76UPhY1g for <apps-discuss@ietf.org>; Tue, 22 May 2012 11:00:05 -0400 (EDT)
Received: from [] (ip-64-134-190-100.public.wayport.net []) by daboo.name (Postfix) with ESMTPSA id 0FCBC27BAA7C for <apps-discuss@ietf.org>; Tue, 22 May 2012 11:00:04 -0400 (EDT)
Date: Tue, 22 May 2012 11:00:22 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: apps-discuss@ietf.org
Message-ID: <64C6DF43A866F40437AF4CC3@cyrus.local>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2105"
Subject: [apps-discuss] Aggregated service discovery
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 May 2012 15:00:13 -0000

Hi folks,
Today many protocols define their own "service discovery" protocols (e.g., 

>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 

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