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

Cyrus Daboo <cyrus@daboo.name> Mon, 08 February 2016 14:55 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: webfinger@ietfa.amsl.com
Delivered-To: webfinger@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7A1B2C8F; Mon, 8 Feb 2016 06:55:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1VBbOeWA89w; Mon, 8 Feb 2016 06:55:02 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E121B2C88; Mon, 8 Feb 2016 06:55:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 83C65337E3F8; Mon, 8 Feb 2016 09:54:59 -0500 (EST)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V7TnEtz7TFR; Mon, 8 Feb 2016 09:54:59 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 7E1A1337E3E5; Mon, 8 Feb 2016 09:54:58 -0500 (EST)
Date: Mon, 08 Feb 2016 09:54:56 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: "Paul E. Jones" <paulej@packetizer.com>, John C Klensin <john-ietf@jck.com>, apps-discuss@ietf.org, webfinger@ietf.org
Message-ID: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com>
In-Reply-To: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney>
References: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=4847
Archived-At: <http://mailarchive.ietf.org/arch/msg/webfinger/P2xua6xQFtdrpWV0_NHLXSkHyNU>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webfinger/>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 14:55:05 -0000

Hi,

--On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" 
<paulej@packetizer.com>; 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: 
<https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03>;.

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