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

[Dave Crocker <[e-mail]>]

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