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

[Ken Murchison <[e-mail]>]

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]>:
>
> 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