Re: [Cbor] Review of draft-bormann-cbor-sequence

Given that, as you observe, simple concatenation differs from an indefinite-length array only in the leading/trailing bytes, I still don’t see the use case for a stream of CBOR items that doesn’t indicate either a start or an end. It seems like it would be analogous to WebSocket without a close handshake: what is the advantage, versus having a built-in mechanism that defines the end of the stream?

An advantage of defining sequences as merely a special case of indefinite-length arrays (maybe with a tag) is that an ordinary CBOR encoder and decoder can then parse/encode the stream: either per item if it’s capable, or as a single blob otherwise. The same workflow as for an indefinite-length array—fork off processing per item in the decoder, chunked output in the encoder—will serve the sequence use case.

-F

> On Jul 22, 2019, at 17:15, Sean Leonard <dev+ietf@seantek.com> wrote:
> 
> Basically, I believe it’s because you want to enable simple concatenation semantics to add more stuff to the sequence. A sequence is potentially multiple CBOR items strung together. An indefinite-length CBOR array with a terminating byte is a single CBOR item; it can’t be augmented by streaming more data at the end (then, naturally, the data becomes multiple CBOR items).
> 
> You can turn a CBOR sequence into a single CBOR data item by prepending the array tag of definite length, or prepending the array tag of indefinite length and appending the terminating byte. This is cheap because it’s just part of “initializing” and “finalizing” the decoder. But when the data is coming across ad infinitum on the wire, you never actually want that terminating byte in the data stream. (At the same time, once you get a single CBOR data item, you want to fork off processing of that single data item rather than keeping the top-level decoder running, looking for said terminating byte.)
> 
> Sean
> 
>> On Jul 1, 2019, at 4:11 AM, Felipe Gasper <felipe@felipegasper.com> wrote:
>> 
>> Sorry, I was asking a more general question about the proposed CBOR sequence format rather than engaging your point.
>> 
>> I realize I should have started a new thread--my apologies for the confusion.
>> 
>> I’m just a bit surprised that CBOR sequences are (proposed to be) defined this way. It seems to me that CBOR has no real need for such a standard, precisely because of the indefinite-length arrays that the format itself includes. I would have thought it more logical to define a specific tag that indicates such a structure; thus, a CBOR sequence would itself also be a valid CBOR data object.
>> 
>> Thank you!
>> 
>> -FG
>> 
>>> On Jun 30, 2019, at 9:18 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>>> 
>>> This is the text I was referring to
>>> 
>>> An
>>> implementation may be able to recover from some errors in a sequence
>>> of bytes that is almost, but not entirely a well-formed encoded CBOR
>>> data item.
>>> 
>>> -----Original Message-----
>>> From: CBOR <cbor-bounces@ietf.org> On Behalf Of Felipe Gasper
>>> Sent: Sunday, June 30, 2019 2:56 PM
>>> To: Jim Schaad <ietf@augustcellars.com>
>>> Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org; Carsten Bormann <cabo@tzi.org>
>>> Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence
>>> 
>>> What is the advantage of defining a CBOR data sequence as a simple concatenation versus a tagged CBOR array of indefinite length?
>>> 
>>> Thank you!
>>> 
>>> -FG
>>> 
>>>> On Jun 30, 2019, at 1:48 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>>>> 
>>>> See below.
>>>> 
>>>> -----Original Message-----
>>>> From: Carsten Bormann <cabo@tzi.org>
>>>> Sent: Sunday, June 23, 2019 9:53 AM
>>>> To: Jim Schaad <ietf@augustcellars.com>
>>>> Cc: draft-bormann-cbor-sequence@ietf.org; cbor@ietf.org
>>>> Subject: Re: Review of draft-bormann-cbor-sequence
>>>> 
>>>> Hi Jim,
>>>> 
>>>> except for items 3 and 5 below, where I don’t quite agree, I believe I have addressed all your comments as well as the other items that popped up for -00 in Prague and on the mailing list.
>>>> 
>>>> Please enjoy at:
>>>> 
>>>> Status:   https://datatracker.ietf.org/doc/draft-bormann-cbor-sequence/
>>>> Htmlized: https://tools.ietf.org/html/draft-bormann-cbor-sequence
>>>> Diff2:    https://tools.ietf.org/rfcdiff?url2=draft-bormann-cbor-sequence-01.txt
>>>> 
>>>> Grüße, Carsten
>>>> 
>>>> 
>>>>> On May 15, 2019, at 04:56, Jim Schaad <ietf@augustcellars.com> wrote:
>>>>> 
>>>>> […]
>>>>> 3.  Section 2 - I think that I would remove the parenthesis in the 
>>>>> third paragraph.  This is almost the entire paragraph.
>>>> 
>>>> I believe that is useful information, so I don’t think the parenthesis should be removed.
>>>> 
>>>> [JLS] I am not suggesting that the sentence be removed, just the parenthesis characters.
>>>> 
>>>>> […]
>>>>> 5.  Section 2 - A program, not the decoder, may also be able to 
>>>>> recover by decoding individual fields looking for a pattern that 
>>>>> matches an expected structure.  As an example, looking for a byte 
>>>>> which corresponds to an array of 3 items and then test decoding to 
>>>>> see if it works and continue from that point.
>>>> 
>>>> The specific recovery actions are out of scope (and the text says so).
>>>> I don’t think we should give advice here for diagnostic tools beyond what is needed for a true decoder.
>>>> 
>>>> [JLS] The problem I have with this argument is that you are actually giving an example - should that example then be deleted?
>>>> 
>>>> _______________________________________________
>>>> CBOR mailing list
>>>> CBOR@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/cbor
>>> 
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cbor
>>> 
>> 
>> _______________________________________________
>> CBOR mailing list
>> CBOR@ietf.org
>> https://www.ietf.org/mailman/listinfo/cbor
> 