Re: [Cbor] Review of draft-ietf-cbor-packed-02

Russ Housley <housley@vigilsec.com> Mon, 15 March 2021 22:18 UTC

Return-Path: <housley@vigilsec.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 525163A1100 for <cbor@ietfa.amsl.com>; Mon, 15 Mar 2021 15:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 rSsseeLeZI4L for <cbor@ietfa.amsl.com>; Mon, 15 Mar 2021 15:18:24 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D723A10FE for <cbor@ietf.org>; Mon, 15 Mar 2021 15:18:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6BC38300B8F for <cbor@ietf.org>; Mon, 15 Mar 2021 18:18:22 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ma3dI3Gjrh2Y for <cbor@ietf.org>; Mon, 15 Mar 2021 18:18:21 -0400 (EDT)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id F0C1E300259; Mon, 15 Mar 2021 18:18:20 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <7BB8857D-1212-4AD7-B3E7-0416C8248290@tzi.org>
Date: Mon, 15 Mar 2021 18:18:21 -0400
Cc: cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <94F95A0D-4EAF-4015-8EBA-55A705193F6F@vigilsec.com>
References: <3835E637-85A1-44B3-812D-FD6A80EE8473@vigilsec.com> <08DB2CF6-21D7-4EE6-85C7-1E73416D1A70@tzi.org> <0C959B3D-462F-4872-A8AA-12F9C90FD425@vigilsec.com> <7BB8857D-1212-4AD7-B3E7-0416C8248290@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/JganVcJunWdHnGVKq6W2Yf7LEbk>
Subject: Re: [Cbor] Review of draft-ietf-cbor-packed-02
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, 15 Mar 2021 22:18:26 -0000


> On Mar 15, 2021, at 4:33 PM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> On 2021-03-15, at 19:40, Russ Housley <housley@vigilsec.com> wrote:
>> 
>> I felt this point of divergence from the original design goal needed explicit discussion.
>> 
>> I'm not sure what the right answer might be.  Maybe some preamble to say that a named table is needed for successfully recovering the entire content. In the current document, this context is assumed.
> 
> I added to PR#2:
> 
>> * By the application environment, e.g., a media type.  These can
>>   define tables that amount to a static dictionary that can be used in
>>   a CBOR data item for this application environment.
>> +  Note that, without this information, a data item that uses such a
>> +  static dictionary can be decoded at the CBOR level, but not fully
>> +  unpacked.
>> +  The table setup mechanisms provided by this document are defined in
>> +  such a way that an unpacker can at least recognize if this is the
>> +  case.
>> 
>> * By one or more tags enclosing the packed content.
> […]
> 
> I’m not sure that this fully addresses your comment, but I agree that it is important to make this point.


Not completely.  It mkes it clear that the unpack will know that it has an unknown table index.  That is good.  Should there be an explicit identifier of the predefined starting point for the tables?

Russ