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

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jan 2021 18:56:01 -0500

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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Josef 'Jeff' Sipek <[email-masked]>
Date: Wed, 20 Jan 2021 20:07:42 -0500

On Wed, Jan 20, 2021 at 18:56:01 -0500, Michael Richardson wrote:
...
...
...
> This proposal uses a CBOR Sequence {{!RFC8742}}.

Recently, I was thinking about the fun fact that the Unicode string "bor"
and the byte string "BOR" end up getting encoded as "cbor" and "CBOR",
respectively.

Maybe that could be somehow (ab)used?  In general, I'm a big fan of
human-readable magic numbers.

Jeff.

---

From: David Waite <[email-masked]>
Date: Wed, 20 Jan 2021 18:30:41 -0700

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 <[email-masked]> wrote:
> 
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jan 2021 21:10:10 -0500

Josef 'Jeff' Sipek <[email-masked]> wrote:
    > On Wed, Jan 20, 2021 at 18:56:01 -0500, Michael Richardson wrote: ...
    >> Since very early in computing, operating systems have sought ways to
    >> mark which files could be proposed by which programs.
    >>

    > Recently, I was thinking about the fun fact that the Unicode string
    > "bor" and the byte string "BOR" end up getting encoded as "cbor" and
    > "CBOR", respectively.

Oh my.
That's too cool not to run with.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jan 2021 21:11:49 -0500

> "bor" and the byte string "BOR" end up getting encoded as "cbor" and

obiwan-[work/richardson/cbor-file-magic](2.6.6) mcr 10355 %echo -n cbor | cbor2diag.rb
"bor"

obiwan-[work/richardson/cbor-file-magic](2.6.6) mcr 10356 %echo -n CBOR | cbor2diag.rb
h'424F52'

so, the first case is true, but the second does not seem to be.

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 20 Jan 2021 19:16:00 -0700

> mark which files could be proposed by which programs.

The word "proposed" feels very awkward here. Maybe "opened" or "manipulated," or some recasting of the sentence that talks about files "belonging to" programs, or something similar.

--
Doug Ewell, CC, ALB | Thornton, CO, US | ewellic.org

-----Original Message-----
From: CBOR <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, January 20, 2021 16:56
To: [email-masked]
Cc: cose <[email-masked]>
Subject: [Cbor] CBOR magic number, file format and tags

Hi, I was thinking about this yesterday too, and after the discussion this morning at COSE, I wrote:

which is at:

# 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.

...

---

From: Josef 'Jeff' Sipek <[email-masked]>
Date: Wed, 20 Jan 2021 21:19:07 -0500

> obiwan-[work/richardson/cbor-file-magic](2.6.6) mcr 10356 %echo -n CBOR | cbor2diag.rb

Which is hex for 'B' 'O' 'R'. :)

I'm guessing cbor2diag.rb sees the raw data and hexdumps it to be helpful.
Here's what python has to say:

In [1]: import cbor

In [2]: cbor.loads(b'cbor')
Out[2]: 'bor'

In [3]: cbor.loads(b'CBOR')
Out[3]: b'BOR'

Note the difference in return type - the first is unicode string the second
is a byte string.

Jeff.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 20 Jan 2021 22:18:03 -0500

"Doug Ewell" <[email-masked]> writes:
> The word "proposed" feels very awkward here. Maybe "opened" or
> "manipulated," or some recasting of the sentence that talks about
> files "belonging to" programs, or something similar.

When I first read that, I mis-read it as "processed by".  I suspect that
is what is intended.

But ... Am I missing something?  Isn't a magic number provided by RFC
8949 section 3.4.6?

   3.4.6.  Self-Described CBOR

   [...]
   Tag number 55799 is defined for this purpose, specifically for use at
   the start of a stored encoded CBOR data item as specified by an
   application.  It does not impart any special semantics on the data
   item that it encloses; that is, the semantics of the tag content
   enclosed in tag number 55799 is exactly identical to the semantics of
   the tag content itself.

   The serialization of this tag's head is 0xd9d9f7, which does not
   appear to be in use as a distinguishing mark for any frequently used
   file types.  [...]

Dale

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jan 2021 04:31:19 +0100

Challenge accepted.
CBOR diagnostic notation is quite versatile, you just have to tell cbor2diag.rb what you want.

cbor2diag.rb -t: bytes_as_text, i.e., use text form for bytes if possible.

$ printf cbor | cbor2diag.rb -t
"bor"
$ printf CBOR | cbor2diag.rb -t
‘BOR'

Oh, and, BTW:

cbor2diag.rb -e: try_decode_embedded, i.e., try embedded CBOR.

$ printf CBOR | cbor2diag.rb -te
<< 'OR' >>

(Do a “gem update” to get cbor2diag.rb version 0.5.9 for -t.)

Back to the magic number issue:

For CBOR data items, I prefer registering a tag and prefixing with that head (*) over prefixing with an array head and a string.  See, we have a magic number registry built right into CBOR...

For CBOR sequences, obviously prefixing the sequence with a CBOR-encoded (text or byte) string sounds quite good.  Making that optional (to save bytes when you don’t need it) requires that the sequence otherwise cannot start with that kind of string.

Grüße, Carsten

(*) E.g., tag 15309736 for the RAINS protocol:

>> CBOR::Tagged.new(15309736, "oooooo").to_cbor
=> "\xDA\x00\xE9\x9B\xA8foooooo"
>> CBOR::Tagged.new(15309736, "oooooo").to_cbor[2..].force_encoding(Encoding::UTF_8)
=> "雨foooooo"

Oh, for those who don’t speak Chinese:

$ trans 雨
雨
(Yǔ)

rain

Definitions of 雨
[ 简体中文 -> English ]

noun
    rain
        雨, 雨天, 霅

adjective
    rainy
        雨, 多雨的

雨
    rain

> On 2021-01-21, at 03:19, Josef 'Jeff' Sipek <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2021 07:24:39 -0500

> When I first read that, I mis-read it as "processed by".  I suspect
    > that is what is intended.

    >    [...]  Tag number 55799 is defined for this purpose, specifically

That tells us that it might be CBOR.

It does not distinguish a CBOR encoded certificate from a CBOR encoded
RFC8366 artifact, for instance.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2021 08:44:51 -0500

I think this belongs in CBOR, not COSE.
It sounds like this is something that a few people are interested in persuing.
Is it a BCP or a Standard?

Carsten Bormann <[email-masked]> wrote:
    > Challenge accepted.  CBOR diagnostic notation is quite versatile, you
    > just have to tell cbor2diag.rb what you want.

okay.

    > $ printf cbor | cbor2diag.rb -t "bor" $ printf CBOR | cbor2diag.rb -t
    > ‘BOR'

    > $ printf CBOR | cbor2diag.rb -te << 'OR' >>

alright, I award full cool points.

    > For CBOR data items, I prefer registering a tag and prefixing with that
    > head (*) over prefixing with an array head and a string.  See, we have
    > a magic number registry built right into CBOR...

I can live with this, but here are my concerns.
If we go this way, then it just becomes a BCP on good CBOR protocol design.

1) when transmitting over the wire, shorter tags are preferred, and I'm
   concerned that they will be too short to useful *on-disk* magic numbers.
   The same short sequence could occur in other kinds of files rather easily.

2) I wanted a structure that made it rather easy for an application that is
   reading from the disk to know what part they can omit when transmitting.
   That's why I initially looked at the two-element array, with the second
   element being the actual "thing"

    > For CBOR sequences, obviously prefixing the sequence with a
    > CBOR-encoded (text or byte) string sounds quite good.  Making that
    > optional (to save bytes when you don’t need it) requires that the
    > sequence otherwise cannot start with that kind of string.

For on-disk files, if one uses a CBOR Sequence, I wasn't thinking about ever
having the prefix be optional.  But, we could go that way easily if do

   Tag<per-protocol-tag>CBOR
or
   Tag<CBOR-protocol-tag>Per-protocol-Value.

As the prefix, as I think that would be quite easily not part of any protocol.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2021 08:50:17 -0500

> "manipulated," or some recasting of the sentence that talks about files
    > "belonging to" programs, or something similar.

Oops. "processed" was the intended word.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2021 09:00:19 -0500

> a magic number registry built right into CBOR...

BTW, in case you didn't read far enough, that was variation two:

## Use a CBOR Tag on the CBOR Integer

A two or three byte CBOR Tag could be used in proposal two, applied to the CBOR Integer.

Or, a two byte CBOR Tag could be used in proposal one, applied to the CBOR Integer,
and not applied to the array.
This would make the first four bytes of a CBOR encoded item recognizeably CBOR,
with the next four bytes being the specific CBOR content.

....

I didn't know if using the Tag registry was a welcome or unwelcome hack.

My take right now is that you:
1) prefer a CBOR Sequence
2) prefer a per-protocol CBOR Tag around something.
   * c"bor" or C"BOR" would seem to be the right strings here!
3) probably prefix it all with Tag number 55799.

Tag<55799>Tag<Protocol>C"BOR"
3-bytes   5-bytes      4-bytes   = 12 bytes, with the relevant magic number
                                   being the first 8-bytes

So in section 6, in the case where the CBOR Tag registry is used, then there are two options I
thought of:

1. allow requesters to select their own four (32-bit) or eight (64-bit) tags, from the First Come First Served Registry, using the existing instructions.

2. amend the IANA instructions for {{RFC8949}} and carve out a 30-bit chunk of the four byte registry,
or a 32-bit chunk of the eight byte registry.

While in many cases CBOR encodings strive to be as compact as possible, for the purposes of a magic number registry for objects stored on disk, the use of between eight and twelve bytes is acceptable.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jan 2021 15:39:00 +0100

> 1) prefer a CBOR Sequence

I actually was proposing two different approaches, one for magic-numbering CBOR data items (like the 55799 does today) and one for CBOR sequences.
But, of course, data items are just CBOR sequences of length 1, so they can easily be used in a CBOR sequence-only proposal.

>   * c"bor" or C"BOR" would seem to be the right strings here!

Well, “cool” (a byte string of length three, as well :-), but maybe not adding much.

> 3) probably prefix it all with Tag number 55799.

Not sure that is needed, but we could use it.

> 3-bytes   5-bytes      4-bytes   = 12 bytes, with the relevant magic number

Nice.

This has the advantage that:

— we are still using the tag registry to register protocol tags
— the prefix is recognizable as a magic number prefix (the first four bytes and byte 8 to 11 are the signature)
— we are using up 1+4-byte tag numbers, which there are plenty.

So an implementation cat remove that magic number from a file with a single CBOR data item or CBOR sequence that is following, keeping an efficient on-the wire format.  And it would be possible to more or less indiscriminately slap the magic number on any CBOR on-disk format.

Nice.  A single proposal that covers everything, at the cost of 12 bytes of magic number.

> 1. allow requesters to select their own four (32-bit) or eight (64-bit) tags, from the First Come First Served Registry, using the existing instructions.

Adding the eight-byte version complicates things slightly, but could be done, too (there are two magic number signatures, then).

> or a 32-bit chunk of the eight byte registry.

In which case the 55799 antics and the <<‘OR’>> would be a bit redundant.
(We would need to update the registry to do this carve-out, I think; registering a billion tags would also do a carve-out but then we can’t use the normal registry process to do the allocation.)

> While in many cases CBOR encodings strive to be as compact as possible, for the purposes of a magic number registry for objects stored on disk, the use of between eight and twelve bytes is acceptab…

In particular if it is easy to remove…

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2021 15:46:01 -0500

okay, I've revised the document, going for the "CBOR" double-tag sequence
only, as that seems to be the preference among those who have spoken.

I've asked for a tag for my use case, and once I have it, I'll add my
example.

Comments appreciated: maybe the chairs could chime in on whether this is on charter.
I think that this needs to be marked as BCP (which my document doesn't say yet)

>A new version of I-D, draft-richardson-cbor-file-magic-01.txt
>has been successfully submitted by Michael Richardson and posted to the
>IETF repository.
>
>Name:		draft-richardson-cbor-file-magic
>Revision:	01
>Title:		On storing CBOR encoded items on stable storage
>Document date:	2021-01-21
>Group:		Individual Submission
>Pages:		5
>URL:            https://www.ietf.org/archive/id/draft-richardson-cbor-file-magic-01.txt

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: John Mattsson <[email-masked]>
Date: Thu, 21 Jan 2021 23:19:21 +0000

Hi,

It seems like there is agreement to specify a CBOR tag for a CBOR certificate. I stated specifying this for the next -07 version, se below.

I started to specify a tag based on Laurance suggestion to tag an array wrapping the CBOR Sequence. I don't know how to best specify this data item. It would have been easy before when the CBOR Sequence was specified as a CDDL group. Now when CBORCertificate is specified as an array with human-readable text specifying that it is really a CBOR sequence, both CBORCertificate and [ CBORCertificate ] seems wrong....

Would a tag for a chain/bag or both be needed as well? If a tag for COSE_X509 with CBOR certificates is specified, that could potentially be used to tag a single certificate as well.

Maybe it is confusing to use the COSE_X509 CDDL for CBOR certificates? A new structure for CBOR certificates could then also be more compact by wrapping the certs in arrays instead of bstr.

---------

## CBOR Tags Registry {#tags}

This document registers the following entries in the "CBOR Tags" registry under the "Concise Binary Object Representation (CBOR) Tags" heading.

~~~~~~~~~~~
+------+------------------------------------------------------------+
|  Tag | X.509 Public Key Algorithms                                |
+======+============================================================+
| TDB6 | Data Item: [ CBORCertificate ]                             |
|      | Semantics: The CBORCertificate CBOR sequence wrapped in an |
|      |            array.                                          |
|      | Reference: This document                                   |
+------+------------------------------------------------------------+
| TDB7 | Data Item: COSE_X509                                       |
|      | Semantics: The content of each bstr is the bytes of a CBOR |
|      |            Certificate.                                    |
|      | Reference: This document                                   |
+------+------------------------------------------------------------+
~~~~~~~~~~~

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2021 19:29:02 -0500

John Mattsson <[email-masked]> wrote:
    > It seems like there is agreement to specify a CBOR tag for a CBOR
    > certificate. I stated specifying this for the next -07 version, se
    > below.

I'm not sure what a _CBOR certificate_ is, and I suggest we don't use that
term for your document.  I think it's a CBOR-compressed PKIX certificate.
(CCPC if you like. Maybe someone can figure out how to backronym CCCP, and we
can them Soviet Russians)

    > I started to specify a tag based on Laurance suggestion to tag an array
    > wrapping the CBOR Sequence. I don't know how to best specify this data

I don't know either.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 21 Jan 2021 21:37:29 -0500

> RFC8366 artifact, for instance.

Uh, yes?  They're both CBOR, right?  It's still the magic number for
CBOR.

Do you mean to say, you want a place in CBOR to place a magic number
that describes the particular kind of CBOR structure this is?  If so,
you should make that clear right at the start of the I-D.  Indeed, in
the Abstract, though it needs other work, too.  Checking again, it looks
like you don't really lay that out until section 6, whereas I only read
it through section 5.  My mistake, but lots of other people will make it
as well.

Dale

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Jan 2021 11:17:00 -0500

> that describes the particular kind of CBOR structure this is?

Yes.

    > If so,
    > the Abstract, though it needs other work, too.  Checking again, it
    > looks like you don't really lay that out until section 6, whereas I
    > only read it through section 5.  My mistake, but lots of other people
    > will make it as well.

Better wording suggestions welcome.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 22 Jan 2021 22:14:44 -0500

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.

Dale

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 23 Jan 2021 14:07:59 +0100

> On 2021-01-23, at 04:14, Dale R. Worley <[email-masked]> wrote:
> 

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.)

— 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.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Jan 2021 15:01:22 -0500

Carsten Bormann <[email-masked]> wrote:
    > 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.

I am personally agnostic about CBOR Sequence vs something else.

I believe that:
  a) the magic number needs to be at least 4 bytes
  b) we shouldn't mandate that it be transmitted on the wire.

Being able to split off the magic part easily make sense to me.
That's why I proposed either:
  1) CBOR Sequence
  2) Two-element array.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 23 Jan 2021 21:21:34 +0100

> That's why I proposed either:

(Which is the only approach to magic-numbering CBOR sequences, and works for CBOR data items as long as you don’t mind them turning into CBOR sequences.)

>  2) Two-element array.

Which is mostly a weird way to express a tag, without the need to register it.
Why would this be better than a tag?
(Unless you believe registering them is too onerous or creates too much noise in the registry.)
So I’d prefer using tags, which otherwise have exactly the same properties.
The 1+2+1+4 proposal looks pretty good to me.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 23 Jan 2021 12:36:10 -0800

My choice would be to parallel what is done for COSE, CWT and most other CBOR protocols I’ve seen:

1) Make the compressed CBOR certs an array instead of a sequence for all use. This makes it one byte bigger, but it makes it work just like the other CBOR protocols that have been defined. I see the use of CBOR sequence here as an outlier, somewhat confusing and burdensome. It is burdensome because you can’t just drop them into other CBOR protocols and because a tag for it has to be special. As far as I can tell the only reason this is a sequence and not an an array is to save the one byte. 

2) Assign a tag that indicates compressed CBOR cert and use it just like the tags for COSE and CWT or any other protocol with an identifying tag. Or said another way, most CBOR protocols have an identifying tag. Compressed CBOR certs should have one too.

3) When you put it in a file, use the 55799 magic number to indicate it is CBOR and then the compressed CBOR cert tag to indicate it is a compressed CBOR cert. If the tag number was 48 then the first bytes of the file would be:

d9 d9 f7 d8 30 8b … 

You could take d9 d9 f7 d8 30 to be the magic number for a compressed CBOR cert. The 8b is to open the array for step 1) above. When you want to put the compressed CBOR cert into a protocol message field that needs no tagging you can just exclude those five bytes. When you take it out of a protocol message and put it in a file, you add those five bytes.

This mechanism would work for CWTs and COSEs in files too.  Similarly a COSE_Sign1 CWT in a file would be:

d9 d9 f7 d8 3d d2 84

This is three nested tags 55799(61(18(…))), a COSE_Sign1 in a CWT in a 55799. You can treat d9 d9 f7 d8 3d d2 the magic number.

Or take d9 d9 f7, the 55799 tag, to be the magic number indicating CBOR causing a general CBOR dispatcher to be started. That dispatcher looks for a second tag. Based on a second tag it dispatched to the handler for the compressed cert, the CWT, the COSE, the CoSWID, the UCCS...

LL

> On Jan 23, 2021, at 5:07 AM, Carsten Bormann <[email-masked]> wrote:
> 
> 
> 
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 23 Jan 2021 21:42:40 +0100

> You could take d9 d9 f7 d8 30 to be the magic number for a compressed CBOR cert. The 8b is to open the array for step 1) above. When you want to put the compressed CBOR cert into a protocol message…

… or six bytes!

(Turning the over-the-air cert into a CBOR sequence again.)

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Jan 2021 16:39:24 -0500

> Which is mostly a weird way to express a tag, without the need to
    > register it.  Why would this be better than a tag?  (Unless you believe
    > registering them is too onerous or creates too much noise in the
    > registry.)  So I’d prefer using tags, which otherwise have exactly the
    > same properties.  The 1+2+1+4 proposal looks pretty good to me.

It just avoids the CBOR Sequence.
The first element is something.  It can be a CBOR Tag<CBOR>.
The real item is second element.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 23 Jan 2021 22:49:40 +0100

> The real item is second element.

I’m still intrigued.
So why not just put the tag on the data item to be tagged?

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Jan 2021 17:45:56 -0500

Carsten Bormann <[email-masked]> wrote:
    >> It just avoids the CBOR Sequence.  The first element is something.  It
    >> can be a CBOR Tag<CBOR>.  The real item is second element.

    > I’m still intrigued.  So why not just put the tag on the data item to
    > be tagged?

For content that the application doesn't really know a lot about,
(a CBOR compressed certificate for instance), then the second element is
always the thing transmitted.  (With whatever tags are there!)

The application doesn't have to have such intimate knowledge about whether or
not to send the tags.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 23 Jan 2021 23:54:37 +0100

OK, so you always get the CBOR sequence solution, you just don’t always send it naked (as a CBOR sequence), put sometimes wrapped in an array.

Grüße, Carsten

> On 2021-01-23, at 23:45, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 24 Jan 2021 00:25:03 -0500

Carsten Bormann <[email-masked]> wrote:
    > OK, so you always get the CBOR sequence solution, you just don’t always
    > send it naked (as a CBOR sequence), put sometimes wrapped in an array.

I don't feel strongly either way.

Also, both the array and the sequence solution result in a solid 8-to-12
bytes of known data at the beginning so file(1) will be very happy.
(ps: It already knows about 55799)

{I've re-implemented my code with a CBOR Sequence, but I'm annoyed that I
haven't found a decode in C that takes a getc(3)-like input stream, and eats
only as many things as it needs.  I have just abandonned tinycbor for QCBOR.}