Subject: [Cbor] Terminology for parts of CBOR items

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 11 Aug 2017 15:25:37 -0700

I'd like CBOR-bis to, if possible, provide some clearer terminology
for the pieces of a CBOR item, mostly so that implementations of CBOR
can use the terms and so be easier to read.

Take a 32-byte byte string. We have:

* Type 2
* Additional information 24
* Length 32
* Some data.

The Type+Additional Info is the "initial byte" per
https://tools.ietf.org/html/rfc7049#section-2. Are we happy with this
term? I don't see a term for the Type+Additional Info+Length. [1]

For the negative integer -32, we have:

* Type 1
* Additional Information 24
* Value 31

I don't see a term that includes both the byte string's length and the
integer's value. [2]

I don't have strong opinions about what these terms should be, but in
the spirit of not complaining without offering a path forward, I'll
propose:

[1] "Item header"? For integers and simple items, the item header
would be the same as the item.
[2] "Argument"? This isn't very good, but I don't have a better idea.

Jeffrey

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 12 Aug 2017 08:51:08 +0200

In some implementations, we have called the parts of a CBOR data item:

* the head (initial byte plus any additional bytes needed to convey the unsigned integer) and 
* the body (the string or additional data items contained in that data item).

So if head(n) stands for the initial byte and additional bytes that convey the unsigned integer n, we get the following summary of (definite length) CBOR data items:

Major type   Head      Body
0, 1, 7      head(n)   – (Head only)
2, 3         head(n)   n bytes
4            head(n)   n data items
5            head(n)   2n data items
6            head(n)   1 data item

We did not come up with very good terms for the indefinite length case (as in RFC 7049 we called 0xFF the “break"; the initial byte for indefinite length of course also could be called a head; both together are the “brackets").

Grüße, Carsten

> On Aug 12, 2017, at 00:25, Jeffrey Yasskin <[email-masked]> wrote:
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Sean Leonard <[email-masked]>
Date: Sat, 12 Aug 2017 09:20:30 -0700

Just my two cents, I don’t think it needs to be overthought…

CBOR falls into the general category of a binary TLV (type-length-value) encoding. The “Additional information” portion does not change this. In ASN.1 BER, the length can be encoded directly in the first length octet (“short form”), or the bits in the first length octet can specify how many octets follow that represent the length of octets of the content (“long form”). CBOR compacts the major type and initial length into one octet; otherwise, this is pretty much the same philosophically as CBOR. Note that zero-length data items still count as TLV, and the sentinel that signals the end of an indefinite-length data item is a special double case of a complete data item, as well as the last portion of a valid TLV encoding. (So the 0xff “break” in CBOR is exactly analogous to the “end-of-contents octets” in ASN.1 BER, see X.690 (2015) Section 8.1.5.)

The term “header” usually refers to, well, headers: a run of “header fields, each consisting of a header name, a colon [or other delimiter], and data” [RFC5322], separated by newlines. A “body” is the stuff after the “header section” ends. It is a more macro-thing for text-oriented protocols/data formats.

In CBOR, “Type+Additional Info+Length” is the “TL” of “TLV”.

An entire Major Type+Additional Info+Length+Data(optional +Break) would be CBOR’s protocol data unit (PDU); RFC 7049 calls it “CBOR-encoded data item” (basically the same thing).

It’s not productive to call out the “both the byte string's length and the
integer's value” independently of the major type bits, because how one interprets additional information, length, and data (value) depends entirely on the major type bits. The additional information bits are always about “length of string” for byte and UTF-8 text strings, but the data can be compacted into the additional information for integers, maps, and arrays. Major type 7 can go all sorts of ways and there is extensibility in the spec for future work (AI values 28-30) to do any sort of thing.

The incidence of data-less / body-less PDUs can be high in CBOR, in contrast some other formats (e.g., ASN.1 BER). For simple protocols one can easily imagine a PDU on the wire that contains nothing more than a few maps and arrays that contain integers and true/false/null values, none of which require a “body”/“content” (i.e., data that requires a length of octets specified in the Ai bits).

Regards,

Sean

> On Aug 11, 2017, at 3:25 PM, Jeffrey Yasskin <[email-masked]> wrote:
>