ietf
[Top] [All Lists]

Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap)

2017-02-08 07:40:19
Dave,


On 06/02/2017 20:11, Dave Crocker wrote:
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.

The protocol is HTTP version agnostic, for the most part.
The original thought was that it is less stateful than IMAP, which requires a mailbox to be opened for some operation. But the server still needs to maintain state (for example to track flag modifications). So saying "stateless" is incorrect, so I deleted it in 2 places in the Charter.

 [...]

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.
True.
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.

As you pointed out, saying stateless is not really correct.

Best Regards,
Alexey