Re: [Iot-directorate] [Last-Call] EAT profiles (was Re: Iotdir last call review of draft-ietf-rats-eat-13)

Carsten Bormann <cabo@tzi.org> Wed, 08 June 2022 00:32 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: iot-directorate@ietfa.amsl.com
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552A8C14F74B; Tue, 7 Jun 2022 17:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 BWwQ-xDsGOva; Tue, 7 Jun 2022 17:32:34 -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 9F6D7C14F744; Tue, 7 Jun 2022 17:32:29 -0700 (PDT)
Received: from smtpclient.apple (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 4LHp8V0T6TzDCbY; Wed, 8 Jun 2022 02:32:26 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <E267AEDE-D1DB-415B-B28F-DD78A517D27A@island-resort.com>
Date: Wed, 08 Jun 2022 02:32:25 +0200
Cc: Eliot Lear <lear@cisco.com>, iot-directorate@ietf.org, draft-ietf-rats-eat.all@ietf.org, last-call@ietf.org, rats@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A38F37B7-2E81-451F-86BA-0A041760EB7E@tzi.org>
References: <165443386776.35361.12898474920348394274@ietfa.amsl.com> <E267AEDE-D1DB-415B-B28F-DD78A517D27A@island-resort.com>
To: Laurence Lundblade <lgl@island-resort.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/RJSzHbyCS8MGsf5w857tGL0sHMw>
Subject: Re: [Iot-directorate] [Last-Call] EAT profiles (was Re: Iotdir last call review of draft-ietf-rats-eat-13)
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2022 00:32:36 -0000

On 8. Jun 2022, at 01:26, Laurence Lundblade <lgl@island-resort.com> wrote:
> 
> CBOR — RFC 8949 clearly allows for both indefinite and definite encoding.

Indeed (after s/encoding/length encoding/).

> If one implementation chooses one and another the other, there will not be interoperability.

FTFY:
If one implementation inexplicably chooses only to accept one of them, there will not be interoperability with generators that generate the other.

Don’t do that, unless there is a very specific reason not to.
(One specific reason may be where you need deterministic encoding — there a decision has been made to only allow definite length encoding.)

Generic implementations accept both length encodings.
I can’t imagine an implementation that can handle the complexity of EAT but not the complexity of both length encodings.

This subject is normally not visible to CBOR users because CBOR implementations simply implement both.

Grüße, Carsten