[Uri-review] Re: [art] Re: Re: Alternative representation of URIs in YANG

[Martin Thomson <[e-mail]>]

On Tue, Jan 27, 2026, at 03:17, Kent Watsen wrote:
> PS: I still don't think the HTTP folks made their case.

What case?

It might be worth stepping back a little here and examining what the fundamental goals are.  Looking at -31 of the draft, the <uri> element is part of the client only.  Apparently, an HTTP client has a single URI that it is fixated on.

That doesn't match my model of an HTTP client at all.  Clients routinely make many requests to different resources, following redirects and making decisions about other requests that might be made.

So, is a client *defined* by the resource that it fetches or interacts with?  Almost certainly not.  Is it instantiated to request a single resource?  That's possible, but not especially useful.  I guess you could use that to model a single invocation of the Fetch API, but I don't think that Fetch is conceived of as a single interaction with the API or that a binding to a single URI is a good fit for the model.

The question I'd like to ask is whether this module needs to define the client in this way.  I see that this element is mandatory, but only for a subset of the URI components that would not be sufficient to construct a functioning HTTPS URI (I can't be sure for other schemes).

What purpose do you see this information serving?

--Martin

p.s., Let's leave aside that fragments are included, but do not play a part in HTTP. That's a distraction.
p.p.s., I can see why you might have rules for a client that constrain what it can talk to, maybe for security reasons (see also Content Security Policy).  That's a very different thing though and also a distraction.