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

From: Ken Murchison <[email-masked]>
Date: Sun, 8 Mar 2020 15:16:56 -0400

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 <[email-masked]>:
>
> 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."

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

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

-- 

Ken Murchison
Cyrus Development Team
Fastmail US LLC

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 9 Mar 2020 16:02:52 -0400

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

> The following comments were provided by Benjamin Schwartz <[email-masked]> <[email-masked]>:
>
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
> 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.

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

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 18 Mar 2020 17:23:27 +0000

Hi Ken,

> 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.
I think clarifying whether this is a generic extension or WebSocket specific, would be useful.

Best Regards,
Alexey

---

From: Ken Murchison <[email-masked]>
Date: Wed, 18 Mar 2020 14:03:51 -0400

On 3/18/20 1:23 PM, Alexey Melnikov wrote:
>> On Sun, Mar 8, 2020 at 3:16 PM Ken Murchison <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> 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.

draft -06 has language like the following for each object type:

The specification extends the Request object with two additional
    arguments when used over a WebSocket:

Is that sufficient or do you have some alternative text that you'd like 
to suggest?

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 18 Mar 2020 18:18:36 +0000

Hi Ken,

   arguments when used over a WebSocket:
This is sufficient. Thank you for checking.

Best Regards,
Alexey