Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity
John C Klensin <john-ietf@jck.com> Tue, 07 February 2017 20:54 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AE1129613; Tue, 7 Feb 2017 12:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 TABe48b23GSS; Tue, 7 Feb 2017 12:54:19 -0800 (PST)
Received: from bsa2.jck.com (ns.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 AE56B1294A5; Tue, 7 Feb 2017 12:54:19 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cbCmG-000NRc-9V; Tue, 07 Feb 2017 15:54:16 -0500
Date: Tue, 07 Feb 2017 15:54:09 -0500
From: John C Klensin <john-ietf@jck.com>
To: Randy Bush <randy@psg.com>, Gren Elliot <fatkudu@gmail.com>
Subject: Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity
Message-ID: <9D66E5E7619E1C55F1DEB959@PSB>
In-Reply-To: <m2poitydi9.wl-randy@psg.com>
References: <CAMQk0F-6CFLHKvTxSaPV20Lp-hVOSSk_WrHOGq6-LOUO8aDNww@mail.gmail.com> <m2poitydi9.wl-randy@psg.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/qVkNRhFfqqRz7h7A6GT5D7FIMMY>
Cc: jmap@ietf.org, iesg@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2017 20:54:21 -0000
I agree with most of Dave Crocker's comments and don't have much time to spend on a proposal that, if approved, I believe (for reasons that overlap those he cites) will, like many of its predecessors, die a quiet death after wasting a lot of time. However, the exchange surrounding one of Randy's comments prompts a further remark or two... --On Wednesday, February 8, 2017 05:03 +0900 Randy Bush <randy@psg.com> wrote: >> Why? You will either be using IMAP/SMTP to access your >> mail/submit your messages or you will be using JMAP. If you >> have the option of the latter, youʼve just halved the number >> of things that need configuring. > > how does the server forward the submitted mail to the global > internet? > > how does the server migrate 200 or 2,000 imap users at human > speed, i.e. over months? So, suppose I have a mail server that, because it is configured in the real world, has to support SMTP and IMAP (and maybe POP3) for existing users while trying to support new MUAs that use this JMAP stuff. Randy suggests that requires configuring three kinds of systems. I suggest that he underestimates the problem. First, there is not just "configuring" but "supporting". Working with configurations may be an infrequent activity. Providing support is a continuing one and takes time, even if one's idea of support is saying "what do you want for nothing, figure it out yourself" in a firm tone and at frequent intervals. A change from an IMAP/SMTP base to supporting a new model or representation and systems that provide it vastly increases that job, and increases it by at least a factor of three (old one, new one, people considering or trying to make the transition). Second, there is an issue that Randy and Dave both hinted at in different ways. Unless the proposal is to use Jmap end to end, replacing SMTP, conversion issues have to be worked out. The community made a series of decisions around the time MIME was adopted that essentially require that the SMTP payload be either unstructured messages (essentially conformant to 822) or MIME. The previous (albeit controversial) idea that, other than trace fields inserted by SMTP MTAs, SMTP could treat the message as header-free and opaque and carry material that was not at least 822-conformant is history. That means one needs to configure, maintain, support, and debug: SMTP IMAP JMAP SMTP/Standard Message Headers -> JMAP for inbound messages JMAP -> Message Submission for outbound messages. That is a big deal. There better be a lot of added value to justify it or it will go nowhere (a slightly different negative analogy to the rapid and overwhelming success of IPv6 is perhaps obvious), just as a variety of grand solutions to real or imagined problems with email have gone nowhere. With this proposal, I see some small incremental improvements for systems that are working in JSON environments anyway, but nothing that would justify widespread implementation and deployment. The answer might be different for a mail system that assumed that all users would be using the same mail store and either webmail or JSON-based clients/MUAs. But such mail systems exist only in proprietary walled gardens and should not be IETF topics except possibly for mail gateways to and from them. And those gateway raise most of the issues outlined above. TL;DR summary: Just say 'no'. john
- Re: WG Review: JSON Mail Access Protocol (jmap) Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Alexey Melnikov
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Adrien de Croy
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Phillip Hallam-Baker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Neil Jenkins
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Gren Elliot
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Randy Bush
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Gren Elliot
- Fwd: Re: [Jmap] WG Review: JSON Mail Access Proto… Gren Elliot
- Re: [Jmap] service discovery, was WG Review: JSON… John Levine
- Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access P… Dave Crocker
- Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access P… Randy Bush
- Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access P… John C Klensin
- Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access P… Adrien de Croy
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Neil Jhaveri
- Re: Fwd: Re: [Jmap] WG Review: JSON Mail Access P… Gren Elliot
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Joe Hildebrand
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Neil Jenkins
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Yoav Nir
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Cridland
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Alexey Melnikov
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Alexey Melnikov
- Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Acc… Alexey Melnikov
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Andrew Sullivan
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Alexey Melnikov
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Spencer Dawkins at IETF
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John C Klensin
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Alexey Melnikov
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Ted Hardie
- Re: WG Review: JSON Mail Access Protocol (jmap) -… John Levine
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Alexey Melnikov
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Pete Resnick
- Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access P… Ted Lemon
- Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access P… Dave Crocker
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… ned+ietf
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John Levine
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Phillip Hallam-Baker
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John C Klensin
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Dave Cridland
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Dave Crocker
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John C Klensin
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… John C Klensin
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Dave Cridland
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Dave Cridland
- Re: [Jmap] WG Review: JSON Mail Access Protocol (… Ted Lemon
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… Alexey Melnikov
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… ned+ietf
- Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail… John C Klensin