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

Bob Briscoe <> Fri, 20 December 2019 01:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 055E1120013; Thu, 19 Dec 2019 17:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fEayNPHqaW9h; Thu, 19 Dec 2019 17:48:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36C4712000F; Thu, 19 Dec 2019 17:48:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d5BdR4BdcTAgRmD2oVBEEDna9u5KVx5e5hIMCEuGgyM=; b=nPXagoPl52PNfyTv+CTcPS5VL5 G4enbIYQ7MJY1snJN+rhsQo4H6/tQT/jlN20N8DBvvA+zID/ppc1+jAnBvzJ4qtFQbRsG7ae3gtLv RfXlI5cwvDSu6w3FL6YbazaipveY4NOrRRFTW0D+P0JB19v74QWSh6buPmHIS1z8caBtlIs7CYhlf rCtBRdXSsmSGxJ8hrE9Rs8+0bwPTZSZWYHwPWdWS7jtc4tXw0BDL7cxa3r6CoXuGbWXF0VeLAq07w +7F5TcK8gI9+sOsnXcl9KzXqzegU1URtmXwZ1UFjFfhNDPtFno2u+U1eajzxW6Aae5P1eKiOe6DJF dB99L1/Q==;
Received: from [] (port=34288 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1ii7P8-0006rO-Q9; Fri, 20 Dec 2019 01:48:35 +0000
To: Alexey Melnikov <>,
References: <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Fri, 20 Dec 2019 01:48:32 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-jmap-websocket-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Dec 2019 01:48:40 -0000


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.


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

Bob Briscoe