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

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 20 December 2019 09:01 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9806A1200B7; Fri, 20 Dec 2019 01:01:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBlS5i2goBVK; Fri, 20 Dec 2019 01:01:43 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id CE2F61200A1; Fri, 20 Dec 2019 01:01:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1576832501; d=isode.com; s=june2016; i=@isode.com; bh=LPhNb8mI0pduCz/UhURCZZ+8KB4R3Ln48foso0in5d8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZuiXKAVprOcuOYw1HPHFnNff7UFQp87qhdLGZBhx8pHY2N/DdhJQEfGBNHA1MxA6E+CdHt Jof15Y+J+G1OH5oA9hkYOh5wARcfe4KQ5kW15Md296/SX1qLMoAlJPxpyCphC9yvFzaZq5 RgwJL41mO05DCl/ZU4wrGXqXMv+DFZM=;
Received: from [10.172.117.34] (92.40.249.160.threembb.co.uk [92.40.249.160]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <XfyN9AAXdEhN@waldorf.isode.com>; Fri, 20 Dec 2019 09:01:41 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: iPad Mail (16G102)
In-Reply-To: <31fd1e58-0537-2d7e-b69e-0739228e2776@bobbriscoe.net>
Date: Fri, 20 Dec 2019 09:01:39 +0000
Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-jmap-websocket.all@ietf.org, jmap@ietf.org
Message-Id: <78E4BB6D-13B8-4938-9709-A8887272B3EE@isode.com>
References: <157677367852.27417.14108254460834408683@ietfa.amsl.com> <33b1eb10-ff5c-192e-d7d8-56b200e8de96@isode.com> <31fd1e58-0537-2d7e-b69e-0739228e2776@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/x3kIqAYnP29tIeXBLuAAZITtKSQ>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-jmap-websocket-04
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2019 09:01:45 -0000

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/
>