Re: [Cbor] draft-bormann-cbor-sequence-00 and Big Data

Carsten Bormann <cabo@tzi.org> Sun, 23 June 2019 05:43 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 94FDD1200EB for <cbor@ietfa.amsl.com>; Sat, 22 Jun 2019 22:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 tQBncju9cIxD for <cbor@ietfa.amsl.com>; Sat, 22 Jun 2019 22:43:18 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49131200A4 for <cbor@ietf.org>; Sat, 22 Jun 2019 22:43:18 -0700 (PDT)
Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45WhD449ztz1005; Sun, 23 Jun 2019 07:43:16 +0200 (CEST)
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: <MWHPR22MB0336C10E7C7D2C4F2146D4FA92E10@MWHPR22MB0336.namprd22.prod.outlook.com>
Date: Sun, 23 Jun 2019 07:43:14 +0200
Cc: "cbor@ietf.org" <cbor@ietf.org>
X-Mao-Original-Outgoing-Id: 582961392.086924-4abc59b4b5628e9b18a9489a9059dfbb
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3329E7E-7112-40FC-81CF-090EED6687C7@tzi.org>
References: <MWHPR22MB0336C10E7C7D2C4F2146D4FA92E10@MWHPR22MB0336.namprd22.prod.outlook.com>
To: Burt Harris <burt_harris@hotmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/tiB8VZmM9IpcezASDDT_jKKEtac>
Subject: Re: [Cbor] draft-bormann-cbor-sequence-00 and Big Data
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: Sun, 23 Jun 2019 05:43:21 -0000

Hi Burt,

thanks for your kind words on RFC 8610 and CBOR sequences!

Whether the sequence-preserving property of CBOR sequences is useful for your application or not depends on the application.  CBOR sequences do not take a position on this, they just preserve the sequence (because they can, at approximately zero cost).  This is exactly as with CBOR arrays, where it also depends on the application whether the actual sequence means something or not.  For serialization, they need to be in a specific sequence, so we might as well make that available to the application.  There are applications that use CBOR sequences in a way that cannot really be called a stream, so I think we are better off with the “sequence” name.

Tagging a CBOR sequence as such is a bit difficult because logically a CBOR tag would be tagging the first item in the sequence.  CBOR sequences are best used in a context where it is clear what they are (e.g., via a media type); I tend to think of them like CBOR arrays that have been taken out of their package…

Any special split markers can be provided by simply putting CBOR data items for those markers into the CBOR sequence.  And, yes, such an application might be a good reason to allocate a CBOR Simple value or two.  We don’t need an equivalent for YAML “…”, though, because the CBOR data items themselves are self-delimiting.

Grüße, Carsten