> [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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
