There are a lot of ways to go here - for instance it could be a tag indicating a two element array, the first being an integer or a mime type
-DW > On Jan 20, 2021, at 4:56 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > Hi, I was thinking about this yesterday too, and after the discussion this > morning at COSE, I wrote: > > https://datatracker.ietf.org/doc/draft-richardson-cbor-file-magic/ > > which is at: > https://github.com/mcr/cbor-magic-number > > > # Introduction > > Since very early in computing, operating systems have sought ways to mark > which files could be proposed by which programs. > > For instance, the Unix file(1) command, which has existed since 1973 > ({{file}}), has been able to identify many file formats for decades. > > ... > > As CBOR becomes a more and more common encoding for artifacts, identifying > them as CBOR is probably not useful. > > This document provides a way to encode a magic number into the beginning of a > CBOR format file. > Two options are presented, with the intention of standardizing only one. > > These proposals are invasive to how CBOR protocols are written to disk, but > in both cases, the > proposed envelope does not require that the tag be transfered on the wire. > > Some protocols may benefit from having such a magic on the wire if they > presently using a different (legacy) encoding scheme, and need to determine > before invoking a CBOR decoder if the sender is using the legacy scheme, or > the new CBOR scheme. > > # Requirements for a Magic Number > > A magic number is ideally a unique fingerprint, present in the first 4 or 8 > bytes of the file, > which does not change when the content change, and does not depend upon the > length of the file. > > Less ideal solutions have a pattern that needs to be matched, but in which > some bytes need to be ignored. > > # Proposal One > > This proposal uses a CBOR Array of size two. > The first byte is therefore 0b100_00010 (0x82). > > Array element number one is a CBOR integer in the range 0x80000000 to > 0xffffffff. > This number is the magic number described below in {{magictable}} > > For a magic number 0x87654321, this results in a total of a six byte sequence: > > ~~~~ > 0b100_00010 0b000_11010 0x87 0x65 0x43 0x21 > ~~~~ > > Array element number two is whatever the original CBOR content is supposed to > be. > Due the array construct with known size, there is no further syntax required. > > # Proposal Two > > This proposal uses a CBOR Sequence {{!RFC8742}}. > > Array element number one is a CBOR integer in the range 0x80000000 to > 0xffffffff. > This number is the magic number described below in {{magictable}} > > For a magic number 0x87653412, this results in a total of a five byte > sequence: > > ~~~~ > 0b000_11010 0x87 0x65 0x34 0x12 > ~~~~ > > This is followed by one or more CBOR data items of whatever type was intended. > > ... and then some variations. > > (I probably had more important work I should have been doing) > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
