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

Eric Burger <eburger@standardstrack.com> Mon, 08 February 2016 15:43 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210741B2D47 for <apps-discuss@ietfa.amsl.com>; Mon, 8 Feb 2016 07:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level:
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no
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 yImkmUuLNdpf for <apps-discuss@ietfa.amsl.com>; Mon, 8 Feb 2016 07:43:38 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F83D1B2D4D for <apps-discuss@ietf.org>; Mon, 8 Feb 2016 07:43:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=SVFuMc7JX01xlTn+o9Bp7nK4uEz2/hQHumnkimgjBAg=; b=RRz8FSnN06IKrkQnAtNJmSd8EBZH194Fx3yUBZj/yqTAcnkDTbVPsxi0rUvJG4C3ht0x3ewwZg+TAIfe1KMTKLS9JWn/ZXv43GaQCl8V1MyDdAc2hNVQGO9sSq8ztwzenAzBznCINwUi5tL6l4ty5SHMSwkzl/5ncrnylIPgJcM=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:50880 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from <eburger@standardstrack.com>) id 1aSnyS-0004Pb-B1 for apps-discuss@ietf.org; Mon, 08 Feb 2016 07:43:38 -0800
Content-Type: multipart/signed; boundary="Apple-Mail=_9CF04B92-977F-42FA-A5AE-566FE04F6EDE"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Pgp-Agent: GPGMail 2.6b2
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com>
Date: Mon, 08 Feb 2016 10:43:34 -0500
Message-Id: <8D50E1C3-46FB-4341-B06A-86902B984AEC@standardstrack.com>
References: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney> <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com>
To: apps-discuss@ietf.org
X-Mailer: Apple Mail (2.3112)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/aF9sRSu8-x2hgEK09txfoAM0vU4>
Subject: Re: [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 08 Feb 2016 15:43:40 -0000

Perhaps an application-layer DHCP?

> On Feb 8, 2016, at 9:54 AM, Cyrus Daboo <cyrus@daboo.name> wrote:
> 
> 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
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss