Hi Bob,
Thank you for your review. A few quick comments below:
On 19/12/2019 16:41, Bob Briscoe via Datatracker wrote:
[snip]
===Shouldn't extensibility be discussed?===
The specification is full of statements saying what peer A MUST do, but
lacks statements saying what peer B MUST do if peer A doesn't do what it
is supposed to.
Perhaps there needs to be a default case for what to do if one peer
receives a message that violates the Websockets JMAP subprotocol (or at
least one peer believes it violates the version of the protocol that it
supports).
Examples:
4. JMAP Subprotocol
Binary data MUST NOT be uploaded or downloaded
through a WebSocket JMAP connection.
What if they are?
I think this case is not interesting, as it is effectively a separate
API endpoint in standard JMAP anyway. So there would be just no way of
doing this in JMAP over WebSocket.
4.1 Handshake
Other message types MUST
NOT be transmitted over this connection.
What if they are?
This is a more interesting case. So saying something here would be useful.
4.2 WebSocket Messages
The lists of allowed messages following "The messages MUST be in the
form of..." do not say what to do if they are not, and do not seem to
allow for extensibility.
And so is this.
[snip]
Best Regards,
Alexey
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
