Re: [Cbor] πŸ”” WGLC on draft-ietf-cbor-array-tags-03

Carsten Bormann <cabo@tzi.org> Fri, 08 March 2019 07:56 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBE71312DE; Thu, 7 Mar 2019 23:56:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHwlWVajkngG; Thu, 7 Mar 2019 23:56:12 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6538D131311; Thu, 7 Mar 2019 23:56:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x287u2Y0014445; Fri, 8 Mar 2019 08:56:07 +0100 (CET)
Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44G0Dd6Bt5z1Bp8; Fri, 8 Mar 2019 08:56:01 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CANh-dX=dnfMzMaanoavbvxdZBzfcU8aZS625esnJ8Tt1eF94tQ@mail.gmail.com>
Date: Fri, 8 Mar 2019 08:56:01 +0100
Cc: "cbor@ietf.org" <cbor@ietf.org>, "draft-ietf-cbor-array-tags@ietf.org" <draft-ietf-cbor-array-tags@ietf.org>
X-Mao-Original-Outgoing-Id: 573724558.9582289-70bf69b9a33891193abf072d1c3b53f7
Content-Transfer-Encoding: quoted-printable
Message-Id: <C06F5B81-37DD-4F08-A68B-E2C9F9520209@tzi.org>
References: <426CD514-B174-4CE7-B467-2727C6B5B354@ericsson.com> <CANh-dX=dnfMzMaanoavbvxdZBzfcU8aZS625esnJ8Tt1eF94tQ@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin@chromium.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/hPhUmuYFvnbbmEx8ezMZisk7Qys>
Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-cbor-array-tags?= =?utf-8?q?-03?=
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 07:56:23 -0000

On Mar 8, 2019, at 02:03, Jeffrey Yasskin <jyasskin@chromium.org>; 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