On 8. Jun 2022, at 01:26, Laurence Lundblade <lgl@xxxxxxxxxxxxxxxxx> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
