Re: [Jmap] Submission is not hard

["John Levine" <[e-mail]>]

In article <[e-mail]> you write:
>I think the distinction comes from whether you actually think that the SMTP submission protocol is always going to be what's behind a message
>submitted via JMAP.   If you think that, then it's going to look really weird to not just replicate that exact paradigm with the JMAP submission process.

Um, this is the IETF.  If you want to invent a new, different, and
incompatible mail system, JMAP is definitely not the place to do so. 

I am scratching my head about why people are having such trouble with
the submission model.  It's not complicated.  The message goes into a
queue, the envelope and message are separate, the envelope addresses
can have annotations, and the server tells the client what optional
features it supports.  That's it.  The options are, you know,
optional, but many of them are useful.

Before someone suggests that we should use some better scheme, I would
point out that a lot of mail transport designs have come and gone over
the past 40 years, and all of the others are dead.  You're going to
need a really good story about why this time is different.

There's also a lot of issues that are really quality of
implementation.  For example, I agree that a server that doesn't
support 8BITMIME would be pretty lame, and I would not blame a client
that refused to work with it (and unsurprised to find that the MUA on
my phone already does that.)  But the place to deprecate not-8BITMIME
is in 5321bis, not here.

Finally, if people want to try whizbang ways to show animations of
mail zipping through the aether, that sounds like a swell optional
add-on to try and implement and test and perhaps bring back later as
an extension, but it'd be nuts to try to invent it now.

R's,
John