A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana No Objection

Comment (2020-01-08 for -04)
No email
send info
I also support Alissa's DISCUSS.

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-02-17 for -05)
Thanks for addressing my discuss points (and comments!) on the -04!
I do want to have a bit more discussion in light of the late-breaking
secdir review, though.  Specifically, RFC 6455's security considerations
have significant discussion of the web's "Origin" concept and how it
applies both in the case of trusted browsers running untrusted
javascript, and potentially untrusted native applications.  I did not
see any follow-up discussion in response to the secdir reviewer's
comments, and wonder if we need to say anything about the relationship
between the Origin of the JMAP API endpoint and the websocket endpoint.

I'd also like to have a bit of discussion about the risks of
compression, which I mentioned in my comments on the -04 but don't
remember seeing any follow-up on.

Section 4.3.1

What's the difference between an unsupported JMAP vs. unsupported JSON
object?  E.g., what would make something "well-formed JMAP" but still

Section 5

It's best to refer to RFC 7525 as BCP 195, to incorporate any future

Martin Vigoureux No Objection

Comment (2020-01-08 for -04)

I only have one nit, as a comment:

The references to Sections 3.2, 3.3, and 3.5.1 of RFC8620, in Section 4 of this document, seem wrong.
I believe they should, be 3.3, 3.4, 3.6.1, respectively.

Roman Danyliw No Objection

Comment (2020-02-15 for -05)
No email
send info
Thank you for addressing my COMMENT.

Éric Vyncke No Objection

(Alexey Melnikov; former steering group member) Yes

Yes ( for -04)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection (2020-01-08 for -04)
Thank for the work that went into creating this document. I agree with various
other IESG members about the need to make WSS mandatory.

(Alissa Cooper; former steering group member) (was Discuss) No Objection

No Objection (2020-02-07 for -05)
Thanks for addressing my DISCUSS.

(Barry Leiba; former steering group member) No Objection

No Objection (2020-02-19 for -05)
I agree with the DISCUSS positions that suggest explicit text to require encryption.

I think that RFC 7692 needs to be a normative reference.  The IESG statement about references ( https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ ) says this:

     Note 1: Even references that are relevant only for optional features must
     be classified as normative if they meet the above conditions for normative

 + + + + + + + + + + + + + + + + + + + +

The following are comments from Murray Kucherawy, incoming ART AD.  Murray is getting an early start on doing reviews, and I’m including his comments into my ballots during the overlap period before he’s officially an Area Director.

 - - - - - - - - - - - - - - - - - - - -

Section 4.1, I don't know what interoperability assertion is being made by saying I "MUST" consider something.  I think the reference to the other document is appropriate, however.

Section 4.2's use of MUSTard also has me flinching, and can hear Pete Resnick's voice asking me why there's "MUST close" instead of simply "closes", etc.

Section 4.3.1's SHOULDs have me wondering under what conditions an implementation would deviate legitimately from that advice.

The "@type" line in Section looks like it's run together with its description line.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2020-01-06 for -04)
The TSV-ART review (Thanks Bob!) flagged an issue about further discussing failure cases. Alexey indicated that the spec should add more text about this, however, no update has been posted since. I assume this will be addressed before publication, as Alexey is aware, so I'm balloting no objection.

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -04)
No email
send info