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

Felipe Gasper <felipe@felipegasper.com> Mon, 01 July 2019 11:11 UTC

Return-Path: <felipe@felipegasper.com>
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 9E84A120220; Mon, 1 Jul 2019 04:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=felipegasper.com
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 XYaiw-bk4ur2; Mon, 1 Jul 2019 04:11:09 -0700 (PDT)
Received: from web1.siteocity.com (web1.siteocity.com [67.227.147.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D67612008A; Mon, 1 Jul 2019 04:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=felipegasper.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+8jbLU9057dv9V1kQ9bmwRjaZfTWUvgrEIhHD+rMqNE=; b=Mh29IkSsSjehD9CyN8p/zaMzO sxHTfqP8PU/+SuPyjqPRmHTTUEv61gBMKIi1AmVueujO4DUe9XwII73GA3+hIPWZl/oGqGhvwHjlv K96/FbgJPeh9xs/50iBCz4pBN/xjzr66LgCrb9wW8J4S9EV4jl6uvkRzePKlXvUGaK85GiHTKjMVJ uketrC9jx0II68bBTDPSKuhcNf5kdoDoaKdNBHYankzuAWsshpDpkqwl40cNlsXxrEbaxeLpxMJYy +eKqWtXn1Uz7d0fkLbMk0n5kFVKisGzSBmNEYHcWZcx4uDuj0ppfTGFDWRRYk0wmMv6YxlewxQimT wL9kAn5Tg==;
Received: from [149.248.87.38] (port=50212 helo=felipes-mbp.lan) by web1.siteocity.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <felipe@felipegasper.com>) id 1hhuDB-009kGD-Rl; Mon, 01 Jul 2019 06:11:06 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Felipe Gasper <felipe@felipegasper.com>
In-Reply-To: <0eb801d52faa$f118fc70$d34af550$@augustcellars.com>
Date: Mon, 1 Jul 2019 07:11:05 -0400
Cc: draft-bormann-cbor-sequence@ietf.org, cbor@ietf.org, Carsten Bormann <cabo@tzi.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B5D53CC-0450-4D05-9632-6F31C17E9E74@felipegasper.com>
References: <01f201d50ac9$d6b1abd0$84150370$@augustcellars.com> <CA0F439A-A578-4AE5-9E05-1277FF949997@tzi.org> <0e8901d52f6c$08291060$187b3120$@augustcellars.com> <4AF53D16-C6AE-4D53-9A3A-DF442D827D86@felipegasper.com> <0eb801d52faa$f118fc70$d34af550$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web1.siteocity.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - felipegasper.com
X-Get-Message-Sender-Via: web1.siteocity.com: authenticated_id: fgasper/from_h
X-Authenticated-Sender: web1.siteocity.com: felipe@felipegasper.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/2exeWj7RFtNgj9nhxBbNktBfXeo>
Subject: Re: [Cbor] Review of draft-bormann-cbor-sequence
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: Mon, 01 Jul 2019 11:11:11 -0000

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
>