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

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
> 