Re: [Cbor] 🔔 WGLC on draft-ietf-cbor-array-tags-03

[Carsten Bormann <[e-mail]>]

On Mar 8, 2019, at 02:03, Jeffrey Yasskin <[e-mail]> wrote:
> 
> This generally looks good to me, with decreasing confidence as the
> document gets farther from the simple typed-array use case in its
> title. A couple comments below:
> 
> 1. The document justifies itself with "performance" improvements, but
> I believe the tags also save the space overhead of encoding a type for
> each element or nested array.

Potentially.  (Depending on how many elements of the array are small enough to benefit from even shorter encoding.)  But that is indeed a motivation.

For this reader, space savings are part of “performance”.
Do we have to be more explicit about that?

> 2. It's not clear on the first reading that
> https://tools.ietf.org/html/draft-ietf-cbor-array-tags-03#section-3.1
> defines two different tags. I'd appreciate either a subsection for tag
> 1040 or parallel subsections for the two tags.
> 
> 3. The definition of tag 40 ends with "Data in the Typed Array byte
> string …", but the second sub-array doesn't need to be a Typed Array.
> 
> 4. The definition of tag 1040 starts with "Note" making it look
> non-normative. I'd rather have that paragraph define the meaning of
> the data item, like "The data item is interpreted the same as in tag
> 40 except that the second sub-array holds elements with the first
> dimension contiguous (column-major order)."
> 
> 5. The reference to Section 7.1 of [TypedArrayUpdate] is out of date.

I believe these are all good opportunities for improvements.  Will make issues.

> 6. It's not clear to me that representing the source of the elements
> in a uint8 array is worth the confusion of re-using the
> is-little-endian bit. What's a use case? It exists in Javascript to
> define how assignment works, but one does not assign to CBOR data.

It is not really where they came from, but how they are meant to be processed further.
So a JavaScript implementation would deserialize into a clamped array.

> 7. What's the use case for the homogenous array tag? Tags, in general,
> are mostly useful for generic parsers: do we have an example of one of
> those that's going to add a new set of homogenous array types for its
> consumers to have to check for?

A generic decoder might lay out a more compact array of integers instead of an array of CBOR data items when it sees this tag (and the first element is an integer).
I’m not sure there is an implementation out already that does this.

I think this becomes relevant at the encoder API only if there are natural native types being fed in that are homogeneous (and the application gives license to use the tag 41, but the typed array tags do not apply).

(Meta-comment: Maybe 40, 1040, and 41 should have gone into a separate document.
But it did feel expeditious to include them here.)

Grüße, Carsten