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

[Kent Watsen <[e-mail]>]

[CC-ing Mahesh, as my co-author on draft-ietf-netconf-https-notif, which depends on this work]


Hi other Martin  ;)

> On Dec 2, 2025, at 7:18 PM, Martin Thomson <[e-mail]> wrote:
> 
> The other Martin here...
> 
> On Wed, Dec 3, 2025, at 06:29, Kent Watsen wrote:
>> The document previously used the "ietf-inet:uri" typedef from RFC 6991 
>> (previously RFC 6021).  The WG complained that the unstructured format 
>> did not exhibit good YANG-fu (best practice), making it hard to 
>> apply/validate defaults and constraints on individual fields.  From a 
>> YANG-outlook perspective, the "ietf-inet:uri" typedef is likely to be 
>> rarely used.
> 
> URIs are more complicated than your decomposed structure allows for.  That's the problem.  If you are going to represent a URI, it really has to be a string.

I believe you, but I'm unsure what I missed in RFC 3986...

Does this regard the percent-encoded form of a URIs that don't  follow the "normal circumstance" mentioned in the first paragraph here: https://datatracker.ietf.org/doc/html/rfc3986#section-2.4?   Would it help for this draft to state that the values MAY be percent-encoded?


> If the goal is to only represent an HTTP URI (or an HTTPS URI, ideally), then you can use the structure you describe, but you would name it accordingly.  You might also find that you don't need fragment in this context, because HTTP doesn't carry fragments.

I imagine this YANG grouping being useful for other schemes other than http/https.  I'm especially thinking about ftp, scp, and mailto.


Kent // as author of the http-client-server draft