[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
- [Cbor] [core] WG Last Call on draft-ietf-core-pro… Marco Tiloca
- Re: [Cbor] [httpapi] [core] WG Last Call on draft… Roberto Polli
- Re: [Cbor] [httpapi] [core] WG Last Call on draft… Carsten Bormann
- Re: [Cbor] [httpapi] [core] WG Last Call on draft… Roberto Polli
- Re: [Cbor] [core] WG Last Call on draft-ietf-core… Marco Tiloca
- Re: [Cbor] [core] WG Last Call on draft-ietf-core… Thomas Fossati
- Re: [Cbor] [core] WG Last Call on draft-ietf-core… Carsten Bormann
- Re: [Cbor] [core] WG Last Call on draft-ietf-core… Christian Amsüss
- Re: [Cbor] [core] WG Last Call on draft-ietf-core… Thomas Fossati
- Re: [Cbor] [core] WG Last Call on draft-ietf-core… Christian Amsüss
- Re: [Cbor] [core] WG Last Call on draft-ietf-core… Marco Tiloca
- Re: [Cbor] [core] WG Last Call on draft-ietf-core… Thomas Fossati
- [Cbor] "Ignore unknown" -- Re: [core] WG Last Cal… Carsten Bormann
- [Cbor] Base-URI Re: [core] WG Last Call on draft-… Carsten Bormann
- Re: [Cbor] [core] WG Last Call on draft-ietf-core… Carsten Bormann
- Re: [Cbor] Base-URI Re: [core] WG Last Call on dr… Christian Amsüss