Re: [Cbor] [COSE] CBOR magic number, file format and tags

[[e-mail]]

Carsten Bormann <[e-mail]> writes:

>> On 2021-01-23, at 04:14, Dale R. Worley <[e-mail]> wrote:
>> 
>> Here's an alternative.  It is aligned with the magic number tag of CBOR
>> itself (55799) and the CBOR way of doing things.  Specifically, reserve
>> a large range of tags (such as 55800 to 65000, or 100000 to 109999) for
>> use as magic numbers; the CBOR object has the appropriate magic number
>> tag applied to that, and optionally, the CBOR magic number tag 55799
>> applied to that.  That can leave the generic CBOR magic number visible
>> at the start of the file, immediately followed by the bytes of the
>> specific magic number for the object type.
>
> Right.  Something like this would probably make sense as an
> alternative to the primary approach proposed, which is based on CBOR
> sequences.  If you want to keep the magic-numbered file a single data
> item, this is the way to go.
>
> Two issues:
>
> - This should probably be a 1+4-byte tag.  The range you mention leads
> to a zero byte in the magic number.  Not sure if that is a bug or a
> feature.  (It is also way too small.)

I'm sure that zero bytes in magic numbers are OK, as "file" allows the
byte values it tests against to be specified in hex.  And in general,
"file" processes lots of binary formats.  Of course the range(s) you
allocate for magic number tags depend on the number of different magic
numbers you anticipate.  Naively I expect 10,000 to be sufficient.
OTOOH, you can always define an additional range if you run out.

> - As I mentioned before, we don't have a good way to assign a purpose
> to a range and then let IANA do the allocation within the range.

I'm not so sure that's important.  As the CBOR Tags registry
demonstrates, you can specify to IANA how registration is to be done in
different tag number ranges; presumably the parties allowed to make the
registration in those ranges can be trusted to enforce the desired
semantics, otherwise other rules would have been specified.

The deficiency of a tag-only approach is that it doesn't allow
"paramaterized" types.  A lot of "file" entries not only discern the
overall type of the file, but various additional facts about it.  E.g.,
picking at random:

     # Digital Symphony data files
     # From: Bernard Jungen ([e-mail])
     0		string	\x02\x01\x13\x13\x13\x01\x0d\x10	Digital Symphony sound sample (RISC OS),
     >8		byte	x	version %d,
     >9		pstring	x	named "%s",
     >(9.b+19)	byte	=0	8-bit logarithmic
     >(9.b+19)	byte	=1	LZW-compressed linear
     >(9.b+19)	byte	=2	8-bit linear signed
     >(9.b+19)	byte	=3	16-bit linear signed
     >(9.b+19)	byte	=4	SigmaDelta-compressed linear
     >(9.b+19)	byte	=5	SigmaDelta-compressed logarithmic
     >(9.b+19)	byte	>5	unknown format

determines that the file is "Digital Symphone sound same" but also its
"version", its "named", and an encoding type.

Simply prefixing a "Digital Symphony CBOR object" with a tag specifying
such provides no place to hold such data.  Having the magic number
information contain a sequence makes it easy to store annotations like
that.  OTOH, presumably interesting prameters in a "Digital Symphony
CBOR object" would be stored at fixed indexes within the base object
itself.

Dale