Alexey,
Pls check the draft for more occurrences than the three I found.
I think your word uninteresting meant "not possible for current
implementations to do this".
You might have misunderstood my point that defining what to do on
receipt of an unexpected (i.e uninteresting in your words) message is a
useful exercise to allow for extensibility. If you don't say whether to
ignore or to abort the connection (or whatever), it becomes impossible
to predict what pre-existing implementations will do if you want to
extend the protocol in future.
Bob
On 19/12/2019 17:17, Alexey Melnikov wrote:
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
_______________________________________________
Tsv-art mailing list
Tsv-art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tsv-art
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
