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

Carsten Bormann <cabo@tzi.org> Fri, 10 June 2022 08:36 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 6AC5DC157B4B; Fri, 10 Jun 2022 01:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 iCREwz3YNLmi; Fri, 10 Jun 2022 01:36:35 -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 9A613C157B43; Fri, 10 Jun 2022 01:36:32 -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 4LKDp52HNhzDCbP; Fri, 10 Jun 2022 10:36:29 +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: <PH0PR02MB7256F46500F5AA6D859489F8F2A69@PH0PR02MB7256.namprd02.prod.outlook.com>
Date: Fri, 10 Jun 2022 10:36:28 +0200
Cc: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>, Laurence Lundblade <lgl@island-resort.com>, Eliot Lear <lear@cisco.com>, "iot-directorate@ietf.org" <iot-directorate@ietf.org>, "draft-ietf-rats-eat.all@ietf.org" <draft-ietf-rats-eat.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, rats <rats@ietf.org>, "cbor@ietf.org" <cbor@ietf.org>
X-Mao-Original-Outgoing-Id: 676542988.853075-483c77f53b44136d570055bcaeca8edc
Content-Transfer-Encoding: quoted-printable
Message-Id: <406D73B5-6779-49D0-AA5E-E0182DBD1BBA@tzi.org>
References: <165443386776.35361.12898474920348394274@ietfa.amsl.com> <E267AEDE-D1DB-415B-B28F-DD78A517D27A@island-resort.com> <A38F37B7-2E81-451F-86BA-0A041760EB7E@tzi.org> <9E4661C8-DFB7-4BC3-A7B5-150C774917F0@island-resort.com> <8C044EB7-92CF-4306-9025-FD667E1B0F22@tzi.org> <B7C27559-92B6-4426-821B-431A08341C72@island-resort.com> <6CDA1CA0-A59A-4ED7-903F-0B6829F08075@tzi.org> <AC2E17A1-52E7-455F-8959-091D58AA291F@island-resort.com> <9a938d66-55b9-c4e4-a5cf-0d655a90fcbd@it.aoyama.ac.jp> <PH0PR02MB7256F46500F5AA6D859489F8F2A69@PH0PR02MB7256.namprd02.prod.outlook.com>
To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/W1spOQ_rQCNWp06clsn0URHZ4mA>
Subject: Re: [Iot-directorate] [Last-Call] Segmented strings (Re: [Rats] 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: Fri, 10 Jun 2022 08:36:37 -0000

 
> [JOD] As far as I can tell from the specification, for a “fully conforming” CBOR implementation:
>  
> 	• Indefinite length maps and arrays consisting of up to 2^64 entries must be supported (and note that, as far as I can tell, there is nothing preventing every entry in an array from being a definitely encoded string of length 2^64)
> 	• There appears to be no limit at all to the length of indefinite encoded strings.

There is indeed no limit to segmented strings (that’s what makes them “streaming”).

I think that most implementations that conform to something also need to conform to the laws of nature, so for me having a non-arbitrary limitation on space and/or time is part of every kind of conformance, which does not need to be explicitly stated.
>  
> There may exist hardware platforms wishing to support EAT which cannot fully support those requirements.

Let me expand this with the reason why (and qualify “cannot” in the process).

One significant advantage of CBOR over many other formats, including ones that are binary-enabled in some form, is that (definite length) strings (both text and bytes) are encoded in an unadulterated form, i.e., strategies that use that string right out of the encoding (via pointer/length APIs) work and can get rid of allocation and copying.

This advantage is reduced with indefinite length: you need a segmenting (“scatter/gather” or “streaming”) API; often the subsystems CBOR data are interacting with have pointer/length APIs only.

The advantage only really accrues if the input to the decoder is unsegmented as well.  Practically, this means the whole data item fits into a packet.

> Statements along the lines of “an entity capable of receiving <thing> MUST support a payload of at least <number> bytes” are commonplace. Perhaps profiles are the right place for additional restrictions, but it seems reasonable to at least discuss implementation considerations in the main text.

We had those arbitrary limitations in SGML, and we were really happy to lose them in XML.
 
> Since the CBOR specification also says “some applications and protocols will not want to use indefinite-length encoding”, I’d like to understand if there even exists a reasonable case for an EAT which requires indefinite length encoding.

Embedding a video in an EAT?

> If there is not, I would be minded to explicitly exclude indefinite length items from EAT. This would address the “one person legitimately implements EATs with segmented strings” problem. I accept that this potentially deviates from “EAT is a CWT” as CWT doesn’t exclude indefinite length encoding.

Subsetting the encoding does not hurt “every EAT is a CWT”.  (It would hurt “every CWT is an EAT”, but I don’t think that we want that.)

Grüße, Carsten