[art] Alternative representation of URIs in YANG

Martin Thomson <mt@lowentropy.net> Mon, 24 November 2025 22:02 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: art@mail2.ietf.org
Delivered-To: art@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 674688FC6F32 for <art@mail2.ietf.org>; Mon, 24 Nov 2025 14:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b="QdpGHO7H"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="mFsEy9qO"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIZ_JHgNyyYq for <art@mail2.ietf.org>; Mon, 24 Nov 2025 14:02:05 -0800 (PST)
Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) (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 mail2.ietf.org (Postfix) with ESMTPS id EBD7E8FC6F2D for <art@ietf.org>; Mon, 24 Nov 2025 14:02:05 -0800 (PST)
Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 9A84C14000CE; Mon, 24 Nov 2025 17:01:59 -0500 (EST)
Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-04.internal (MEProxy); Mon, 24 Nov 2025 17:01:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to; s=fm1; t=1764021719; x= 1764108119; bh=pgdaSnemMkg7/jnk3q0DXGkM23U9/08h5W0PfymXnwo=; b=Q dpGHO7H1BHJPRJ5r2NA/2JXU39TN77Z59Es5UGwq71rYj+3aO7NrqIf1OG8pCThZ 9BMZ9AUjnp7IscBmDvzmZ8FwwdI39T6UH+r4XYitp4PUIrV06yXOm5ep4E7WnoeN 4vcm4nVfMJDuo17MUB2XKoU2oEedzxohwF/bgtIQ8Cks1c/+ERPAwECl3/RVKPGK 1nrC4APPsbGKfYtlHW9dKSO65Uu/Q0bhowEceg+iSY53RRTYGe+tf1RqlIBZGF8Z koX2+BdSEw4qIe0Wa++1IEc6W9Tm1SJeli2X0dU53hIJjFRbKLmm7TpKDBqKQbGw CgTPQ5b27qYgUec/yCKaQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1764021719; x=1764108119; bh=pgdaSnemMkg7/jnk3q0DXGkM23U9 /08h5W0PfymXnwo=; b=mFsEy9qOCTQnS8Nc/OHpn2NH9oUsEX9UJ6BZTU7vLcwU LBAGFoVEfm7AWhtvzZaGVtpIIkjM8+ttpmabm+z8CUQ2DaxAWhhUa8fu3Ik9iu2L 4qM7CCfRMetCrb3hKWccpZlDwMRmOwar5WgqLInK53B98MKNzUcVap7V07EqnbAQ gIcJU8Kzpl9QP5uS90tEmJuNSDsrfUQY/zhbKxiK57ArRf+cRP13cqWE/gxhoYy6 j8PBl1/A6GxqrO/l9QEESq9OyLdBVsaiD6OVH4UuxoUia75Hm0ANlOtq5umQcZsh 5mMfsbrVHLVI7nhH3+9Vw08t/ALc3R3NAzkbjaouUg==
X-ME-Sender: <xms:19UkacD0oCIve97dRT94MmmiuzE01mCq_Y6eyntqAr7vmmsA_0BmWw> <xme:19UkaZWJ-1ZjGnlL7O5DYz9-1J7d1sfwM4xUL0vsKM9wIi4itHrDiwipkFQcB3ZyI H-KNQimATto3nr1m3ZhZF7jyCOTlwGleS7t2BKzKqYfr1p882ajgA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvfeeljeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvvefkufgtgfesthejredtre dttdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptdeitdeugffhvdegffduhfdttd elgfejjeeftdevhffggfekteevvdfhteduffevnecuffhomhgrihhnpehivghtfhdrohhr ghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmth eslhhofigvnhhtrhhophihrdhnvghtpdhnsggprhgtphhtthhopedvpdhmohguvgepshhm thhpohhuthdprhgtphhtthhopegrrhhtsehivghtfhdrohhrghdprhgtphhtthhopehkvg hnthdoihgvthhfseifrghtshgvnhdrnhgvth
X-ME-Proxy: <xmx:19UkaRgnK_8BfkcKpEaNwGEWE13eTYjLNYZPQ1Ka_6O1rg7jUMX4Eg> <xmx:19UkacDUMh2EV-n3WFM7tmyB3WqdSH91ZiEocwmnN8DL8FkA4Yjvhw> <xmx:19UkaesLEu_vB88HYTeKsDPkmZ-FmvFCbCe8_STJ0p0HJ08LEMjl8w> <xmx:19UkaRZ-4u8tj8Kf1ai_l3fDGoUSaOX0p-x9U1lvMB-BEFGulkFaUg> <xmx:19UkaX3Kc82qUcqBHAUow1X4Y-S8zIH-fmoB26rIWy8x-Om43b8qXCdn>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id 2BCFC78006C; Mon, 24 Nov 2025 17:01:59 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
Date: Tue, 25 Nov 2025 09:01:37 +1100
From: Martin Thomson <mt@lowentropy.net>
To: art@ietf.org
Message-Id: <04751771-27b6-4894-81dc-82036aeea5d2@betaapp.fastmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-ID-Hash: QWGDYK6ODNHZDY24MVNQNOGAONRBJPA5
X-Message-ID-Hash: QWGDYK6ODNHZDY24MVNQNOGAONRBJPA5
X-MailFrom: mt@lowentropy.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-art.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Kent Watsen <kent+ietf@watsen.net>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [art] Alternative representation of URIs in YANG
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/kCa9uceIqX2_mtzNNV3zR7aiqC4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Owner: <mailto:art-owner@ietf.org>
List-Post: <mailto:art@ietf.org>
List-Subscribe: <mailto:art-join@ietf.org>
List-Unsubscribe: <mailto:art-leave@ietf.org>

Hi,

I recently had cause to review draft-ietf-netconf-http-client-server and found Section 2 [2] gave me pause.

This section claims to represent URIs with a name of "ietf-uri" for the module.  However, it seems like the only form on offer is a very specific authority form.  This might be sufficient for HTTP URIs, but I doubt it works for SIP, file, or many other URI forms.

Questions:

* I know that decomposition is common when using specific types of URI, but is this a sensible way to represent URIs?  
* Should this instead try for a more limited scope?  Through a different name, perhaps.

Kent, on CC, can likely answer questions about expected usage.

Cheers,
Martin

[2] https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server#section-2