Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP

Doug Royer <> Wed, 09 November 2016 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6232F1296C5; Wed, 9 Nov 2016 11:56:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9A67jYmzqG03; Wed, 9 Nov 2016 11:56:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09B7C1296C8; Wed, 9 Nov 2016 11:56:29 -0800 (PST)
Received: by with SMTP id u205so294824114itc.0; Wed, 09 Nov 2016 11:56:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to; bh=2hXEh5XZgn4M/p5K5vzfmK1ZP9ah80DXtNGxbEisYQ8=; b=W9tS68tt0HEgQR5FhBP6oDmntZL44sYOWj1VsuGDsNmvvp9YbwSWqlrhFn5ZMkgDiu cNjUtzBltRNDUrdq9DFPLGGmeN2SMhXug6w4yJLPI8zz+ayQhAfW9BF6dooa7ew9aqQe FQtNY05Oqev4cqJy0FDs+w2ltognBS9S5v/7cBlSxwTMLvqEVUK+egxKdniBzepq2E7P B8r3MtqHvIc+j1sIQRtF9DINQ7wMPadSukVWYWYWGP5YZfIFaANKSsEm0VD/uDrLr/uF SSyFYOoXyqh4R9WcCv9vSWTtEwlBSxqx0IC8oQz1hEUEskMyIN1N9Xx4OQlbQ8zhBF7J aYBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=2hXEh5XZgn4M/p5K5vzfmK1ZP9ah80DXtNGxbEisYQ8=; b=e0oGiNJyeOi1V2rXH2OkJAsg4nILwsCq3GTk5yeQ8keppxv6M81KxwgfsWZhAdAdpZ J2E1y7RGnl2kuFRZJ+7CUAXuIgelUtRSVSvqdbZFedOYE6mQ8qiij0ISRk4vbs4bFv4Y ckkspUMrF3/OLGYFWESWatNv5ZEcpqFdyztXJ5oA7G3Tkqzarrl7jzyi10tzibQH7Ik5 qFAZ0mZ7zlJzf2hvUn4MehyirJVXQvARmXGtja4oKoYDeyoQ4vf/16FkKHELQrCLaX7V HrIg8mT3e+kH3U2gI9vOfRmZDJWOSNnufBisAFsxD2CcTz3yfegxeSdikq8+b2ipbtDQ 4cuw==
X-Gm-Message-State: ABUngvd4kVWcsS6gh7gN4jcKwSxOmv8IAoYvBeanfIGiWPA91fDCtksSeWDtcoCOhPky6Q==
X-Received: by with SMTP id 123mr1036058oie.40.1478721388205; Wed, 09 Nov 2016 11:56:28 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id x36sm361299ota.5.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 11:56:27 -0800 (PST)
To: Ned Freed <>
References: <> <> <56DA516EAC53C07E3F453BA6@JcK-HP8200> <> <>
From: Doug Royer <>
Organization: http://SoftwareAndServices.NET
Message-ID: <>
Date: Wed, 09 Nov 2016 12:56:26 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030907030201010706040102"
Archived-At: <>
Cc: John C Klensin <>, Alexey Melnikov <>,, "''" <>
Subject: Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IMAP extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Nov 2016 19:56:33 -0000

On 11/09/2016 08:15 AM, Ned Freed wrote:
> ... so this is a wash. ...
> ... This is also a wash. ...

Good :-)

> Binary MIME has been around for almost 25 years. SMTP was extended to
> handle it not long after itKaia FIT Boise was defined. And note that it's entirely
> possible to use binary MIME only on SUBMIT and not depend on the
> rest of the infrastructure handling it.

Yes, MIME is awesome. However it is now possible to send, transfer, and 
fetch full binary data. The encoding/decoding cycle now seems to be more 
of a habit, than a need. Time to reverse this process and only encode 
when requested?

> IMAP has had the ability to transfer parts in binary for a long time. And
> IMAP also offers the ability to decode and transfer a encoded part on
> the server side.
> JSON doesn't support binary, but there are various extensions that do.

Yes, that is my point earlier.

>> ...The complexity of the requests and replies are the issue. If its mostly
>> converting IMAP to JSON, the same problems are going to exist.
> Yes and no. Part of the problem with IMAP is that it was designed for
> a very different sort of client than what we have now. (I note that the
> problem SMTP is intended to solve hasn't changed nearly as much.) Getting
> rid of historical baggage will definitely simplify things.

Yes, it was mostly used by command line tools, that allowed you to save 
attachments as files and to decide what part of email you wanted to view.

> IMAP also uses an unnecessarily large number of format variants.


> OTOH, there's absolutely no doubt that there's considerable intrinsic
> complexity in the message access space. Especially given the desire to
> push more and more of the problem to the server.
> On the flip side, basing things on HTTPS adds an enormous amount of
> inherent
> complexity. But most of that complexity is hidden from the majority of
> developers, who won't code HTTPS support directly, preferring instead to
> use any one of the bazillion libraries out there that does it all for you.

Problems that would need to be solved first:

What does a modern MUA's need?

I am not talking about what it takes to make an IMAP aware MUA work. I 
mean what functional needs do they have? (Fetch, fetch body part, 
notifications, get summary information, ...). If the goal is to make 
this new protocol so much like IMAP as to make the coding converting an 
IMAP MUA to a new-protocol faster? Or is the goal to do whatever the 
correct new thing is?

Most of the IMAP command were designed to make command line tools work. 
Those limitations no longer exist. You would get a summary of headers, 
pick which ones you wanted to read. Then perhaps download the attachment 
and save it to a file.

I think the new message fetch protocol could be much simpler.

Polling for email was needed years ago because most computers (or the 
programmers) had difficulty performing asynchronous notifications, or 
multi channel I/O.

Does the new protocol have the server parse the headers and hand them 
over in a more simple-client manner? (You have 10 headers, here they are 
(left side/right side). Or does it send a blob of headers and the MUA is 
responsible for the parsing? Same with body parts.

Does the new protocol help with securing the content in any way? If the 
can is opened, should this be in the that mix of what's changing? How 
can it not be a major issue?

What is needed at the functional level?

> My guestimate is that - and here I'm speaking only of the message access
> space
> - that a HTTPS/JSON approach wins in terms of effective implementation
> complexity, although it is far from clear to me by how much.

I am not a HTTP(s) solves every protocol problem person.

If the WEB MUA had different needs, what exactly are they?
Do they want the HTML formatting done on the server side? Some of it? 
One of the many SMTP, IMAP, and POP ports are already opened on any 
firewall that needs email.

One problem with putting email on port 80/443 is that some companies 
need to control customer private data. And they would now have to block 
by content, not by port. Much is more difficult.

What functional differences are their between WEB email and application 
clients? What differences are their between mobile device needs and desktop?

Doing JSON because its the new thing as the reason, I would think is an 
insufficient reason to disrupt the email process.

This process is going to be a nightmare if the functional needs are not 
nailed down first.


Doug Royer - (http://DougRoyer.US)