[rfc-i] <sourcecode type="cbor">
cabo at tzi.org (Carsten Bormann) Wed, 24 February 2016 06:43 UTC
From: cabo at tzi.org (Carsten Bormann)
Date: Wed, 24 Feb 2016 07:43:35 +0100
Subject: [rfc-i] <sourcecode type="cbor">
In-Reply-To: <242BE23D-2285-4627-AA67-8FF148BB2002@vpnc.org>
References: <56CCE465.9010001@tzi.org>
<242BE23D-2285-4627-AA67-8FF148BB2002@vpnc.org>
Message-ID: <56CD5117.1000801@tzi.org>
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
- [rfc-i] <sourcecode type="cbor"> Carsten Bormann
- [rfc-i] <sourcecode type="cbor"> Paul Hoffman
- [rfc-i] <sourcecode type="cbor"> Carsten Bormann