Hi Bob, > On 20 Dec 2019, at 01:48, Bob Briscoe <ietf@xxxxxxxxxxxxxx> wrote: > > Alexey, > > Pls check the draft for more occurrences than the three I found. Right. > I think your word uninteresting meant "not possible for current implementations to do this". Yes. I think your general point is valid, I just wanted to point out that one of the cases you mentioned doesn’t need further considerations. > > 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. No, I agree with you here. > > 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
