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

[Michael Richardson <[e-mail]>]

Christian Amsüss <[e-mail]> wrote:
    > 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.

My opinion is: not really.

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

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

I agree.

    > 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?

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