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

[Alexey Melnikov <[e-mail]>]

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