Re: [Cbor] correctness of implied top level array?

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 28 February 2019 00:53 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 C0B5812D829 for <cbor@ietfa.amsl.com>; Wed, 27 Feb 2019 16:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 oNIYiismMoiq for <cbor@ietfa.amsl.com>; Wed, 27 Feb 2019 16:53:27 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AD1126C15 for <cbor@ietf.org>; Wed, 27 Feb 2019 16:53:26 -0800 (PST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 39B07380BE; Wed, 27 Feb 2019 19:53:19 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 1C08B989; Wed, 27 Feb 2019 19:53:24 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 197935BE; Wed, 27 Feb 2019 19:53:24 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carsten Bormann <cabo@tzi.org>
cc: Joe Hildebrand <jhildebrand@mozilla.com>, cbor@ietf.org, Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <052FFFD1-6145-4451-91A0-B07ED0AEC726@tzi.org>
References: <81789050-5133-48B0-BEE7-4F1E0BBB4C06@island-resort.com> <40A3B694-80A4-4AD7-A2A6-C071C6E88D2D@tzi.org> <F0A06813-3F1F-4D53-80A1-4CBBBB91DC64@island-resort.com> <0A96C82A-85DB-411D-812D-5A3479A8EA87@mozilla.com> <052FFFD1-6145-4451-91A0-B07ED0AEC726@tzi.org>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 27 Feb 2019 19:53:24 -0500
Message-ID: <9644.1551315204@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/3upZXY76An07h_pPu8hC8ISSIcs>
Subject: Re: [Cbor] correctness of implied top level array?
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: Thu, 28 Feb 2019 00:53:30 -0000

Carsten Bormann <cabo@tzi.org>; wrote:
    >> However, in my opinion both of the above cases are instances of
    >> protocols built on top of CBOR, not inherent in the CBOR design itself.

    > Indeed, that’s why cbor-seq is a separate document (and a separate media type).

    > When updating CBOR, we just need to be careful not to rule out decoders
    > that are fine to find additional data when done with the data item they
    > were tasked to decode.  (Both for cbor-seq and for piggy-backing CBOR
    > data in front of a binary blob in some other form.)
    > It took me a while to add that API to my CBOR implementation…

An alternative way to do the desired action (and bring this inside of cbor)
would be an (indefinite?) array type that was specified to concatenate.

I'm not really arguing for this, but I think it's worth knowing why this
would be less good a thing.

BTW: we certainly would up with "ASN1-SEQ" being an unevenly defined/implemented
     defacto-non-standard.  Certificates can sometimes be concatenated, and
     sometimes they can't, depending upon the location and the software being used.

--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting =-