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

[Doug Royer <[e-mail]>]

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.

YES!

> 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)
[e-mail]
714-989-6135