(I hadn't seen the draft charter text until now, due to some
unfortunately behavior in my email filters.)
As with others, I think the draft charter has a number of very basic
problems. I think there are several real issues and that some efforts
to respond to them could be useful, but that we need far more clarity
about needs and associated responses, and we need far more narrow
sequencing of those efforts to respond. In its current form, this draft
charter is, IMO, far too scatter-shot and complex, and has far too
little justifying foundation.
Many companies and projects are developing their own JSON based
representations of email which are proprietary, non-standard, and
incompatible with each other. These protocols are proliferating due
to existing standards being insufficient or poorly suited to the
environments they are operating in, particularly mobile and webmail.
As with others, I take 'representations' to mean formats. And given
what JSON is that seems an appropriate interpretation even without
that word. So I take this asserted need as having a form of email data
format that is an alternative to RFC 5322/MIME.
Prior to chartering, we should document just how extensive the current
problem of multiple JSON email formats is, to establish the practical
benefit of unifying it. The theoretical benefit should be obvious, but
that's not enough to justify the cost of a working group. We should
establish real market need.
Having spent quite a bit of my early career on email gatewaying, I'll
comment that getting a common interchange format is especially powerful.
The active protocols aren't irrelevant, but stabilizing the message
object itself is, IMO, far more important. I'm more than a little biased
about this strategic approach: It provided the unifying base for email,
during the Internet's early growth into commercial markets. And it
happens that focusing on this narrow requirement permits end-to-end --
and I mean the real kind: author to recipient, not just originating
operator to receiving operator -- benefits without having to change the
infrastructure, other than insertion of gateways.
Working groups need task serialization. So I'll suggest that having an
effort to standardize an JSON representation of an RFC5322/MIME object
would be the highest-leverage first task.
And not a trivial effort...
As for the remaining effort(s)...
The JMAP working group will specify an mechanism to allow clients to
both view and send email from a server over a single stateless HTTPS
channel with minimal round trips.
There is no justification given for this approach. For each activity,
there needs to be a clear and solid need documented, based on actual
industry activities or at least industry statements. Besides clarifying
/what/ needs doing, it should serve to indicate likely industry uptake
after the work is done.
The protocol will support
out-of-band signaling of changes, and will give mobile clients
significant benefits in terms of battery life and network usage.
So, that sounds like some sort of need, but it isn't clear to me what it
The use of multiple protocols to perform actions within a single
application creates significant support challenges, as users may get a
variety of partial failure modes (for example, can receive email, but
can not send new messages). This is further exacerbated if the
different protocols are authenticated separately
Ditto. Worse, any claim that an alternative would be better needs to be
justified both in terms of its considerable effort and its purported
improvement. Unification efforts have a habit of re-creating complexity
and providing little actual benefit.
Note, for example, that the IETF email community debated whether
submission should be independent of IMAP or integrated into it. It was
a one-year debate and, IMO, was conducted in a highly informed, diligent
and constructive fashion. That the result was to maintain separation
should not be ignored...
The working group will deliver the following:
- A problem statement detailing the deployment environment and
situations that motivate work on a new protocol for client to
server email synchronisation. The working group may choose
not to publish this as an RFC.
- A document describing an extensible protocol and data structures which
supports stateless use, flood control and batched operations.
Since client/server email access typically benefits from having the
server retain state about the client's activities, I can't tell whether
this actually means stateless lower-level transport or whether it really
does mean a stateless email protocol. So this needs to be made much
more clear, as to the what and the why, as well as to the benefit that
- A document describing how to use the extensible protocol over HTTPS
with the data structures expressed as JSON.
Given the considerable complexity of HTTP, I continue to fail to see why
making it be a universal, lower-layer transport is so popular. Again,
the need and the benefit need to be documented.
- A document describing a data model for email viewing, management,
searching, and submission on top of the extensible protocol.
- An executable test suite and documented test cases to assist
developers of JMAP servers to ensure they conform to the
This last is useful, but I think it's not typically an IETF work product?
A charter is more than a work statement. It is a marketing tool for
recruiting industry support. Hence the need for explanatory text that
makes needs and benefits clear, as well as specification of deliverables.
ietf-smtp mailing list