A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket
draft-ietf-jmap-websocket-07

Thank you for addressing my COMMENT.

Thank for the work that went into creating this document. I agree with various
other IESG members about the need to make WSS mandatory.

Thanks for addressing my DISCUSS.

I also support Alissa's DISCUSS.

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

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

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 4.3.5.2 looks like it's run together with its description line.

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
unsupported?

Section 5

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

Hello,

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.

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.