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@xxxxxxx> 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