> On 2021-06-14, at 13:46, Ivaylo Petrov <ivaylo@xxxxxxx> wrote: > >> I think documenting the true/false value of the primitives here (noted in the >> CBOR encoding) would aid in clarity. For example, "primitive(20) [false]". > > [IP]: I am not against that, I am only concerned if that would be > readable for others that are used to the diagnostic notation, > otherwise I am fine to apply this change. Let me pick this one because it is all my fault. The “CBOR encoding” snippets are generated by the CBOR diagnostic tool (which is also available at cbor.me on the Web.) The comments it generates in its “pretty hex” output are rather generic comments about the encoding; they are not trying to reflect the exact meaning of the content. This usually comes up with negative numbers (where the argument numbers shown are not bit-wise inverted to generate the negative number), but more detail could also be added for false/null/true/undefined. Instead of manually tweaking dozens of generated examples, I think it would be a good idea to agree about the best way to update the tool. Until that is done and implemented, I would feel uncomfortable with all this tweaking, because it will be error-prone and inconsistent. Grüße, Carsten -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
