Re: [apps-discuss] Mail client configuration via WebFinger
John C Klensin <john-ietf@jck.com> Mon, 08 February 2016 19:26 UTC
Return-Path: <john-ietf@jck.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 346491B3230; Mon, 8 Feb 2016 11:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 6rJaKt--rjFk; Mon, 8 Feb 2016 11:26:38 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DBA1B322C; Mon, 8 Feb 2016 11:26:38 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1aSrSD-0007yY-2w; Mon, 08 Feb 2016 14:26:33 -0500
Date: Mon, 08 Feb 2016 14:26:28 -0500
From: John C Klensin <john-ietf@jck.com>
To: Cyrus Daboo <cyrus@daboo.name>, "Paul E. Jones" <paulej@packetizer.com>, apps-discuss@ietf.org, webfinger@ietf.org
Message-ID: <41CEFD2751A79CA0424C9D3F@JcK-HP8200.jck.com>
In-Reply-To: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com>
References: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney> <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/oHUe1zO6RPt57ocLpCDEUq5YN0g>
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 19:26:40 -0000
Cyrus, Thanks for stepping in on this. A few comments and clarifications below... --On Monday, February 08, 2016 09:54 -0500 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. >... While I was (deliberately) vague, my "look at ACAP" comment was not intended as "go adopt ACAP". My own view of ACAP comes from a different perspective than Cyrus's, but is consistent with the above and some of his other remarks: it seemed to me to be far too "flexible" and complicated for the actual requirements and generally to suffer from a bad case of second system effect. However, I agree with Cyrus that it would be helpful to look at configuration for some class of applications that we can configure in a reasonable way --not just email but also not "everything". I mentioned ACAP because I think looking at it from a "what works, what is needed, and what is unnecessary or harmful decoration" perspective might provide a better real-world starting point than, to paraphrase another comment, starting with Webfinger and whatever buzzwords and formats are in fad at the moment. Perhaps Webfinger (with or without ASCOT) or, as Cyrus suggested in passing, WebDAV, will turn out to be the right answer (I really don't have an opinion) but I think there would still be a lot to learn from the ACAP experience... starting from "no more complex and option-laden than absolutely necessary". >... > 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. And, as Paul and others have pointed out, SRV-based approaches are not particularly well-suited for environments in which the configuration information itself may raise privacy issues or in which per-user or per-device, rather than per-domain, configurations may be needed. SRV approaches might, however, be used to bootstrap the right configuration tools even if they are not those tools. >... > 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. Agreed for either device management or potentially per-user application management, but I'm also suggesting that part of such an effort should be to examine the many approaches we have adopted or tried to adopt to this general class of problems and see what we can learn from them, at least to the extent of avoiding repeating those mistakes. Of course, if there are a collection of almost-good-enough proprietary solutions out there, the two other questions that should be asked are (i) whether, and how, the IETF can actually add value to the situation and (ii) whether those vendors would shift to a standardized, interoperable, mechanism rather than continuing to push their proprietary ones with whatever advantages keeping them proprietary bring. best, john
- Re: [apps-discuss] Mail client configuration via … Eric Burger
- Re: [apps-discuss] Mail client configuration via … Cyrus Daboo
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- Re: [apps-discuss] Mail client configuration via … Dave Cridland
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] [webfinger] Mail client config… Paul E. Jones
- Re: [apps-discuss] Mail client configuration via … Stephen Farrell
- Re: [apps-discuss] Mail client configuration via … Paul E. Jones
- Re: [apps-discuss] Mail client configuration via … Eric Burger
- Re: [apps-discuss] Mail client configuration via … John C Klensin
- [apps-discuss] Mail client configuration via WebF… Paul E. Jones
- Re: [apps-discuss] Mail client configuration via … Dave Cridland
- Re: [apps-discuss] Mail client configuration via … Claudio Allocchio
- Re: [apps-discuss] Mail client configuration via … Paul E. Jones
- Re: [apps-discuss] Mail client configuration via … John C Klensin
- Re: [apps-discuss] Mail client configuration via … John C Klensin
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- [apps-discuss] call blocking was Re: Mail client … t.petch
- Re: [apps-discuss] Mail client configuration via … Eric Burger
- Re: [apps-discuss] Mail client configuration via … Claudio Allocchio
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … Eric Burger
- Re: [apps-discuss] Mail client configuration via … John C Klensin
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker