[Cbor] Re: Zone identifiers (issue #62, pr #63)

Carsten Bormann <cabo@tzi.org> Fri, 23 August 2024 16:43 UTC

Return-Path: <cabo@tzi.org>
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 76D32C15106E for <cbor@ietfa.amsl.com>; Fri, 23 Aug 2024 09:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 IXKCA0jCnJF3 for <cbor@ietfa.amsl.com>; Fri, 23 Aug 2024 09:43:50 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A959C15106A for <cbor@ietf.org>; Fri, 23 Aug 2024 09:43:47 -0700 (PDT)
Received: from clients-pool1-0074.vpn.uni-bremen.de (clients-pool1-0074.vpn.uni-bremen.de [134.102.107.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Wr5Vm0BLtzDCd6; Fri, 23 Aug 2024 18:43:43 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <B3BE9433-E043-4DFA-A92C-29034033E55B@cursive.net>
Date: Fri, 23 Aug 2024 18:43:43 +0200
X-Mao-Original-Outgoing-Id: 746124223.633576-38ef2d698820d2a1a38e752103cf456e
Content-Transfer-Encoding: quoted-printable
Message-Id: <49528D65-CE60-4A93-B532-768CA293A5A9@tzi.org>
References: <58569A1E-2580-4C0A-BFE9-DA938DF11FAE@tzi.org> <B3BE9433-E043-4DFA-A92C-29034033E55B@cursive.net>
To: Joe Hildebrand <hildjj@cursive.net>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Message-ID-Hash: VX2T4NO2ZD3YLBY3HJCVT3FEK5FNVHFQ
X-Message-ID-Hash: VX2T4NO2ZD3YLBY3HJCVT3FEK5FNVHFQ
X-MailFrom: cabo@tzi.org
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: CBOR <cbor@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Cbor] Re: Zone identifiers (issue #62, pr #63)
List-Id: "Concise Binary Object Representation (CBOR)" <cbor.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/trdPLXUw--VHxmqpYSbdA2IeczQ>
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 2024-08-23, at 18:21, Joe Hildebrand <hildjj@cursive.net> wrote:
> 
> I see a couple of possible approaches:
> 
> - Explicitly declare zone identifiers out of scope with a small amount of text.  This probably assumes that nobody will need to use EDN to help fix the identified zone identifier problems.

I didn’t make myself clear.
EDN already supports notating CBOR data items zone identifiers.
This document just doesn’t go ahead and picks up any specific additional syntax for that in an application-oriented literal — examples for expressing zone identifiers in EDN are in RFC 9164.

Modulo this point, yes, this is probably the approach we should take.
(I personally think that what we had in #63 is enough, but I’d appreciate additional input.
I just merged #63 so I can do some more editorial work; obviously, we’ll need to continue the discussion on how to address this, so I reopened the auto-closed issue #62.)

> - Pull ip'' app-strings out into a separate doc as an extension to EDN, so that it can proceed at its own pace.

This is a nice example for application-oriented literals being, er, application-oriented, or one could say domain-specific.

In this case we just happen to have people who already have been burned by this domain discourse (which is happening in 6man etc.), so we know that we don’t want to charge ahead with yet another complication.

So no need to wait for anything…

Grüße, Carsten