Subject: [Cbor] draft-ietf-cbor-file-magic: Processing recommendations

From: Christian Amsüss <[email-masked]>
Date: Wed, 21 Apr 2021 17:15:27 +0200

Hello Michael,

looking at cbor-file-magic from the "implementing generic tools" (static
CoAP file server, downloading CoAP client) point of view, I'm wondering
whether anything actionable for these cases.

I'm tempted to do crazy things, serving content formats from recognized
CBOR protocol tags, and possibly stripping the tagging once transferred
into a Content-Format option, or doing the inverse when downloading into
a file. Turning down the crazy, these things may make more sense in an
opt-in fashion both on the server and on the client side. Going only
half the way and serving the content-format while also sending the full
data stream probably makes no sense (if the data was really intended to
be application/octet-stream, the server is already lying about the
content format, and stealing the inital bytes just adds to the charges).

Is there any recommendation on that topic that you'd deem sensible,
either in-document or just on the "it's been discussed on the list"
record?

(On the mapping between content formats and tags I'll have to revisit
the discussion history; I was under the impression that at some point
this was tied to content format numbers, as in "registering 2**16 tags
at once", but seems I was mistaken here).

BR
c

PS. Is bcp really the intended category for that document?

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Apr 2021 15:37:02 -0400

> whether anything actionable for these cases.

My opinion is: not really.

    > a file.

I certainly think that storing the media type with the file is smart.
MacOS does it, and a number of non-/pre-Unix systems forced the file
extension.  It wasn't until Unix/CPM/DOS that had pseudo-relevant file
extensions, but didn't enforce any meaning on them that we things got
confusing.  But, that was because "it's all a stream of bytes" meant that you
could apply tools in a less regimented way.
In a world of XML,JSON,CBOR, being able to process records has started to
have some appeal again.

I think that deriving a media type (both for CoAP and HTTP) from the
cbor-file-magic makes sense.  Whether or not you want to strip off the
12-byte sequence-style prefix is another question to me.

    > Turning down the crazy, these things may make more sense in an

I agree.

    > either in-document or just on the "it's been discussed on the list"

I think that a place where it wins is forensics.
We know that we are going to embed trust anchors into systems.
The trust anchors are public keys with authorizations attached to them.
Marking each trust anchor with what it's intended to validate
is cheap and easily avoids confusion.
     ("Huh, so your refridgerator trusts the root DNSSEC key for software
       updates, and it can't do DNS if you turn on DNSSEC? How did that happen?")

The second place is where two possible CBOR encoded things can be sent over
some channel.  Or where a CBOR encode thing, or a legacy thing might be sent,
and the legacy thing already has some kind of magic header.

    > PS. Is bcp really the intended category for that document?

Yes, because there really isn't any SHOULD/MUST here.
The 55800 tag, which we added for this document, is of general use.
The per-protocol tag is one which the user of this BCP obtains, so we aren't
specifying anything there.

We are just explaining a way to use existing mechanism to put things together.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Apr 2021 22:23:48 +0200

> at once", but seems I was mistaken here).

I still like the idea.

Grüße, Carsten