Re: [apps-discuss] Aggregated service discovery

Mark Nottingham <> Wed, 23 May 2012 06:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23DE321F855D for <>; Tue, 22 May 2012 23:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TDnW6pDnB6wx for <>; Tue, 22 May 2012 23:29:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5EA6521F8552 for <>; Tue, 22 May 2012 23:29:36 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6C0F222E257; Wed, 23 May 2012 02:29:26 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <>
In-Reply-To: <64C6DF43A866F40437AF4CC3@cyrus.local>
Date: Wed, 23 May 2012 16:29:24 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <64C6DF43A866F40437AF4CC3@cyrus.local>
To: Cyrus Daboo <>
X-Mailer: Apple Mail (2.1278)
Subject: Re: [apps-discuss] Aggregated service discovery
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 May 2012 06:29:37 -0000

If they're HTTP - <>

Not yet convinced that well-known is needed for this yet; it's effectively substituting a hostname for a full URL.


On 23/05/2012, at 1:00 AM, Cyrus Daboo wrote:

> 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 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
> _______________________________________________
> apps-discuss mailing list

Mark Nottingham