[Cbor] Re: [Tools-discuss] [abnf-discuss] Re: [art] Re: Exploring ABNF extracts from RFCs

Dave Crocker <dcrocker@gmail.com> Mon, 29 July 2024 15:00 UTC

Return-Path: <dcrocker@gmail.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 7B67EC1840DB; Mon, 29 Jul 2024 08:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2B0vB5spBVfR; Mon, 29 Jul 2024 08:00:42 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8654C180B7E; Mon, 29 Jul 2024 08:00:36 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-70d1a74a43bso2146651b3a.1; Mon, 29 Jul 2024 08:00:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722265236; x=1722870036; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Xph4CXXEf/wbriGPaNGNnl3sIVRX4w+ertI+MZW04kE=; b=bzvgdp2PCXABaX8nkkOcW49zsP+B25qyUe/99SaVv8KrPQmOGz/wUEDrG8TPAag45g K12VCbqrD5zBSShTiWNFDwxRfW4Pv4qKASx7SJIpdMiG2L8p203BZkQrDPldZHJX3w71 R53NTCVC+qXghZtJ8CGAoHxZ4xAOO7pFVtHPGL/MD+IdfvwXA7Ym2mevp7rcfbmcX9Pg ksz4oaTUk/H9P1oAW9+/W+UpWiEim7OPV2HJjbCoasZQk8xbIiRy67/cVEmCTBMmjOlh 6bhh8oLgK0k2W+i9OXbYwzleP6bE+F0mniWV3FOgrFzxsUeET6s4IFakfLajaHM4jzN1 LJYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722265236; x=1722870036; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Xph4CXXEf/wbriGPaNGNnl3sIVRX4w+ertI+MZW04kE=; b=HZUAxurPvBrYwFFBrP4YiSBVAyE5g2maS9BS6zxVbvhuoxallXR9nm8dLWSBUBZql7 TUJ4Z2EtCPzvs52UpxyVg7bTw8wvzPKenlhjvFmbZBOXjgaWFKqopI6KvRxRkQzyeRVF AP9Pvcaep8Rs+HuPmqNGVoru2+cqLJAq5tZ7mw8KWO7Y/cWQFZ1LpFi2f4cH7E0Hd/1y y3NeVJCZglNAW2AlN6g3Q3DGLWHRQn51wnRg6ZJTqehSiYwA9O14VGJI1aVLuC/lKrWt fRWVweVwlAwJeTQ9oqf/oFnpnxYkWB4Z1m2q1hdF3pCmflP5b9nb4v0cTfruOBgTIKY0 RUHA==
X-Forwarded-Encrypted: i=1; AJvYcCV3mfWyl+zuWwm0k4/nNLzhDuVli2Coy8d8mxERVK+V1E6c8L3HKpcSvXIhA4GvCOuUDRfQc7K3X9Smmjd7cmmgTSXtmQYkNjuyLvna8zOXH+UfZTnkXqarQ5B13dzFKluUdqZK64K/xxF2YcOxK/NFmEEeO05mqQxS0g==
X-Gm-Message-State: AOJu0YykmdK36O5IhGavP4IAegImL7y9O6FEEpooeiZzxsEtxxzZQvhz uvj7r4Yh3B4TY0C22Zrm6GW+6564ww34sG7qX7hHWKBWZYDK8x06Eh6Sc/9P
X-Google-Smtp-Source: AGHT+IFEvcU1yT4ynTsztIsPGVgYsMkttg5wDp5/nMbvxSxGQRieb02NeLeMsiDQrNyf85HfyXFTYA==
X-Received: by 2002:a05:6a00:1881:b0:70e:98e3:1b9d with SMTP id d2e1a72fcca58-70ecea2ef98mr6314398b3a.18.1722265235555; Mon, 29 Jul 2024 08:00:35 -0700 (PDT)
Received: from [192.168.68.53] (c-98-42-225-165.hsd1.ca.comcast.net. [98.42.225.165]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70ead712f25sm6876647b3a.81.2024.07.29.08.00.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jul 2024 08:00:35 -0700 (PDT)
Message-ID: <5f0ada79-2520-4460-a558-919b40943cdc@gmail.com>
Date: Mon, 29 Jul 2024 07:59:55 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Carsten Bormann <cabo@tzi.org>
References: <89a4a566-8ffe-413e-9196-3f08bebe8d20@w3.org> <99E8B992-AF60-4CD6-9786-2EC180E95E4D@tzi.org> <2867abac-8c62-41b2-a20c-cb9fe8d3736d@alum.mit.edu> <ff29ebe0-efbc-4bfc-8c79-f09ccbe3ffe3@w3.org> <b864092b-477b-4866-a2b1-481313545917@alum.mit.edu> <da4c5ded-24dc-46c8-b011-cea627107f19@gmail.com> <99B795A8-DC51-409A-8395-A0CD5E5C24BF@tzi.org>
From: Dave Crocker <dcrocker@gmail.com>
In-Reply-To: <99B795A8-DC51-409A-8395-A0CD5E5C24BF@tzi.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: PSHOPZBTINJIZEX5MSP24EXL3UPQ3WAH
X-Message-ID-Hash: PSHOPZBTINJIZEX5MSP24EXL3UPQ3WAH
X-MailFrom: dcrocker@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cbor.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Paul Kyzivat <pkyzivat@alum.mit.edu>, Dominique Hazael-Massieux <dom@w3.org>, art@ietf.org, tools-discuss <tools-discuss@ietf.org>, CBOR <cbor@ietf.org>, abnf-discuss@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Cbor] Re: [Tools-discuss] [abnf-discuss] Re: [art] Re: Exploring ABNF extracts from RFCs
List-Id: "Concise Binary Object Representation (CBOR)" <cbor.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/Nmapw5sB0Fqh3UMq5pOXrQJ4JYo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Owner: <mailto:cbor-owner@ietf.org>
List-Post: <mailto:cbor@ietf.org>
List-Subscribe: <mailto:cbor-join@ietf.org>
List-Unsubscribe: <mailto:cbor-leave@ietf.org>

On 7/29/2024 7:54 AM, Carsten Bormann wrote:
> On 2024-07-29, at 16:47, Dave Crocker <dcrocker@gmail.com> wrote:
>> As for namespaces, something like organization-document probably suffice to take care of the global uniqueness part.  So, for example, ietf-rfc-nnn-…
> Generally, it is advantageous to separate the document reference (which may need to carry a lot of information to properly select the document, its revision, provenance, ...) from how the referenced item is used in the actual specification.
>
> So in CDDL, we do something like
>
>     ;# import cose.label, cose.values from rfc9052 as cose
>
> Which makes cose.label (cose--label when using ABNF name characters only) the rule name to be used in the CDDL (ABNF) and keeps the detailed document reference (in this example rfc9052) in the import statement, which acts as the glue.

Unless I'm misreading, I think we are agreeing on the major point I was 
making, although differing on what I think is an important detail.

Your example uses rfc9052 as the external reference.  Mine is meant to 
allow more variation in source and indentification of publication.  An I 
meant the ellipsis in my example to refer to lower-level detail withn 
the document.

Your 'as' construct is interesting.  I hadn't thought about mapping 
between rule names.  fwiw, it makes me uncomfortable, though I 
understand the motivation and possibly even the need...

d/


-- 
Dave Crocker
dcrocker@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791

Volunteer, Silicon Valley Chapter
Northern California Coastal Region
Information & Planning Coordinator
American Red Cross
dave.crocker2@redcross.org