Subject: [Jmap] Benjamin Kaduk's No Objection on draft-ietf-jmap-websocket-05: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 17 Feb 2020 16:23:57 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-jmap-websocket-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-websocket/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.