Re: [Cbor] [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]

[Carsten Bormann <[e-mail]>]

On 2020-05-08, at 11:37, Kio Smallwood <[e-mail]> wrote:
> 
> - the next offset (must be strictly larger than the offset + length of previous data item)
> 
> - the next byte(s)
> 
> - etc.
> 
> e.g.
> 
> 2020([0, h'0107', 500000000, h'15'])
> 
> The following example should result in an error:
> 
> 2020([0, h'0107', 1, h'01'])
> 
> A case should be made that each offset+byte pair should have at least one set bit. So this would be a valid bitfield that's all zeros:
> 
> 2020([])

Looks good.  Even better: make sure that an overlap cannot even be encoded.
The numbers in the array could be the number of bytes not sent that are presumed all zero.

So your first example would become:

2020([0, h'0107', 499999998, h'15’])

Or, actually, since the first zero becomes redundant now, 

2020([h'0107', 499999998, h'15’])

So the contents of the array would be byte strings or numbers that indicate gaps by giving the number of zero bytes.

Numbers should probably be positive (non-zero), and we could forbid adjacent numbers or trailing numbers.  Or we could just make that the preferred encoding and still allow them (including zeros); I don’t have a strong opinion.  (I’m not motivated enough to think about c14n now…)

[ASN.1 has the ability to indicate that the last byte in a bit string isn’t completely part of the bit string.  A trailing negative number could indicate that.  But I still haven’t seen a true use case for ASN.1 bit strings since I thought about that in 2013…]

Grüße, Carsten