Re: [Jmap] [Tsv-art] Tsvart last call review of draft-ietf-jmap-websocket-04

Hi Bob,

> On 20 Dec 2019, at 01:48, Bob Briscoe <ietf@bobbriscoe.net> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/tsv-art
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 