Re: [Jmap] Benjamin Schwartz comments on draft-ietf-jmap-websocket-05

[Ben Schwartz <[e-mail]>]

On Sun, Mar 8, 2020 at 3:16 PM Ken Murchison <[e-mail]> wrote:

>
> On 2/21/20 7:45 AM, Alexey Melnikov wrote:
>
> Hi,
>
> **********************************************************************
> * Note, that I am conducting an experiment when people aspiring to be*
> * Area Directors get exposed to AD work ("AD shadowing experiment"). *
> * As a part of this experiment they get to review documents on IESG  *
> * telechats according to IESG Discuss criteria document and their    *
> * comments get relayed pretty much verbatim to relevant editors/WGs. *
> * As an AD I retain responsibility in defending their position when  *
> * I agree with it.                                                   *
> * Recipients of these reviews are encouraged to reply to me directly *
> * about perceived successes or failures of this experiment.          *
> **********************************************************************
>
> I also have some comments on Benjamin's comments below marked with "[[Alexey]]:"
>
>
> The following comments were provided by Benjamin Schwartz <[e-mail]> <[e-mail]>:
>
> Benjamin would have balloted *YES* on this document. He wrote:
>
> ## Section 3
>
>
> Consider removing “webSocket” from the parameter names.  It is redundant within this context.
>
>
> Done.
>
>
>
> ## Section 4
>
>
>    Binary data MUST NOT be uploaded or downloaded
>    through a WebSocket JMAP connection.
>
>
> Please provide a motivation for this restriction.
>
> [[Alexey: In standard JMAP these operations are performed on special HTTPS endpoints, so no JMAP objects are exchanged there. This document just does the same.]]
>
>
> To Alexey's point, the very next sentence states "Binary data is handled
> per Section 6 of [RFC8620]
> <https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi#RFC8620> via a
> separate HTTP connection or stream."
>
Yes, the text is perfectly clear as to what you're supposed to do, but it's
not at all clear as to why this restriction is necessary.  If the
restriction is "intrinsic" to the protocol then it's not a normative
requirement, because the forbidden action is inexpressible.  Otherwise, the
restriction must have been imposed for some reason, but the text doesn't
say why.

Uploading binary data through the WebSocket seems potentially useful (e.g.
to gain the benefits of compression, as mentioned elsewhere in the draft).
If there's a good reason to forbid it, I suggest mentioning that.
Otherwise, I would remove the requirement.

## Section 4.1
>
>
> I would suggest replacing this MUST with a simple reference to Section 8.2, which can contain its own normative language.
>
> [[Alexey: Ben, can you clarify why you suggest pointing to Section 8.2? Is this in another RFC?]]
>
>
> Same question as Alexey.  To which Section 8.2 are you referring?
>
RFC 8620.  This text is attempting to use "MUST" to regulate not the
software's behavior, but the implementor's state of mind.  In my view, this
is not good use of RFC 2119 language.  I recommend simply reminding the
reader to review Section 8.2 of RFC 8620, or perhaps explaining why those
recommendations are especially important in this context.

>
> ## Section 4.3.2
>
>
> Is “@type” now required on all Request/Response/Problem Details objects everywhere?  Does this update RFC 8620?
>
>
> Alexey, I'll let you decide is this document updates RFC 8620.
>
My point is that the text is unclear.  I presume that the line "This
specification adds two extra arguments to the Request object" doesn't apply
to all Request objects, but only to Request objects that are sent over a
WebSocket.  However, the text doesn't say that.  I would suggest noting
that this specification uses an extended object encoding from RFC 8620, so
that the distinction can be described explicitly.

>
> --
>
> Ken Murchison
> Cyrus Development Team
> Fastmail US LLC
>
>