[rfc-i] <sourcecode type="cbor">

Carsten Bormann 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
template.

(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):

~~~~ CBORbytes
a1                                      # map(1)
   19 06ac                              # unsigned(1708)
   a2                                   # map(2)
      02                                # unsigned(2)
      78 1a                             # text(26)
      323031352d31302d30325431343a34373a32345a2d30353a3030
      01                                # unsigned(1)
      78 1a                             # text(26)
      323031352d30392d31355430393a31323a35385a2d30353a3030
~~~~
{: align="left"}

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.

Grüße, Carsten


More information about the rfc-interest mailing list