Re: [Cbor] Invalid tag (issue 176); notable tags draft

[Thiago Macieira <[e-mail]>]

On terça-feira, 12 de maio de 2020 22:13:38 PDT Carsten Bormann wrote:
> This was discussed at the same time we also discussed that 64-bit (i.e., >
> 32 bit) tags are likely only going to be processed by implementations that
> do 64-bit numbers as well, and it was pointed out that some implementations
> will even attempt to get by with 16 bits for the tags they need.  But we
> could go ahead and reserve ~0 as another invalid tag as that strategy
> (storing tag number+1) is only visible inside an implementation, so it
> doesn’t matter whether that tag is processed during interchange.

Indeed. TinyCBOR's own structure for validating tags could be shrunk to 16-bit 
and save just under half of the memory use. Right now, I'm using some extra 
bits to indicate that tags 21, 22 and 23 apply to arrays, maps and byte 
strings so I need more than 16 bits anyway, but there are other ways of 
indicating the same thing.

> https://www.ietf.org/id/draft-bormann-cbor-notable-tags-00.html#name-invalid
> -tag Is that text sufficient?

It's sufficient, based on the discussion here. But if I hadn't participated, 
I'd read the "are encouraged to" as something I should implement, not just 
something I can ignore.

> > If this discussion is of interest, I'll start a new thread to talk about
> > Undefined.
> 
> Yes, please.  Even better if you could include tag 31
> https://github.com/svaarala/cbor-specs/blob/master/cbor-absent-tag.rst in
> that discussion.

Will do.

> > If it is present, the decoder
> > will see a QCborTag(0xffff) and I will add a QCborKnownTags::Invalid to Qt
> > and CborInvalidTag to TinyCBOR (if it fits into 32-bit).
> 
> Maybe we should go for Invalid1 (0xffff) and Invalid2 (0xffffffffffffffff)
> then…

Then reserve 0xffff, 0xffffffff and 0xffffffffffffffff.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products