Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-etch-05: (with COMMENT)

"Alexey Melnikov" <aamelnikov@fastmail.fm> Thu, 05 September 2019 12:24 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 8F37C120059; Thu, 5 Sep 2019 05:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=VsXo6dVu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LVH9LzSE
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 3BOpDr61vYP2; Thu, 5 Sep 2019 05:24:29 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD3B120026; Thu, 5 Sep 2019 05:24:29 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 29F0822128; Thu, 5 Sep 2019 08:24:28 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 05 Sep 2019 08:24:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=VvRIbIe4yxyjp9BAEcAZtS41T9keUyj B4gBpAzEuUK8=; b=VsXo6dVuVf8l0L9N2kII/EZHxAsJ3Qox5kGOPux8FG4QHqZ 2fePcXrh3nxlRIY28ZDDB5i+bA/nLPB74voSD3oqj7DTaENV/fx6LkJS89UKkYAo 7PwqkPqJbZUUB6pfO3yOR4u5vd9JL6tnSKd2qkjOtkAgUCOdrDv1tewXjyT8yN/G bWO1uwoGkIjAzQiO/mAVbYgQATgLR+V10ab2klvi5kJnmDo0JBDc45jjtMgraZK6 4QgkDVETXA/+AvPsL26DlSArPx+mK3GdUhg1n1Q15ggfJKlCsqfkpvqL1uKZnBk6 SmPJdxOnn9whwYH7ke0Vhg6z8z0Ys17W8Jxl0Kg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=VvRIbI e4yxyjp9BAEcAZtS41T9keUyjB4gBpAzEuUK8=; b=LVH9LzSE8LZLBLVC4pqIv5 Ix519MXmoOpsjOxIxZ1938fQsC+THHV1q4TZT0idh8Rr9Ogo2GTUqS5VPONxK5Oc 9nLvoCxYMhD0qQJOE1NL6Y6fPz+KFRYzQEntuS2K6cqGO2V8R3KVbmrD0LmnNeno 4CuFKwIsYdApFnA3bDTq5Z0vBzrhdwU+GHd/mFLIzs37RweJusk701jZpsUiZDl1 nkv/oPjrgmAVuIkvLjaoEjYq7h3XKunTjh4yWsVT4whl9mmflnGmVSx5+raV8ubo 2yolQyqPwmw45TULD1Wu5mFEX5Cs/rBzL6J6N/viWaIodxnRORkWQ0cdnZVGT/Cw ==
X-ME-Sender: <xms:e_5wXbteGdGXnUU0JXIO3T9tK91vappOin-K9pLELMleSywjaYi8sQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudejjedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:e_5wXb57tGydbPrWCdtr2A-Jr9hnEXpA9NVZLMuWAv0V6eEEOwJRQQ> <xmx:e_5wXf1oWNuhbS2SeByznSw-IqHv8Zj2m4YZscxv3QzI7_D-Tkp1Wg> <xmx:e_5wXeh03jWpXwBbfLE8bPop65iTh4mogbqP3mQfbH-pFA2cnvnQ8A> <xmx:fP5wXZ431CIu20E-bNExbqkZvC1mAg1P1y4yZmIE5yqIyYa_IcY_5Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9681CC200A4; Thu, 5 Sep 2019 08:24:27 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-188-g385deb1-fmstable-20190905v2
Mime-Version: 1.0
Message-Id: <01c45ddf-a237-46ad-8537-96e191269b1c@www.fastmail.com>
In-Reply-To: <156765535451.22851.10780950548432822644.idtracker@ietfa.amsl.com>
References: <156765535451.22851.10780950548432822644.idtracker@ietfa.amsl.com>
Date: Thu, 05 Sep 2019 13:23:45 +0100
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Cc: draft-ietf-core-senml-etch@ietf.org, core-chairs@ietf.org, Carsten Bormann <cabo@tzi.org>, core@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/HqG90iDCVimZOM-cLHbQrBNGXUE>
Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-etch-05: (with COMMENT)
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, 05 Sep 2019 12:24:30 -0000

Hi Ben,
Just commenting on one thing:

On Thu, Sep 5, 2019, at 4:49 AM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-core-senml-etch-05: No Objection

> Section 4
> 
> As for several other reviewers  I'm not entirely sure that I understand 
> the fragment case for
> fetch/patch records.  These records (the request body) are themselves
> selectors, so a client that wanted to consider just a subset of the
> records could just send the (appropriately resolved for base values)
> subset of the records in the request to obtain the selected set of
> records from the resource instead of requesting the "full" set (from the
> request body) and then selecting from the response via the fragment.
> So, are we just specifying the fragment semantics out of a sense of
> completeness, or are there expected to be cases where we still want to
> retrieve records from the server just to "throw them away" at the client
> side?

Describing handling of URI fragments is a generic requirement for media type registrations. So this is mostly done for completeness.

>  It is perhaps plausible to imagine doing so with (i)Patch, in
> order to effect a set of changes but only retain the results for a
> subset of them, but I'm having a harder time coming up with a case for
> fetch fragments.  The best I can do so far is some (as-yet-to-me)
> hypothetical case where the selector is easier to write with multiple
> fetch records (e.g., for getting base values) but not all of them are
> relevant for the desired computation.