Re: [apps-discuss] Mail client configuration via WebFinger

Claudio Allocchio <> Mon, 08 February 2016 16:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 447A61B2EE9 for <>; Mon, 8 Feb 2016 08:38:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T4N2MuDqmvVx for <>; Mon, 8 Feb 2016 08:38:31 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 869861B2EDD for <>; Mon, 8 Feb 2016 08:38:31 -0800 (PST)
Received: internal info suppressed
Date: Mon, 8 Feb 2016 17:38:28 +0100 (CET)
From: Claudio Allocchio <>
To: Eric Burger <>
In-Reply-To: <>
Message-ID: <>
References: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney> <> <>
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=cyrus; t=1454949509; bh=dqg034xKUITcAXf69J8eJhyU59/HNBjp2MhpXnziG5A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O5w25MosS8bUEJ/Cw6kbMhPu9Ov6gl0YK72T1mWj01MHKrJrTmD8HQXL26S+1SoS7 HtbBTq3TYs1SIm6uAIJAQNmdykDGxrpmvhvMTIreySeMST7Vv4RzwKMmKqS1ZeG+3a 786vXCJMgPdM7PjdHLXib1iJqj8igZo2Luhehp6o=
Archived-At: <>
Subject: Re: [apps-discuss] Mail client configuration via WebFinger
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Feb 2016 16:38:38 -0000

On Mon, 8 Feb 2016, Eric Burger wrote:

> Perhaps an application-layer DHCP?

... or something like the "autoconfig tool" used for eduroam wireless 
service (CAT - Configuration Assistant Tool) ?

it detects which device you are using, you select where you "belong to" 
(which provider/organization/...) and you get your correct configuration 
pushed down to the device...

>> On Feb 8, 2016, at 9:54 AM, Cyrus Daboo <> wrote:
>> Hi,
>> --On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" <> wrote:
>>> If ACAP was going to take off, I think it would have by now.  It did not
>>> and I doubt it will, but I'm absolutely not opposed if we were to somehow
>>> get a bunch of major client developers on board.  We'd need some server
>>> software that is well-supported, too.  We either have to resign to the
>>> fact that it's not going to solve the problem I think we should solve,
>>> that nobody cares to solve this problem, or that we need something
>>> simpler (e.g., a couple of HTTP queries to get config info).
>> As one of the few people who implemented ACP/IMSP and all of that stack I have to say ACAP's time has been and gone. It was way too complicated to implement at the time and nothing has changed. The same could be said of the IETF's original calendaring server effort - CAP (RFC4324) - and in the end a number of people took a more pragmatic approach of building a calendaring protocol using existing technology (HTTP/WebDAV) resulting in CalDAV (RFC4791) that has (at least from my standpoint) been pretty successful. As it turns out I replaced use of IMSP/ACAP in my mail/calendar/contacts client with a simple WebDAV solution - storing preferences on my personal WebDAV share. For the most part that has worked well and is trivial to implement - most of the short comings could be fixed through use of more modern capabilities - likely a JSON solution using HTTP PATCH (RFC5789) and JSON patch/merge (RFC7396).
>> All that said, I do believe that the client account configuration setup is something that needs to be addressed. Indeed I tried to start such an effort at the IETF (via the AppsArea WG) and number of years ago. That was based on work done at the Calendaring and Scheduling Consortium (a group of users and vendors who recognised the need for a common configuration piece). At the time we titled that work "Aggregated Service Discovery" (which morphed into "Automated Service Configuration" (ASCOT) and the last draft for that (now expired) can be found here: <>.
>> That draft used a webfinger-based lookup of a "service configuration document" that could list all relevant accounts a service provider had available for a user. At the time that work stalled partly because there was push back at the BoFs about the scope of the work, and because the stake holders ended up with other priorities that took precedence.
>> Paul and I had an exchange about this prior to him starting this thread, and he felt new work on this should be tightly focussed on just email. I personally believe we need to solve the problem for multiple services, not just one.
>> For email, calendaring and contacts we do currently have a light weight SRV-based account provisioning solution (RFC6186, RFC6764), which works on a per service basis (i.e., one set of requests for each account type). The calendaring/contacts piece of that has been deployed and used by a number of providers and clients. Unfortunately, the email piece has not - a number of major ISP do publish _imaps etc SRV records, but very few, if any, clients make use of that.
>> I also think that since the original ASCOT work, the world has started moving in a slightly different direction - specifically more towards a device management solution. With the wild propagation of mobile devices into the enterprise a number of device management solutions are now available that allow configuring of not only accounts, but provisioning of settings (password policy, VPN certs etc) and applications, documents etc,. These solutions are fairly wide spread in enterprise environments today. Less so in the "personal" device scenario.
>> Right now it is not clear to me that an ASCOT-like solution would be adopted given the use of device management. Before embarking on this we need to take a careful look at whether any solution is likely to be adopted (with the biggest burden likely being on clients/OS vendors to support it). Given the device management solutions already out there, I suspect there would be little value to m,ost of those folks to actually support ASCOT.
>> As an alternative, the IETF might want to take a more serious look at the overall device management solutions, and see if there might be scope for standards in that area. That would allow us to build off something that is already deployed (in a number of proprietary solutions) but is today solving the problem of account setup.
>> PS As it turns out I use a device management tool (one available from my employer - Apple) for managing all my family devices, which includes the ability to push profiles specific to my kids devices for locking down parental control settings and the like.
>> --
>> Cyrus Daboo
>> _______________________________________________
>> apps-discuss mailing list

Claudio Allocchio             G   A   R   R
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;