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

[Kent Watsen <[e-mail]>]

> On Jan 26, 2026, at 7:14 PM, Martin Thomson <[e-mail]> wrote:
> 
> 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?

That the "ietf-uri" structure couldn't encode any URI string.   Dale showed that all the provided examples were encodable.


> 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.

Yes, this has been the data model all along.   This is the case for the entire suite of client-server drafts.  For instance, the "ietf-tcp-client" YANG module configures an IP address and a port.


> 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.

Sure, but there has a be a start point, and that's what's being configured here.


> 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?

The use-case is primarily for programmatic APIs, not browsers.

For instance, the draft-ietf-netconf-http-notif uses this module to configure a router/firewall/switch to send logs to a collector over HTTP.  In this case, the HTTP client truly uses a single URL for the lifetime of the connection.

Similarly, draft-ietf-netconf-restconf-client-server uses this module to configure a controller/orchestrator/NMS to connect to a router/firewall/switch over RESTCONF.  In this case, the HTTP client uses a tree of URLs, defined by the YANG modules the router/firewall/switch implements.


> --Martin

Martin, this all began due to an AUTH48 expert-review request from IANA, to which you raised a concern for the "ietf-uri" module, which is no longer, which is fine.  Can we unblock the RFC Editor now?

Kent