Feedback-ID: ie6694242:Fastmail
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <D7A3B7FB-0284-4DCF-B840-8114860A0FDD@gmail.com>
Date: Sat, 24 Jan 2026 10:16:57 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <802512BC-D897-40DE-A79F-ACB6E8921DA7@mnot.net>
References: <87zf669z4x.fsf@hobgoblin.ariadne.com>
 <0100019be639037e-5401829e-3666-454e-b2c1-e9ac65a04ac5-000000@email.amazonses.com>
 <e1356eb8-31ba-47ce-9a1f-8d42713184a9@betaapp.fastmail.com>
 <263D72B1-54D9-47BA-9787-8A3F3889A6ED@gmail.com>
 <f5bjyx8y0v0.fsf@lochinver.inf.ed.ac.uk>
 <D7A3B7FB-0284-4DCF-B840-8114860A0FDD@gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-ID-Hash: MCUSUPU7DNELXKXBJMPSBPMVYAJVYAKY
CC: "Henry S. Thompson" <ht@inf.ed.ac.uk>, Martin Thomson <mt@lowentropy.net>,
 Kent Watsen <kent+ietf@watsen.net>, "Dale R. Worley" <worley@ariadne.com>,
 tom petch <ietfa@btconnect.com>, art@ietf.org, "uri@w3.org" <uri@w3.org>,
 uri-review@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bart=5D_Re=3A_=5BUri-review=5D_Re=3A_Alternative_representation_?=
	=?utf-8?q?of_URIs_in_YANG?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/art/H0UMcXdsTnevFA0IkiG8y5n9pOM>

I understand that from a YANG perspective the focus is on getting =
something configured. However, what's being talked about here is =
creating a protocol artefact that claims to be "ietf-uri" -- i.e., =
something that the whole IETF community considers to be a good way to =
convey a URI -- and yet there is clear and consistent feedback from the =
relevant expert community that what is described is not an appropriate =
construct.=20

As has been pointed out by others, handling and comparing URIs requires =
a _lot_ of subtlety, compounded by the many different syntactic options =
that they offer. It's not at all clear that this structure has been =
thought through with reference to how it will be used -- hence the =
nervousness you're hearing from the URI expert community.

Furthermore, if something is called "ietf-uri", it is likely to be =
reused in other situations where the constraints you have in mind are no =
longer applicable.=20

So the fairly strong advice you're getting is to either:

a. Just use a string, per MT (preferred)
b. Rename to something *much* more specific to your use case

Cheers,


> On 24 Jan 2026, at 9:56=E2=80=AFam, Mahesh Jethanandani =
<mjethanandani@gmail.com> wrote:
>=20
> Hi Henry,
>=20
> Can you provide a specific example of how the current definition of =
'ietf-uri=E2=80=99 in YANG does not meet the requirements of configuring =
HTTP?
>=20
> Thanks.
>=20
>> On Jan 23, 2026, at 4:22 AM, Henry S. Thompson <ht@inf.ed.ac.uk> =
wrote:
>>=20
>> Mahesh Jethanandani writes:
>>=20
>>> How about we go with option 2 that limits the applicability of the =
definition to the following:
>>>=20
>>> The 'ietf-url' module defines a YANG 'grouping' for a URL described =
as a
>>> constrained subset of the URI defined in <relref section=3D"3" =
target=3D"RFC3986"/>.
>>=20
>> Just changing the 'i' to a 'u' doesn't change the fact that it's no
>> longer a UR[IL] if it's restricted to 'HTTP', so IMHO it's still
>> misleading.
>>=20
>> ht
>=20
>=20
> Mahesh Jethanandani
> mjethanandani@gmail.com
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> art mailing list -- art@ietf.org
> To unsubscribe send an email to art-leave@ietf.org

--
Mark Nottingham   https://www.mnot.net/