Re: [core] block1 size negotiation with 4.13 Request Entity Too Large

Carsten Bormann <cabo@tzi.org> Thu, 07 January 2021 23:06 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33013A0C93 for <core@ietfa.amsl.com>; Thu, 7 Jan 2021 15:06:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1jzaoie1IqP9 for <core@ietfa.amsl.com>; Thu, 7 Jan 2021 15:06:09 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81A23A0C84 for <core@ietf.org>; Thu, 7 Jan 2021 15:06:09 -0800 (PST)
Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DBhg20cQRzyWY; Fri, 8 Jan 2021 00:06:06 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <3558e7a7-4252-4fe5-ed6e-fbfaa7b72bf3@gmx.net>
Date: Fri, 08 Jan 2021 00:06:05 +0100
Cc: jon.shallow@jpshallow.com, "core@ietf.org" <core@ietf.org>, Simon Bernard <contact@simonbernard.eu>
X-Mao-Original-Outgoing-Id: 631753565.349872-99fd89cc99fb2f5095f6b3e85bb344f9
Content-Transfer-Encoding: quoted-printable
Message-Id: <A09B4917-53EE-49BE-BCA8-D114DE83163D@tzi.org>
References: <189d3f1e-9c83-b1c7-d8a1-7f195265bd2d@gmx.net> <e017c262-c88e-6d77-5f05-2ae2c1145aa8@gmx.net> <AA7B14A4-575F-465F-A106-3A6048877F79@tzi.org> <f114dcbf-ef6d-53d1-41e5-83db0835d408@gmx.net> <AE33D7A2-A503-4E90-AB66-9CC7C64FF211@tzi.org> <3560ba6c-9840-653a-bfb6-2685142c0988@gmx.net> <D324751F-D453-42D5-9310-753DF44619B4@tzi.org> <3558e7a7-4252-4fe5-ed6e-fbfaa7b72bf3@gmx.net>
To: Achim Kraus <achimkraus@gmx.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/N80lsFdu5TItXYoXxndBmpB58OY>
Subject: Re: [core] block1 size negotiation with 4.13 Request Entity Too Large
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 23:06:14 -0000

On 2021-01-07, at 22:42, Achim Kraus <achimkraus@gmx.net> wrote:
> 
> RFC 7959, 2.3. Block Options in Requests and Responses
> 
> Block 2 / Request
> "The NUM field in the Block2 Option gives the block number of
> the payload that is being requested to be returned in the
> response."
> 
> The interpretation may be, either
> - the requested "block number" is to be returned in the response, or
> - the payload of the request block is to be returned.

It’s already Friday in Germany, so here goes:

http://doi.org/10.1353/lan.2003.0189:

Temperley, David. (2003). Ambiguity Avoidance in English Relative Clauses. Language. 79. 464-484. 10.1353/lan.2003.0189

The mouse the cat the dog chased chased ran
(The mouse {that the cat {that the dog chased} chased} ran)

I’m so glad I’m not a linguist.

So maybe a more practical reference can be found at stackexchange.

https://english.stackexchange.com/questions/140932/ambiguity-in-use-of-relative-pronouns says:
"You can use a relative pronoun without ambiguity if you make sure it immediately follows its antecedent.”
Well, that’s just one, unreferenced opinion, but I think this is indeed what is meant here (i.e., the “payload” is the referent [reference target] of the “that”.)

https://english.stackexchange.com/questions/169939/more-confusion-with-relative-pronoun-ambiguity can be used to muddy the water by distinguishing integrated relative clauses from supplementary relative clauses.
Since the above is an integrated relative clause (i.e., no comma), the “closest antecedent” rule still applies.

I’m fully convinced that the author had all this in mind (but then I’m not sure 🤔; I wrote that text on 2012-01-13(**) at 00:06:05, which was exactly nine years minus five days ago, for draft-ietf-core-block-05, published a few minutes later), and that the RFC editor later pondered the potential ambiguity carefully and decided that there wasn’t one.

Grüße, Carsten

(**) Which was a Friday, 13th.
The commit comment clarifies everything, though: 
it was the single word “Uff.” (the German word for “phew”).