JSON Mail Access Protocol
charter-ietf-jmap-03

[Ballot comment]
Barry basically captured what I was going to say, but I'll note explicitly that
some of the removed milestones are not currently marked as "Done" and correspond
to items for which "working group will deliver documents for the following";
that mismatch should probably be corrected.

[Ballot comment]
Actually, "Yes, but..."

The concrete deliverables at the bottom include JSCalendar but not JSContact; please add one for the latter.

That would make five concrete deliverables, of which only two (websockets and MDNs) have milestones listed.  It would be nice to have milestones for the others.

And there's a milestone for which there's no listed deliverable (the implementation guidance).  I'm ambivalent here: does it make sense to list it as a deliverable?  Or maybe it's better just to have it in the milestones, as there is a "catch-all" deliverable that will cover it.

[Ballot block]
I actually have a question about this how new transport part:
"New transports for transporting JMAP will have security properties
  comparable to HTTPS. In particular they have to require TLS."
Is the intention actually to have a "transport other https" or rather something on top of https? I really would like to see further explanation here what this is heading to!

[Ballot block]
If we're going to be talking about new transports (e.g., websockets, or the more
generic "different protocols than HTTPS"), we should say something about ensuring
that the appropriate security properties are retained in the new setup(s).

[Ballot comment]
If we're going to be talking about new transports (e.g., websockets, or the more
generic "different protocols than HTTPS"), we should say something about ensuring
that the appropriate security properties are retained in the new setup(s).

[Ballot comment]
If we're going to be talking about new transports (e.g., websockets, or the more
generic "different protocols than HTTPS", we should say something about ensuring
that the appropriate security properties are retained in the new setup(s).

[Ballot comment]
If the goal is to not diverge from existing formats, is it possible to clarify the relation between object models and data formats. For example are there really a need to define new data formats, as I assume there exists already for the established format? Should there be clearer scoping of why one may consider new data formats for existing object models?

[Ballot comment]
Need to do the following edits to the Charter:

1) Clarify whether there are any restrictions on message submission in JMAP and possible pointers to previous IETF discussions (as per Dave Crocker/John Klensin).

[Ballot comment]

I agree with Spencer and would suggest that if the ietf@ietf.org
discussion continues there'd not be much time lost if this was
put back for approval in a couple of weeks.

[Ballot comment]
I'm going to ballot No Objection now, but I know there are still discussions underway that may result in text improvements, and I'm assuming they'll converge before we announce approval.

[Ballot comment]
Need to do the following edits to the Charter:

1) Clarify constraints on what kind of changes (or lack therof) can be done to existing protocol proposal (as per Dave Crocker)
2) Clarify whether there are any restrictions on message submission in JMAP and possible pointers to previous IETF discussions (as per Dave Crocker/John Klensin).

[Ballot comment]
As doing this late, looking at the other comments. Prefer Alissa's rewording. On Spencer's, I don't think it's "mobile devices", I think mobile environment is ok as is.

[Ballot comment]
Given the description, which includes hints at the pain current solutions result in, I would think that the first deliverable (problem statement) is not needed.

If the WG needs to work on a problem statement then perhaps the problem is not full understood yet...

[Ballot comment]
Just a couple of nits for your consideration.

I find the use of "mobile" as a noun to be unnatural in this text:

"These protocols are proliferating due
to existing standards being insufficient or poorly suited to the
environments they are operating in, particularly mobile and webmail."

Perhaps "mobile devices and webmail"?

If this paragraph:

"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. A single protocol for receipt and
submission will resolve long-standing difficulties users face
setting up clients to talk to servers. 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."

was rearranged so that it describes a problem and, in a separate paragraph, says what the working group will do to resolve the problem, that would be easier for me to parse.

I'm thinking of something like this:

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

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. A single protocol for receipt and
submission will resolve long-standing difficulties users face
setting up clients to talk to servers."

[Ballot comment]
I don't think I saw response to the early list comments asking for elaboration on the "many companies and projects" implementing this. It might make more sense to replace the first sentence with something like "A number of JSON-based representations of email have been developed that are proprietary, non-standard, and incompatible with each other."