Subject: Re: [Cbor] Next steps for additional data types

From: Carsten Bormann <[email-masked]>
Date: Fri, 08 Jul 2016 00:18:50 +0200

Carsten Bormann wrote:
> [email-masked] wrote:
>> > Hi, has there been any discussion of where these two proposals fit with the existing TypedArray proposal?
> 
> No, not yet.  There are still a few days up to the Internet-Draft
> deadline for the Berlin meeting...

I now went ahead and submitted

https://tools.ietf.org/html/draft-jroatch-cbor-tags-04

For diffs, see:

https://www.ietf.org/rfcdiff?url2=draft-jroatch-cbor-tags-04

Thank you, Glenn!

I hope we get some F2F time to discuss this in Berlin.
The natural meeting point would be the artarea/dispatch meeting on
Monday morning, unfortunately that conflicts with 6lo:

MONDAY, July 18, 2016

1000-1230  Morning Session I
Potsdam II	ART	artarea	Applications and Real-Time Area Open Meeting  -
Combined with DISPATCH
Potsdam III	INT ***	6lo	IPv6 over Networks of Resource-constrained Nodes WG

I think we will find some other time and announce it here.

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Thu, 28 Jul 2016 18:09:58 -0700

> https://www.ietf.org/rfcdiff?url2=draft-jroatch-cbor-tags-04

Greetings:

I have reviewed draft-jroatch-cbor-tags-04. Here is my feedback.

Section 2. Typed Arrays

Okay; makes sense. However, the mismatch between [u/s]int8 and binary16 
is jarring. It would seem a lot better if 
uint16/sint16/binary16..uint128/sint128/binary128.

I checked the Typed Array Specification as part of this review. It's 
true that 128-bit integers aren't part of web Typed Arrays. But then 
again, neither 64-bit integers nor 128-bit floats are part of Typed 
Arrays either. Future-proof this thing: align ints and floats! __int128 
is a thing in GCC, and there is a typedef in MSVC. It's also not 
uncommon for graphics and GPU-related work.

In contrast, I don't see a lot of value to tagging an array as 
uint8...that would be called a plain old "byte string" by any definition 
of the term. Nevertheless, I see value in sint8 and possibly some minor 
value in the clamping thing.

In view of these comments, I propose:

                 +-----------+--------+--------+-----------+
                 | Length ll | uint   | sint   | float     |
                 +-----------+--------+--------+-----------+
                 | (-1)      | uint8  | sint8  | N/A       |
                 | 0         | uint16 | sint16 | binary16  |
                 | 1         | uint32 | sint32 | binary32  |
                 | 2         | uint64 | sint64 | binary64  |
                 | 3         | uint128| sint128| binary128 |
                 +-----------+--------+--------+-----------+

                           Table 1: Length values

For the case of uint8 and sint8, I propose that you allocate four tags 
in approximately 0b001111_c_s,
where c = clamped, and s = signed. That would be tags 0x3C - 0x3F in the 
current formulation. If you want parity with the bit positions in the 
other tags, I would propose rearranging the 0b010_f_s_e_ll to:
0b010_ll_f_e_s

(where when ll is -1, we are talking 0b00111, and f is always 1, even 
though it's not a float).

I would also like to suggest using tags in the 2-byte space, such as 
0x0220-0x0237 (or 0x021C - 0x0237). I suppose that you have thought of 
this already. I am less concerned about low-byte "pollution"; it has 
more to do with the need for expansion of typed arrays in the future. If 
you want to add binary256, int256, etc., you will have more guaranteed 
room to reserve and grow if you take a chunk out of the 2-byte space. 
Also, "since these typed arrays may carry significant amounts of data", 
the length of the tag is going to be dwarfed by each payload. One extra 
byte does not seem to hurt in this case. Ultimately, it is up to you, 
the authors.

Section 3.
No complaints. Looks all right. Tags 40 and 41 are okay with me.

Sections 4-6.
See prior comments (in case need to update consistent with Section 2).

I do have a comment on the #6.xxx() CDDL in Section 5, but I guess that 
comment needs to be addressed to "the CDDL people", so I'll save that.

Section 7. Security Considerations
Shall improper byte string length be considered a coding error, be 
filled in with zeroes, or be considered undefined behavior? There is a 
risk that if you have a byte string that is tagged as containing 
binary64 or int64, if the byte string is not a multiple of 8 bytes, you 
are going to chomp on garbage memory. You could say "assume all bits are 
0"; this will result in +0 according to IEEE 754 (which apparently 
compares equal to -0, but is a distinct bit pattern). It seems risky to 
me. There is an argument that you might want to permit "sparse arrays" 
where large quantities of the arrays are zeroes, which can result in 
optimal transmission by cutting off those bytes. But if you are relying 
on the length of the byte string, all you can save is (x / 8 - 1) bytes 
(where x is the bit length of the integers/floats).

I consider an irregular-length array to be a coding error; that is with 
my security hat on.

Regards,

Sean