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