[Cbor] Fwd: Limits of .feature and JC<> generic for CBOR/JSON

Laurence Lundblade <lgl@island-resort.com> Mon, 24 October 2022 19:42 UTC

Return-Path: <lgl@island-resort.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 1C01AC1522DD for <cbor@ietfa.amsl.com>; Mon, 24 Oct 2022 12:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS2Jy_T4fOLZ for <cbor@ietfa.amsl.com>; Mon, 24 Oct 2022 12:42:08 -0700 (PDT)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2121.outbound.protection.outlook.com [40.107.243.121]) (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 3509CC14F743 for <cbor@ietf.org>; Mon, 24 Oct 2022 12:42:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ohoi2jJtVQvQ6xl0+flCRV62O9v/HrzpVa3ENsyhctbOpNgIhwQTaLpJZFM8EpPF5iV0iw8YemQ22OxshY7gpUk3Gff+NRzztT0w3I3URwUsAuL4TnF70LPOZqlU+04ziy16B433MbFTZEZpv+1Prk3bHoMVCJbEBfy7HmDHROH4QwjKz2w3KhagsRKQP7XETmngG2iLBgvLC1UuYIZhu35Mdi2DOWo8TIQc9fjJXeR89SPS1d0oqUYE1rF/at8Dwpt7bKA43UqJjzne3Q32yf0V2cxuWa6OeX9cqNgup//JfXzDDpyJHDJGIl4jm6hFDOxFpl+sye+it34DVjC7Fg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t1851hfGK5VYhvbLLaiE2LYRyVyV7duGvJUdPtSoRlU=; b=BNQUDPLYHBKhse4X2o4OsJX2QF7sHBrpIre9Wq+rgjMp0UFTEvOzQihI3sOcSxdqrXJZtyh3RAuWZetSdL1kBVmifGsdcyQm/wkrn2q7S9PKvuO8Hvko0hG0qN8fbpqysKwtMGwDjKz80AYDx6PMObDlT7jMNohmEBnn5gR77NyFPzDAADHZYceCtwJYgP9gPyCcgyADVDjyaa9mHWVoK+TkDhj8oCJUbCYX3/U4dTBCEw8EJaFRtTFJuIgxOqcIcJLQM2fDqezjxBRBovuTWcM1A7fKSCEfoW2cV+bNCrxfikrdhIb2VoJUjojlNUe5AxDf40lMQA8m0XmzG4fdeg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=island-resort.com; dmarc=pass action=none header.from=island-resort.com; dkim=pass header.d=island-resort.com; arc=none
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=island-resort.com;
Received: from SJ0PR22MB3094.namprd22.prod.outlook.com (2603:10b6:a03:42b::14) by MW5PR22MB3512.namprd22.prod.outlook.com (2603:10b6:303:1cb::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.33; Mon, 24 Oct 2022 19:42:03 +0000
Received: from SJ0PR22MB3094.namprd22.prod.outlook.com ([fe80::3ea2:f7db:ed72:ba90]) by SJ0PR22MB3094.namprd22.prod.outlook.com ([fe80::3ea2:f7db:ed72:ba90%7]) with mapi id 15.20.5746.025; Mon, 24 Oct 2022 19:42:03 +0000
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_40C0D297-54F9-4AB4-B34E-D4E1A0154DD1"
Date: Mon, 24 Oct 2022 12:42:01 -0700
References: <1C98F19E-65F6-440E-B493-99D469855FB0@island-resort.com>
To: cbor@ietf.org
Message-Id: <93A14DEB-914A-478F-A631-39ECCCB19BE6@island-resort.com>
X-Mailer: Apple Mail (2.3445.104.21)
X-ClientProxiedBy: BYAPR04CA0035.namprd04.prod.outlook.com (2603:10b6:a03:40::48) To SJ0PR22MB3094.namprd22.prod.outlook.com (2603:10b6:a03:42b::14)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ0PR22MB3094:EE_|MW5PR22MB3512:EE_
X-MS-Office365-Filtering-Correlation-Id: 7751248a-d104-4107-f383-08dab5f7d33d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: QaefHxuKk9MnoIpoK5Ideno3JQGWj66RYVM5zs8RdcQGKqJuN1aXvTtBFYVs7wGL6hyMXWQKuuJVrPxnz4nBr9WJ+LsuNzNn1UJ5vhQ7VFX+Qn0ezkF4QpWfAmD/9TM72S+f94DpUVBUXAVeQf10QYQq7DiDZO0tG7FUw5CPuwofWYmwIcgGEbQJB76NNl2mBsWtNz7B9Aud4QyCZMrrxnnRJ7vcx0l2xiFq83TQIq2/XX3pybN2Ko8FapcFJRp2ZNFh/XdsOxumyISkPWAzBmuFMH/YmYeDRKNE7431dwBQAf4Rvtd7DQ12X0tucMlJoikIRBbX7usXsDitZaE8cSLWTDm1efaT1xkcEcf/nqOXNqzk3autkmjKvV2mQUFUYb3xXrq916opEsf2yqTJGsDkClvALMSVu/KQu0xblCQDt4hMQnV9fyMLC5u5yUM1FP8CHIs0LdtmhC4QmiwsT3/VJHW+cINkA4b4Du7D4T9xRXmlEKXzwQE8Pp4ZyM4/6jIxXdi32zoyRyUK0sNaPX+TVGxn5DvrejHUdvOPuvYGpqOm3mHb1ppkD9fdUpPrk3rsxD1ywjLFPeQUNwyBT3BrxbKBkbsz+F3sAm7CGquK0l1tZFATvFFVUJ5pasIY9RZcE0G2OaX7JdmGe0VJJ3eyKVToAh5YFKJYsr1awjCoxSZfG6DyBG6cgBqsda0Frwzi4TVFIcmLSlLzwCqLJpajupFHrh2nCDn3AftE1MqL60B/kOrcqvhc4eJXOyC0XAY43TjiGapTkk2w5Wm+h3dTg2MZjTR21aHhNO/7bAQtTDeSMmDnWffgAhRz5xeBPRum602QOAK88Fze7ZthQjy9CVokWBk8PKQXzVIcB2Q=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR22MB3094.namprd22.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(39830400003)(366004)(346002)(136003)(376002)(396003)(451199015)(33964004)(6506007)(8936002)(5660300002)(186003)(2906002)(66946007)(66476007)(38100700002)(41300700001)(86362001)(33656002)(8676002)(166002)(26005)(36756003)(52116002)(66556008)(38350700002)(6916009)(2616005)(6486002)(478600001)(6512007)(83380400001)(316002)(66899015)(41533002)(142923001)(45980500001); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 4iQvJrb6sQBrNgF/ofbBTYT88+B4YshjnoDYsqTKHs/20kChi8hhUSa5552EAV5z8VBLxB14fmtAyDcBjrniNqWsvUGUNEjB8ECxhHek+Dv2cS30e8xSdy5kpEhjCHW0octVtgM/oIlkiyG8jtuqFBT9PadKAo7CFAK+neL9vsWM4EZ3iyQNJONSz9bruNEYCED4InLu5ydhF5aGgxDLGNecDGgESjXvnb1IBIEZ8cme/QMIRZy9InAUvNr3SywvzlgcB7qznstLuT9SEFK9WCMVs4fyPqR26XS0VL+5U5VPN+sghG9+DBVAE6NPHGZ+h5myz/ltJN+Q2/PnXxD7h4Wnb8ruXX0ble6W+4AWevbRKl9riPPcT4gpoSykkQ4/oHlpVZBllHzRxZ9L/efl1Kmkt7nQ2ew7X+xRZJndq76PSTXJPiVUT4rrEdv3mpMtyOmC6vZD9yRU40IjJDJ7dCq0QrGYAjF/PnuiuVNggLKTUSaBuQ1HyVe/33mVhcVpC9G1UYm+OcucG6D/yJfe74LIle7gFPI7JPIEhbnkF3x68KdgJDFPg8g9xufbhaYhzuVkid3gLFqWBR4Q50QKxg4zGM2HBTNAcWyBzJoraw/8qLwnEtpx4w5nwH5HH7gArXsyz2lcm00+mFBulYb6Ah/KvrL9pAZdnlkvAg6ZT1S7yICgLYiXsKWK6iMIbPiBGpUzMGyB7OY5tbhyXQgxzBTWBtlVVYgXEbV7Rq+q/+3/8cTp/hXH+por+WSlWJ4h5bzSqnzVFLYTupzb1BD4/4E6p2+SUwq1qyQvaeXb+IE5m4vM/ZNw9OTDIr291LKfCxKJJpT8OwnnPb7667CTy8kqM2JiyYW7hhe9IrDOevIU0Q9Gqa2FkntMdJehvYuATqeKBc2ZxmlyriHRLQRtiliIPL3SWmNjxQNyvfWQZAMQzMw/VpbAkxY42VrhcDAo0GJW/RTAnEdcoT/3lOKvWDTKarAXUc9hvuXK2LunWbRTvZ3hJSYTWqMbzbs0XTes7ikmS0u33bfISHnjPc4biY71TveT6eQki0688Aqzw5sHhJNjatFpyqGcPe/7mk8wX4rOszEoOAZHdu6MPaBlPQDjnY3KxIjqbYpCS1tY37atMMrvSkaktmO0hmhfoM7lEpv9XzNcBlGFf8yMwuZ+d0/WskIp/bKYE8yXa3hTXwmmHA7qrdO8vIiyJfIzjuK5fyrJ0Bgbr+VvArt+5EVAZSuS22QoxY0v7+J/Cye2w7pzkG+RrJRXJQ6WFcXRAE6rqa91jvGjQdxCBbzejG14wIUgforFnXsoLoEvLF3NfwmH3DZJmfHHqrsxUYwECPY52ctaOhCut8BZujrouKNqK7EyrW1weLi691CiXPpLlQcReTNoPV1vUCdGwIamtK1WiIiku8F27IFLHBTTiqcP6F+05n3LakVbYYGJR0gvUUFG5x0zP8LQHJY78zDd1HPXlfApbM52OVVi5u/vkf8mrEkP6mEC8Iq9YJfGnlJPY/bStYyGRK8oIuR5S5OkNVj9RdQcb6tY8jeZtUWZlXlXDWziZUTrnwK5W2UCmMdBJPzc6m8WkUCnjbqxeFzKecq0
X-OriginatorOrg: island-resort.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7751248a-d104-4107-f383-08dab5f7d33d
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR22MB3094.namprd22.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2022 19:42:03.4135 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: ad4b5b91-a549-4435-8c42-a30bf94d14a8
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TpGNog/6Tx5ECAqZjmdHMSJPByfDFAyMYFoGE+AnjXYl508Ls+WgkIAYsDj1BuQMVNncs8+oCFqsb2AhjtnfCQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR22MB3512
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/zXxHhlhZVHBXjMig900AQ4b-icc>
Subject: [Cbor] Fwd: Limits of .feature and JC<> generic for CBOR/JSON
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
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, 24 Oct 2022 19:42:10 -0000

I’m mostly just resending this because I saw mention of something like this in the CBOR agenda for IETF 115.

Note also that eat draft-17  <https://datatracker.ietf.org/doc/draft-ietf-rats-eat/>was recently published and is now considered pretty much complete and correct for both JSON and CBOR and for submodules nesting JSON inside CBOR and vice versa.

Seems to me the CDDL in EAT would be simpler and cleaner if we had a more explicit way of switching between serializations than .feature. The problem, as I understanding it, is that .feature is subject to the greedy matching of a PEG.

LL



> Begin forwarded message:
> 
> From: Laurence Lundblade <lgl@island-resort.com>
> Subject: Limits of .feature and JC<> generic for CBOR/JSON
> Date: April 25, 2022 at 12:50:47 PM PDT
> To: cbor@ietf.org
> 
> Here’s an example EAT top level definition that can be either JSON or CBOR to illustrate my point here. I’m just using UCCS and UJCS  here because it makes the example work well:
> 
> EAT = JC<UJCS, UCCS>
> UJCS = Claims-Set ; Unsigned JSON Claims Set
> UCCS = Claims-Set ; Unsigned CBOR Claims Set
> 
> The definition of Claims-Set and JC<> are from UCCS Appendix A <https://datatracker.ietf.org/doc/html/draft-ietf-rats-uccs-02#appendix-A>. 
> 
> The definition of Claims-Set uses the JC<> generic for claim labels and other things that vary between JSON and CBOR.
> 
> If I feed a valid __CBOR__ token into the cddl validation tool with the above CDDL, it will think it’s __JSON__ because the PEG will cause it to match UJCS, not UCCS because there is no difference between the definition of UJCS and UCCS.
> 
> The output diagnostic from the validation will say the input is JSON, which is defnitely not the desired result because the input is correct CBOR. This is happening because the the JSON is first in JC<> and the PEG is greedy. So, what to do?
> 
> (This is a bit of a degenerate case, kept simple to illustrate the issue. In the larger definition of EAT with nested tokens this is not so degenerate)
> 
> My take away is:
> 
> - I need to define the top-level EAT for CBOR separately from JSON, even though they will share most of their actual definition. The JC<> generic won’t work at the top level, even though it works well for labels and such.
> 
> - The use of .feature to separate JSON and CBOR has limitations
>    - Can’t distinguish structures like the above
>    - Results in a lot of diagnostic output — output for every claim label and for many claim values that have to be sorted through manually to determine if the validation succeeded
> 
> 
> Maybe a .serialization control would be better? It binds hard to the serialization type given as the input. The PEG matching rules don’t apply. Any CDDL alternative that is not the same as the input serialization type is entirely disregarded.
> 
> 
> To go a bit further, the input being matched is likely to be entirely CBOR or JSON, not a mix, but there are cases where the input to be matched might be a mix of CBOR and JSON. This happens in EAT when you nest a CBOR token inside a JSON token or vice versa. It only happens at one well-defined point in EAT as arbitrarily mixing serialization formats would be silly and chaotic.
> 
> In EAT when JSON appears in CBOR it is a text string and when CBOR appears in JSON it is also a text string that is b64 encoded.
> 
> I don’t think it is necessary for CDDL validation to deal with this mixed input case. It seems rare and it doesn’t seem necessary to the general function of validation, so it seems like .serialization as I mentioned above is an OK solution.
> 
> LL
> 
> 
> 
>