Re: [Cbor] 0x5fff/0x7fff (Re: 7049bis: Diagnostic notation gaps)

[Thiago Macieira <[e-mail]>]

On Wednesday, 16 September 2020 04:32:08 PDT Carsten Bormann wrote:
> Hi Thiago,
> 
> Let me try to recap the two proposals for 0x5fff/0x7fff:
> 
> * Add b/t.  The minimum change would be to only allow this for empty
> indefinite length strings (no chunks).  In which case there still would
> need to be some logic to only emit b/t when the indefinite length string
> closes right away.  If we don’t do the minimum change, we would have
> interop issues with all implementations that don’t know about this.

Indeed. The simplest for diagnostic dumpers would be to always allow "b" and 
"t" at that point, since the type has been decoded.

> * Use ‘’_/“”_.  This is indeed the minimum change, because it is no change
> from RFC 7049, just pointing out that this stands for 0x5fff and 0x7fff,
> respectively (well, there is a small change in that this is clarified to
> stand for no chunks, so you would need to say (_ ‘') etc if you have empty
> chunks, but that is already natural).  A generator of diagnostic notation
> would indeed need some look-ahead (one byte) to do this on the fly.  We
> don’t know how many consumers already decode ‘’_/“”_, so it is hard to say
> what interop issues we’d have, but the alternative (_ ) cannot be decoded
> unambiguously anyway.

Hmm... that's also a possibility, since this is currently an unused sequence.

$ printf '\x84\x58\0\x59\0\0\x5a\0\0\0\0\x5b\0\0\0\0\0\0\0\0' | ./cbordump -i
[
    h''_0,
    h''_1,
    h''_2,
    h''_3
]

Looking at my own code at https://github.com/qt/qtbase/blob/dev/examples/
corelib/serialization/cbordump/main.cpp#L294-L327, the complexity is about the 
same either way. There's already some state being kept across chunks work due 
to the comma. It wouldn't be too difficult to realise that the length wasn't 
known and nothing got printed.

> I have a preference for not adding mechanism where it is not needed (even
> though this requires some code in the implementation — but that is true for
> both cases).
> 
> Let’s discuss this some more today at the CBOR interim meeting.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering