[Cbor] "Ignore unknown" -- Re: [core] WG Last Call on draft-ietf-core-problem-details

Carsten Bormann <cabo@tzi.org> Wed, 25 May 2022 10:32 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778AEC15E6E5; Wed, 25 May 2022 03:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKKD_C2SdjuX; Wed, 25 May 2022 03:32:45 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3CBC15E6E1; Wed, 25 May 2022 03:32:45 -0700 (PDT)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4L7S7b200HzDChm; Wed, 25 May 2022 12:32:43 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <YoesjAXIKQS+PBLX@hephaistos.amsuess.com>
Date: Wed, 25 May 2022 12:32:42 +0200
Cc: draft-ietf-core-problem-details@ietf.org, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, cbor@ietf.org, httpapi@ietf.org
X-Mao-Original-Outgoing-Id: 675167562.853454-3014c04fc9fba0ca4604964d43fc46a1
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E2E2AF8-4B53-45F2-9195-F0F495F0243B@tzi.org>
References: <3a2fb1c8-5c50-fa7a-0672-a73c3b6f1a5f@ri.se> <YoesjAXIKQS+PBLX@hephaistos.amsuess.com>
To: Christian Amsüss <christian@amsuess.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/AzNLTxTaaH00j9EjNeBieLeEZp4>
Subject: [Cbor] "Ignore unknown" -- Re: [core] WG Last Call on draft-ietf-core-problem-details
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2022 10:32:48 -0000

> * "MUST ignore": From recent chats I understand that it does not only
>  refers to keys (standard, outer and inner custom) the receiver does
>  not recognize, but also to values outside the expected set.
> 
>  If that is the case, it would be good to have a few words of rationale
>  and guidance, as "on error goto next" patterns are often discouraged
>  -- I think they're good here, but other readers might need convincing.

This is much more widely open (and, thus, subject to interpretation) than simply ignoring unknown map keys.
How strict does the implementation need about checking the values so it can ignore an unexpected value?  Can the originator rely on this check having been properly made?
Big can of worms.
Not sure this spec is the place to develop the general solution.
(In practice, ignore unknown works reasonably well, so I don’t see the pain that would justify such a fundamental effort.)

Grüße, Carsten