Re: [Cbor] Why 0x42_4F_52 (was Re: 🔔 WG adoption call on draft-richardson-cbor-file-magic)

[Laurence Lundblade <[e-mail]>]

OK. Understand 0x42_4F_52 now. Thx.

Here’s the tagging of some common EAT usage on the wire:

{…claims…}  An untagged UCCS (an unsigned CWT/EAT)
601({…claims…})A tagged UCCS (an unsigned CWT/EAT)
61(18([…COSE-signed with claims payload…])) A CWT that is an EAT that uses COSE signing and is fully tagged
[…COSE-signed with claims payload…] A CWT that is an EAT that uses COSE signing and is fully untagged

601 is the UCCS tag, 61 is the CWT tag, 18 is the COSE_Sign1 tag. There is (so far) no tag indicating something is an EAT rather than a CWT. How do these tags related to the tag in the magic number?  I’m not sure yet.

The tag in the magic number seems more about dispatch to a file handler the way file extensions are used. 61, 601 and 18 are more about protocol characteristics, so maybe there is no relation at all. Maybe we define a new tag that indicates the file is an EAT and that is never sent over the wire? 

Or should the magic number tag be 601 or 61?

LL


> On Feb 18, 2021, at 10:14 AM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Laurence Lundblade <[e-mail]> wrote:
>> Can you say why part 3, 0x42_4F_52, is added? The only reason I can
>> think of is that 55799 is not unique enough.
> 
> Because the two tags have to actually tag something.
> 0x42_4F_52 is "BOR", and encoded as a byte string, puts "CBOR" into the file.
> This is the CBOR Sequence version.
> 
>> If we need it, can it be at the start so that the part 2 tag can be
>> part 3 so you can just hand the end part to protocol decoders for COSE,
>> CWT, CoSWID and so on? With the 0x42_4F_52 in there, you can’t do that.
> 
> In the discussion running up to this document, the question as to whether it
> should be a tag preceeding, or a CBOR Sequence occurred.  I concluded on a
> CBOR Sequence, but last week during the discussion, it seems that both have
> been asked for, and so I guess the document will do that once adopted.
> 
> 55799 will need to be replaced in the CBOR Sequence version with a different
> code which is equally unique and not valid unicode.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
>