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

I've always assumed that I would eventually write an XMPP-like protocol that used a stream of CBOR items without further delineation, and node-cbor reflects that, perhaps to the detriment of other use cases.  I *think* you could trick it into reading one CBOR item from a stream and stopping with the rest of the bytes still intact, but I'd have to write a few tests to be sure.

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.

— 
Joe Hildebrand

> On Feb 26, 2019, at 9:11 PM, Laurence Lundblade <lgl@island-resort.com> wrote:
> 
> Hi Carsten,
> 
> So wouldn’t that mean application/cbor is required to consist of one and only one data item with no extra data? And maybe we need a section that says when you design a CBOR protocol you should be clear whether it carries a CBOR sequence or a CBOR data item. Maybe say the preferred encoding the CBOR data item because to be similar to JSON where you can’t have loose name/value pairs?
> 
> LL
> 
>> On Feb 24, 2019, at 4:36 AM, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> Hi Laurence,
>> 
>> the construction you describe is different from a CBOR data item:
>> It is a CBOR Sequence.  You piqued me to finally write it up, see below.
>> 
>> More generally speaking, an encoded CBOR data item followed by residual data is a very valid construction, for instance for a piece of metadata tacked on as a header to a binary blob.  CBOR’s self-delimiting is all you need here.
>> The metadata part doesn’t stop to be well-formed by being followed by that binary blob.
>> But of course the whole thing *is* not, but still *has* a well-formed encoded CBOR data item.
>> 
>> Unfortunately, not very many CBOR libraries have an API that allows isolating that metadata header from its residual data.  Maybe it’s worth writing a draft about suggested API functionality as well.  (One other thing that recently came up and is supported by too few CBOR library APIs is using an already encoded CBOR data item during encoding an array, map, or Tag.)
>> 
>> Grüße, Carsten
>> 
>> 
>> Name:		draft-bormann-cbor-sequence
>> Revision:	00
>> Title:		Concise Binary Object Representation (CBOR) Sequences
>> Document date:	2019-02-24
>> Group:		Individual Submission
>> Pages:		8
>> URL:            https://www.ietf.org/internet-drafts/draft-bormann-cbor-sequence-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-bormann-cbor-sequence/
>> Htmlized:       https://tools.ietf.org/html/draft-bormann-cbor-sequence-00
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-bormann-cbor-sequence
>> 
>> 
>> Abstract:
>> This document describes the Concise Binary Object Representation
>> (CBOR) Sequence format and associated media type "application/cbor-
>> seq".  A CBOR Sequence consists of any number of encoded CBOR data
>> items, simply concatenated in sequence.
>> 
>> Structured syntax suffixes for media types allow other media types to
>> build on them and make it explicit that they are built on an existing
>> media type as their foundation.  This specification defines and
>> registers "+cbor-seq" as a structured syntax suffix for CBOR
>> Sequences.
>> 
>> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor