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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 19 Feb 2020 14:18:09 -0800

Barry Leiba 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:
----------------------------------------------------------------------

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.