Re: [Cbor] Interactions of packed CBOR and tags

Brendan Moran <Brendan.Moran@arm.com> Thu, 03 September 2020 11:57 UTC

Return-Path: <Brendan.Moran@arm.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 0ADD63A08AF for <cbor@ietfa.amsl.com>; Thu, 3 Sep 2020 04:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=E1u2xwqO; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=E1u2xwqO
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 sJ8PNPSqBwm1 for <cbor@ietfa.amsl.com>; Thu, 3 Sep 2020 04:57:13 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2069.outbound.protection.outlook.com [40.107.22.69]) (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 1350A3A08AD for <cbor@ietf.org>; Thu, 3 Sep 2020 04:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L/Ke8dNYbYDv3Efovs2gz/DS/Xev2n0mIdL0bF9cadc=; b=E1u2xwqOPLQWGLCBahceG34ZQY0BYBMsbyWctFv6mK2pNuGhI1/tg/gE7/oOVgrRWxf/5Xn+jUP4RwLY+fu3iQp1q3RIZcVLtrUYEqPYKVf1B7xHwrxhDt8Qzqk1KYCBwtJpScy9VuGd8Br8MS5dJyxEwruIjKaurzD1E6sNuco=
Received: from DB6PR0201CA0011.eurprd02.prod.outlook.com (2603:10a6:4:3f::21) by VI1PR08MB4208.eurprd08.prod.outlook.com (2603:10a6:803:ec::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15; Thu, 3 Sep 2020 11:57:09 +0000
Received: from DB5EUR03FT029.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:3f:cafe::9e) by DB6PR0201CA0011.outlook.office365.com (2603:10a6:4:3f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15 via Frontend Transport; Thu, 3 Sep 2020 11:57:09 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT029.mail.protection.outlook.com (10.152.20.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Thu, 3 Sep 2020 11:57:09 +0000
Received: ("Tessian outbound bac899b43a54:v64"); Thu, 03 Sep 2020 11:57:09 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 753ab1577c542273
X-CR-MTA-TID: 64aa7808
Received: from 9f14d46ee41b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 0C52F68C-38D2-46B1-81C4-7869B05A83E6.1; Thu, 03 Sep 2020 11:56:32 +0000
Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9f14d46ee41b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 03 Sep 2020 11:56:32 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nIfP0Qc+2doGfT4H7kTvthD78xvCL5gYLfyecciJXOrernfpwoO1V6VYJLS6o/z3qTfL+T8tyn2vTo10XKowrkmPTEo6Ou1hA/3yxWFThf2ZpUii5kAZyODoOzZ5w0Q3cR+KCkJvQv1JGntfgc70dTCSZGq9fkrYlYiLChQ9BTLZqYlAN2oNhIUhNrtWzi6RNYLZ0qf1GP66vyfpvSGiYZl2YxpMv4PYDTUkf+ZlCrw6ihDgTklLMbc9I0opNy2TCNHX5aEtWnhkz6O+4eebcBk151W2+odUSwcChFXIQCzE/MwrVzse0TAEeGUBRfU1h2zI/hjfJXD6kgDZ3eUEvA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L/Ke8dNYbYDv3Efovs2gz/DS/Xev2n0mIdL0bF9cadc=; b=Fuq1QopQkn6ZaKFPCOcrN4NQE29FvXcATttGF8uIEHgGNyMgVe77Xv5tAgN+UrpfgTrjCk7PjMqT5+LL1P9H3osHKE9tahbvD1esDhNgSIqfdKlERjsoH7C5D7DJIn7AU5w+uiBS4bBAH/a6FLui4YDyEn5GTAJvP5ngNkwqwjZC0/pRCUBko7nhQ23/yA0oAB7sFhP3dML8yT0XPgjSsTWNsOdgpt9HNhm3vkj/BVIEM9RDr3bzl8oJcgnYbDxrs9TIQUKWZvCSXLPjtza46NBYIwbB2xXQ2rHZFee19gAVlbqx8B04bFq6LED6AERl+GWLLAqmceiWAWv0ySQNGA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L/Ke8dNYbYDv3Efovs2gz/DS/Xev2n0mIdL0bF9cadc=; b=E1u2xwqOPLQWGLCBahceG34ZQY0BYBMsbyWctFv6mK2pNuGhI1/tg/gE7/oOVgrRWxf/5Xn+jUP4RwLY+fu3iQp1q3RIZcVLtrUYEqPYKVf1B7xHwrxhDt8Qzqk1KYCBwtJpScy9VuGd8Br8MS5dJyxEwruIjKaurzD1E6sNuco=
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM6PR08MB3304.eurprd08.prod.outlook.com (2603:10a6:209:49::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.16; Thu, 3 Sep 2020 11:56:30 +0000
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56%3]) with mapi id 15.20.3348.016; Thu, 3 Sep 2020 11:56:30 +0000
From: Brendan Moran <Brendan.Moran@arm.com>
To: Jim Schaad <ietf@augustcellars.com>
CC: Carsten Bormann <cabo@tzi.org>, "cbor@ietf.org" <cbor@ietf.org>
Thread-Topic: [Cbor] Interactions of packed CBOR and tags
Thread-Index: AdZ8s0xpKERBvw7yTZyxz2a31flriAABj4uAAAP6fwABR/KiAA==
Date: Thu, 3 Sep 2020 11:56:30 +0000
Message-ID: <4AE9B2FA-EEB3-4B45-96E4-9DC85118567D@arm.com>
References: <00c101d67cb5$2588b790$709a26b0$@augustcellars.com> <E30F54B6-1A63-48AC-89AE-61983654B5A9@tzi.org> <00cc01d67cc9$766c7b60$63457220$@augustcellars.com>
In-Reply-To: <00cc01d67cc9$766c7b60$63457220$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.1)
Authentication-Results-Original: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=arm.com;
x-originating-ip: [217.140.106.49]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: f8f52d76-965a-42f7-2451-08d850007cc6
x-ms-traffictypediagnostic: AM6PR08MB3304:|VI1PR08MB4208:
X-Microsoft-Antispam-PRVS: <VI1PR08MB420882DF6AD4207AC4AEE304EA2C0@VI1PR08MB4208.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:7691;OLM:8882;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: ogo3+ougzNsmIGFGMObkvwTGXSsgHciw6Z2u7SnNe1ZHxGhJgcSBFVMjP3ldyD2vIuMGqQxgYrRaL+pXWSvShO//4RcDOY5btnAuxDKjyQjaWPtcLbZPnAF5eEszXkwjJbQWrRSooIWIq5vLfVexB+zJHDbsniJugGY7V1tROT7OdqZoTMs+PJYMzTc4zukFohGenRUPMgOU+SFPvwyC7fX+7YLHvhQ5oxtAGe4JrZkiGqjFJF85ZIV2/aiJJozb8KJJx7FoAPurv23gCJ89QFocQTgONrd/EgdvHLRuutrtQMBoxny6NtSLDM0FjsSTXlafQ//3Eomibrg+iG3nPaGt9Xy3Z6Ki0IlIVSwd5c3hAKFyVnKcltPlaQYA4La4Dszv+1Q4tvdyZgU3znFRIQ==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(376002)(136003)(396003)(39860400002)(6916009)(66476007)(66556008)(76116006)(66446008)(91956017)(5660300002)(66946007)(26005)(186003)(6506007)(53546011)(8936002)(4326008)(2906002)(6486002)(54906003)(966005)(8676002)(478600001)(64756008)(71200400001)(33656002)(86362001)(6512007)(2616005)(316002)(83380400001)(36756003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: ho7JNxAwugTbGSbtjFyVJ8Jp3Oc3BTCxGIS9f1yEffM7j+OcBJ2i/u+dzll4XoyRX7k1nzU/FeXsc8cNpnrDlWnIjgVt/MQ+ry9ft2ZzIoGxjvgVI7zAoCgiBaVUTPjYpQc1ytpVEuY++jsvJQNZ5eAHIyZBx7SRmN1K4t9mkU+xuYICMGGNLrVkZ0/hTt4F0wyTraVw0m3qQsT+GJrkna72FZuB0EGsHSK9OJYT6GWDP14j4KJwBy6aKGjmxvU1J8w1XbitqVClkg7JW+iwUV9Udbe4L2xLwqi/bXfmaKavjVz4Ar4I2bAAvZ2RUpJsTeSDAxBRgXJB3DFtUJhhuZbFb4Ph1gdNsZuqHrp1ZJ/AScGV0nQOjWmYjNy6f7lyYESEVIFk0knFOLmFVaFT1B/WBu9feZ7aDycHsKSarzWJiLqj7TKMHTmNcBVgkj2ZkflUev6f0T3TiP5vPge1E2nXIfBGJaMOjptFShTwPKUbF1QeTjjNofs+GCq3GeLBakXkASRBKV5yFYq/JGobq6x2m5WCme/pOSU3Ugq+f5TlvcUZRTZSnRJq3zY4b0xIqrUsJVWRXFXL/7sfQPhatPeusX0Bt01BLN4a47Cw7a4cMxnctyCDoP1a+mTaGKAPZPxFM3QdPrEsH5ZBoRYkQA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E23BDA2EBDC20A4BA7B90D845F03A655@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3304
Original-Authentication-Results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT029.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: a45a7c75-fdd0-44cb-fcf5-08d850006543
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: sJETY3sH5Rnz1XFgjYMaXzBn67fxkn2YxO7pkuZw0qDdG8JucggmKj041opHaRX8AxJxX4PGqBbzxEmJvBKLByBO6r76g2yx7PDnhq9ewoM8lV0a+BXVknYIL+kKshk12R9R8VR29brHzJ81ozZh8KMv7mxWkBPmMBC6YX3HCeCd1ifGgBKGxhx0JE1P1HjRzNHgLEgspl9oOSZYTO2QEOrJGoYvtfGZk3j9a7mK1UAJ6JQOW/5q2nhqqJ34AfU8DEA9oGDWUZnxiQqNsQhkbJxiINsf6ygTjdU0KSgGGmqeJme0PcYt/4Tq6gaIFDGgR32Ui0uSwV/Fcavfs4nkL8k7xxsz/MEjB/bnSRApylkG9i3ooOC4FyNRzwvUk0Mi4GhyfCPRowSO32WPtiJPUQ6u9D06+jWxGzGvZA6diGwdCazFZyFYzbr8Z8ha0XXZuX2HI0kkfmgdCZ3OmcSGTr6triPGZGeZDjujb2vyWpY=
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(346002)(39860400002)(46966005)(6512007)(47076004)(5660300002)(6486002)(33656002)(82740400003)(2906002)(83380400001)(70586007)(70206006)(356005)(86362001)(81166007)(186003)(966005)(8936002)(478600001)(82310400003)(36756003)(2616005)(8676002)(54906003)(336012)(53546011)(26005)(316002)(6506007)(4326008)(6862004); DIR:OUT; SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2020 11:57:09.6427 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f8f52d76-965a-42f7-2451-08d850007cc6
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT029.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4208
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/XxhQRNgtKHhnPuQS6u80Frc9O6w>
Subject: Re: [Cbor] Interactions of packed CBOR and tags
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: Thu, 03 Sep 2020 11:57:16 -0000

I’m not certain whether this overlaps or not, but I think it does. There’s a limitation in the current specification of packed cbor: Only text prefixes and singular CBOR elements can be packed. This may not seem like a big limitation at first, however I think that there are some missed opportunities here.

I’ll use CIRIs (https://tools.ietf.org/html/draft-hartke-t2trg-ciri-01) as an example. I realise they may not be “representative” but they illustrate two observations I’ve made about packed CBOR:

1. Some things need postfix sharing rather than prefix sharing. Domain names are the primary example of this. Because subdomains are prepended, rather than appended like the rest of the URI path, they need postfix sharing, assuming that the TLD has lowest entropy and the subdomains have the highest entropy in a given structure.

2. Packing sub-sequences of elements within containers is something that we should consider.


For example, suppose that I need to many CIRIs that represent, for example, the following URIs:

https://www.ietf.org
http://www.ietf.org
https://datatracker.ietf.org/group/cbor/about/
https://datatracker.ietf.org/doc/draft-bormann-cbor-packed/

Encoded as CIRIs and arranged into an array, these URIs take up 161 bytes (N.B. it would only be 151 bytes for the raw URIs)
[
  [1,"https", 2, "www.ietf.org"],
  [1,"http", 2, "www.ietf.org"],
  [1,"https", 2, "datatracker.ietf.org", 5, 0, 6, "group", 6, "cbor", 6, "about"],
  [1,"https", 2, "datatracker.ietf.org", 5, 0, 6, "doc", 6, "draft-bormann-cbor-packed"]
]

If I wanted to pack this structure, I think the result would look something like this:

Naive (127 bytes, 78% compression ratio):
6([
  [
    [1, 6("s"), 2, simple(0)],
    [1, 6(""), 2, simple(0)],
    [1, 6("s"), 2, simple(1), 5, 0, 6, "group", 6, "cbor", 6, "about"],
    [1, 6("s"), 2, simple(1), 5, 0, 6, "doc", 6, "draft-bormann-cbor-packed"]
  ],
  [
    "http"
  ],
  "www.ietf.org",
  "datatracker.ietf.org"
])

Better (124 bytes, 77% compression ratio):
6([
  [
    [1, simple(1), 2, simple(2)],
    [1, simple(0), 2, simple(2)],
    [1, simple(1), 2, simple(3), 5, 0, 6, "group", 6, "cbor", 6, "about"],
    [1, simple(1), 2, simple(3), 5, 0, 6, "doc", 6, "draft-bormann-cbor-packed"]
  ],
  [
    simple(0)
  ],
  "http",
  6("s"),
  "www.ietf.org",
  "datatracker.ietf.org"
])

I think we can do a bit better, but it’s convoluted… (122 bytes, 76% compression ratio):
6([
  [
    [1, simple(1), 2, simple(3)],
    [1, simple(0), 2, simple(3)],
    [1, simple(1), 2, simple(4), 5, 0, 6, "group", 6, "cbor", 6, "about"],
    [1, simple(1), 2, simple(4), 5, 0, 6, "doc", 6, "draft-bormann-cbor-packed"]
  ],
  [
    simple(0),
    "www",
    "datatracker"
  ],
  "http",
  6("s"),
  ".ietf.org",
  224(simple(2)),
  225(simple(2))
])



Back to the observations I made above.

1. Compressing the domain names doesn’t work very well. Maybe this is unique to domain names, but I think we need more data on that.
2. There’s a lot of regularity left here, but it’s all in the form of sequences of array elements. For example, the sequence [1, simple(1), 2] shows up regularly, as does [simple(4), 5, 0 , 6].


Here’s where I think the discussion overlaps. Enabling packing of sequences of elements would require one of three changes:

1. Only indefinite-length containers can have packed items.
2. The container count refers to unpacked count, which makes the packed CBOR invalid.
3. The container count refers to packed count, which means the decoder must adjust the total whenever a reference is encountered. This has additional implications for maps.

If it turns out that postfix sharing of data really is unique to domain names and that the problem isn’t generic, maybe we could solve it another way, for example special handling of anything within Tag 32. Sequence packing, however, is a space where I think we need a solution.

Brendan

> On 28 Aug 2020, at 00:26, Jim Schaad <ietf@augustcellars.com> wrote:
>
>
>
> -----Original Message-----
> From: Carsten Bormann <cabo@tzi.org>
> Sent: Thursday, August 27, 2020 2:32 PM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: draft-bormann-cbor-packed@ietf.org; cbor@ietf.org
> Subject: Re: [Cbor] Interactions of packed CBOR and tags
>
>
>
>> On 2020-08-27, at 23:00, Jim Schaad <ietf@augustcellars.com> wrote:
>>
>> While building a test library of strings for evaluating my algorithm,
>> I ended up with a question of how tags interact with the idea of CBOR packing.
>> Specifically, if I use a standard date/time string with tag 0, should
>> that text string be considered as a candidate for packing?
>>
>> 0("1970-01-01T00:00Z") could potentially be compressed to 0(simple(3))
>>
>> The problem is that this is no longer a valid CBOR encoding so it
>> would not seem to be a legal thing to do.
>>
>> Question:  Must packed CBOR be valid CBOR or does that requirement
>> only apply to unpacked CBOR?
>
> Great question.
>
> The cop-out could be: either.
> Since CBOR-valid packed CBOR is a subset of (just well-formed) packed CBOR, it could be a parameter given to the compressor whether that is allowed to use compression opportunities like the above or not.
>
> What are the benefits/drawbacks:
>
> * (just well-formed) packed CBOR may lead to trouble with a generic decoder that cannot handle (present to the application) invalid constructs like 0(simple(3)).
> The application can decide whether it wants to live with this limitation or not.
>
> * the structural coherence of the packed structure (that this draft is about) will be expressed as a validity constraint.  It is a bit weird to then relax validity of what goes in there, but not entirely without precedent (e.g., tag 24, even though there is a more explicit firewall here).
>
> * not using those compression opportunities can be wasteful, not just for the example given above (tag 0), but also for tags like 32.
>
> I think I would emphasize the (just well-formed) packed CBOR, but still introduce CBOR-valid packed CBOR as a selectable additional constraint for applications that need to work with pre-packed (designed before packed was invented) generic decoders.
>
> [JLS] Yes I agree that only requiring that the result be well-formed makes the most sense.  It probably makes sense to discuss the implications in the document.  A more interesting case might be tag 26 which could have duplicate or prefix lines of text coming up frequently.
>
> I think it might make sense to reference tag 25 and say that this does the same thing only much better.
> [/JLS]
>
> Do we need to encode this selection?  (E.g., via different top-level tags.)  Probably not.
>
> [JLS] I don't think that there needs to be different top-level tags.
>
> Jim
>
>
> Grüße, Carsten
>
>
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.