Re: [apps-discuss] Aggregated service discovery

Mark Nottingham <mnot@mnot.net> Wed, 23 May 2012 06:29 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DE321F855D for <apps-discuss@ietfa.amsl.com>; Tue, 22 May 2012 23:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDnW6pDnB6wx for <apps-discuss@ietfa.amsl.com>; Tue, 22 May 2012 23:29:36 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA6521F8552 for <apps-discuss@ietf.org>; Tue, 22 May 2012 23:29:36 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.21.48]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (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 <mnot@mnot.net>
In-Reply-To: <64C6DF43A866F40437AF4CC3@cyrus.local>
Date: Wed, 23 May 2012 16:29:24 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <22873D37-8462-48AE-ABA0-49445776E4CC@mnot.net>
References: <64C6DF43A866F40437AF4CC3@cyrus.local>
To: Cyrus Daboo <cyrus@daboo.name>
X-Mailer: Apple Mail (2.1278)
Cc: apps-discuss@ietf.org
Subject: Re: [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: Wed, 23 May 2012 06:29:37 -0000

If they're HTTP - <https://datatracker.ietf.org/doc/draft-nottingham-json-home/>

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

Cheers,


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

> 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
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/