[Top] [All Lists]

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

2016-11-09 13:56:37
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 
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
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
- 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)

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>