Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rewrite a bit of the introduction, explain why heuristics are necessary #14

Merged
merged 2 commits into from Feb 8, 2022

Conversation

mcr
Copy link
Collaborator

@mcr mcr commented Jan 12, 2022

No description provided.


As CBOR becomes a more and more common encoding for a wide variety of artifacts, identifying them as just "CBOR" is probably not sufficient.
This document provides a way to encode a magic number into the beginning of a CBOR format file.
Two possible methods of enveloping data are presented: a CBOR Protocol author will specify one.
(A CBOR Protocol is a specification which uses CBOR as its encoding.)

A third method is also proposed by which this CBOR format prepended tag is used to identify non-CBOR files.
This third method has been placed in an appendix because it is not really about CBOR.
Copy link
Contributor

@cabo cabo Jan 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It actually is about CBOR: Using CBOR to tag non-CBOR data.

This third method has been placed in an appendix because it is not really about CBOR.

This entire document is a Best Current Practice: it gives advice to designers of CBOR protocols on identifying their contents.
This entire document is therefore informative, but the {{headers}} appendix is even more informative .
Copy link
Contributor

@cabo cabo Jan 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intention of this document is to define a standard for how to do this. This doesn't get less normative by the existence of other standards in this space. It's not a BCP because there is no C...

Copy link
Contributor

@cabo cabo Jan 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now in #15

@@ -63,11 +63,14 @@ is friendly to common on-disk recognition systems such as the Unix file(1) comma
# Introduction

Since very early in computing, operating systems have sought ways to mark which files could be processed by which programs.
At one point, files were all record orientated and the operating system enforced this.
Copy link
Contributor

@cabo cabo Jan 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, this is a somewhat categorical statement that is not true at that level. There were "Access methods", some of which were record-based, some of which weren't.

Copy link
Collaborator Author

@mcr mcr Jan 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my intent here is to say that, at the beginning of time, the OS knew how to process every file, and then when we went to everything is a stream of bytes, we lost this. Maybe this isn't worth saying at all?

@cabo
Copy link
Contributor

@cabo cabo commented Jan 26, 2022

I pushed a slightly less radical amputation, which leaves the connection to the following text intact.

@cabo cabo force-pushed the explain-appendix-and-bcp branch from e6235ed to 9d49758 Compare Feb 8, 2022
@cabo cabo merged commit 2358fc7 into main Feb 8, 2022
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants