Re: [core] Request-Tag and Block ID

Christian Amsüss <christian@amsuess.com> Thu, 11 June 2020 11:45 UTC

Return-Path: <christian@amsuess.com>
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 20E4E3A03FF; Thu, 11 Jun 2020 04:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 G0iZO8L8f3ZB; Thu, 11 Jun 2020 04:45:53 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D323A03F3; Thu, 11 Jun 2020 04:45:53 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D622440015; Thu, 11 Jun 2020 13:45:48 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1DB71151; Thu, 11 Jun 2020 13:45:48 +0200 (CEST)
Received: from hephaistos.amsuess.com (arcss01.ait.ac.at [62.218.164.126]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B0C0764; Thu, 11 Jun 2020 13:45:47 +0200 (CEST)
Received: (nullmailer pid 2138136 invoked by uid 1000); Thu, 11 Jun 2020 11:45:47 -0000
Date: Thu, 11 Jun 2020 13:45:47 +0200
From: Christian Amsüss <christian@amsuess.com>
To: mohamed.boucadair@orange.com
Cc: "draft-bosh-core-new-block@ietf.org" <draft-bosh-core-new-block@ietf.org>, "core@ietf.org" <core@ietf.org>
Message-ID: <20200611114547.GB2006829@hephaistos.amsuess.com>
References: <12651_1591874430_5EE2137E_12651_274_1_787AE7BB302AE849A7480A190F8B9330314DC5FC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k"
Content-Disposition: inline
In-Reply-To: <12651_1591874430_5EE2137E_12651_274_1_787AE7BB302AE849A7480A190F8B9330314DC5FC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/5hYwtqTVnzOKtZFbfQkqx-dDUCM>
Subject: Re: [core] Request-Tag and Block ID
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, 11 Jun 2020 11:45:56 -0000

Hello Med,

On Thu, Jun 11, 2020 at 11:20:30AM +0000, mohamed.boucadair@orange.com wrote:
> I would relax those statements. For example, can you please consider updating statements such as this one:
> 
>    "The Request-Tag option is only used in requests that
> 
>                               ^^^^
>    carry the Block1 option, and in Block2 requests following these."
> 
> to cover block options as those defined in draft-bosh-core-new-block.

While the original understanding of Request-Tag was that it'd only be
necessary where Block1 (or Block3) mode is involved, yesterday's
examples show a use case outside as well.

The above is not normative text -- you'll note that there is barely any
at all, for all the option's mechanism already follows from being
NoCacheKey. There is normative text for that very case, though it might
be problematic ("MAY be present in request messages that carry no Block
option[...], and MUST be ignored in those.")

I think it would be topically suitable to relax things a bit here to
ensure applicability with a future Blockwise mechanism.

Procedurally, as this is post WGLC (but waiting for an updated version
for the writeup), I think I can pull those in (together with other
comments received during and after the WGLC), but will need to accompany
those changes with an explicit mail to the WG informing everyone of
those with detail and rationale.

> You may also update the terminology section to define block-wise in a
> more generic manner.

As an immediate reaction I'm tempted to call those users of Request-Tag
"block-wise transfer or other applications that associate requests by
their cache key where such an association is broken deliberately by the
client". I'll see whether that fits with the rest of the text, but don't
think there's trouble if it does not: For with Request-Tag preceding
Block34, the latter can just state that in interaction with Request-Tag,
Block34 are treated like Block12.

Kind regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom