Alexey, thanks for the quick followup.
inline...
On 2/6/2017 11:41 AM, Alexey Melnikov wrote:
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.
I don't think there is intent to specify full mapping of RFC5322/MIME to
JSON. IMAP has BODYSTRUCTURE element that contains parsed representation
of message structure and most commonly used header fields for different
body parts. The intent is to do the same here.
Additionally, it is still possible to retrieve full RFC5322/MIME
payloads over JMAP.
This highlights the need to have far more clarity about what specific
work is to be done and what is not. The existing text has some generic
out-of-scope text, but nothing as frankly useful as your above comment.
Given that comment, I can't text what parts of the resulting jmap
service will use 'native' Internet Mail technical details and what parts
will be new-for-JSON.
I have tried to reflect your comments in the Charter, but I struggled a
bit. If you can suggest how to make the above clearer, that would be
much appreciated.
I make a point of offering candidate text when I think I understand the
context and needs well enough. Unfortunately I don't have that here.
Hence, questions and general suggestions is the best I can offer. Sorry.
Adding to this:
JSON is a meta-format. It isn't a 'protocol'. Something encoded in
JSON is a format, not a protocol. Hence one of the tasks apparently
being chartered would be to create a new message access protocol,
encoded in JSON. While that might be worth doing, there needs to be
clarity that this is more than a 'representation'.
No, it is a representation. See above.
As soon as one says that the task is client/server interaction, one is
declaring the goal of a protocol. So it is more than just a format
(representation.)
>> There also needs to be clarity about the relationship between the JSON
>> encodings and the encodings in 'native' Internet Mail.
See drafts (and above).
Drafts? What drafts? Perhaps you mean:
https://tools.ietf.org/html/draft-jenkins-jmap
Except that no draft is cited in the charter.
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.
From my November comments:
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.
I am not sure what kind of justification is needed. This is a clear
deployment problem.
As I said, there was a year-long, serious and diligent debate about this
in the IETF and it came to a different conclusion. So it's not nearly
as 'clear' as you are asserting.
Adding to this:
The IETF email technical community looked at the question of making
email submission part of IMAP or keeping it separate. It took an
entire year to debate this point extensively and (imo) constructively,
and decided to keep them separate. The current charter draft appears
to have decided otherwise, but offers only the barest of
justifications, which I suspect has not factored in the earlier
evaluation.
There was a followup discussion about doing an IMAP extension for
submission and how it should look like to remain compatible with SMTP
Submission. I don't think this is an attempt to just ignore earlier
discussions.
Discussion is different than deployment. The fact that it isn't used
now suggests that the benefit(s) you are asserting aren't as clear-cut
as is being implied here. To the extent that the current proposal does
indeed represent a consideration of the prior, extended IETF work in
this realm, the charter should indicate the basis for making a different
choice here, in terms of the points considered earlier.
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, with
support for flood control and batched operations, and operating over
a stateless connection such as HTTPS.
'flood control'? what does this mean, since I assume the target
protocol won't be using a flooding algorithm. If it really means
'congestion control', that's not typically part of an application
protocol, so why would it be an issue here?
From the November comments
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.
Stateless lower level transport. The addition of "such as HTTPS" was
trying to make this clearer.
Didn't succeed, given that HTTP runs over TCP.
So this needs to be made much more clear, as to the what and the why,
as well as to the benefit that will accrue.
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.
Presence of tools for manipulating JSON and ease of development. This
was mentioned on the JMAP mailing list. I don't think this needs to be
said here.
A new protocol is choosing to operate over a very complex substrate.
Having some basic justification for that choice, in the charter, seems
somewhere between appropriate and obligatory.
Adding to this:
HTTP/HTTPS are not stateless, since they are connection-based.
Yeah, I struggled with this a bit. Each request/response can be sent on
a separate connection and it is stateless in that sense.
In other words, jmap will be stateless. That's what the charter should say.
...Except that that seems odd, since it means that every exchange would
have to self-identify and self-authorize.
I suspect that's not what's going to be defined. So, really, it isn't
obvious to me at all what will be stateless.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net