[rfc-i] <sourcecode type="cbor">
cabo at tzi.org
Tue Feb 23 22:43:35 PST 2016
Paul Hoffman wrote:
> On 23 Feb 2016, at 14:59, Carsten Bormann wrote:
>> Is <sourcecode type="cbor"> CBOR diagnostic notation?
> Yes, given that people would expect <sourcecode type="asn.1"> to be a
> text representation, not the [BDP]ER bytecodes.
ASN.1 is a language for human consumption, so it is clear what that
means. CBOR is not such a language, it just has one (diagnostic
notation). But I think it is OK to use type="cbor" instead of the more
unwieldy type="CBORdiag" we have been using. Probably the future
RFC-editor page listing those tags should have a column with that
information; this is starting to remind me of an IANA-like registry
(Of course, we also have CDDL, which in the new lower-case conventions
would now probably be called type="cddl".)
>> (So far, we have been using CBORdiag here. We also often use actual
>> hexdumps of CBOR data in some stylized form; these often use CBORbytes.)
> We can't put arbitrary bytes into XML and expect them to be valid, so
> there might be a call to add type="cbor-bytes" and type="asn.1-bytes"
> that are defined to mean the Base64 encoding of those bytestrings.
> However, these seem edge-case-y, and can wait until we have a bit of
> experience with the format, yes?
We are actually using hex as these are illustrative. Example from a
recent spec (in markdown, but you get the idea):
a1 # map(1)
19 06ac # unsigned(1708)
a2 # map(2)
02 # unsigned(2)
78 1a # text(26)
01 # unsigned(1)
78 1a # text(26)
So yes, this is a little language (with its own comment convention).
The language is standardized nowhere, but has been considered intuitive,
and it has its own support website (http://cbor.me).
One more observation about these language tags:
The tag "CBORbytes" is one word because tools have had problems with
punctuation in the tags; we could not use "asn.1" for instance.
More information about the rfc-interest