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

Thanks for the follow-up Dale!   I agree that no valid contradiction has been provided yet.

Folks, this discussion has been going on since Thanksgiving.  Can we make a decision now?

Options:

leave "ietf-uri" as is
leave "ietf-uri" as is, but add an "applicability" note (recommendations welcome)
rename "ietf-uri" to "ietf-url", possibly referencing https://url.spec.whatwg.org <https://url.spec.whatwg.org/>
rename "ietf-uri" to "ietf-http-url" (are URLs ever HTTP-specific?)
eliminate "ietf-uri" by embedding the fields directly into the "ietf-http-client"

Martin, since you're the one blocking the draft, can you state which of these options are okay and which options are not okay with you?

Mahesh, any advise as the responsible AD?


Kent // as author of draft-ietf-netconf-http-client-server



> On Jan 21, 2026, at 9:09 PM, Dale R. Worley <worley@ariadne.com> wrote:
> 
> Sorry for dropping the ball on this...
> 
> "Martin Thomson" <mt@lowentropy.net> writes:
>> I know that you are trying to make the case for decomposition Dale,
>> but I don't think it has been made.  RFC 6991 made the right call
>> (mostly; see below) in avoiding the need for a URL parser.
>> 
>> steam://run/<digits> doesn't follow the authority form, but will be
>> parsed successfully as such.  Is that a good outcome?
> 
> I don't see precisely what the problem is here.  Syntactically, it has a
> <authority> of "run", which is syntactically a <host>, and an
> <path-abempty> of "/<digits>".  Of course *semantically* "run" is almost
> certainly not a valid host name.  (Then again, maybe not.  I remember
> hearing the story of a fellow whose e-mail address was <something@se>
> because the country root domain "se" had an MX record.)  But it's not
> clear to me that the "validity" of a URI depends on the <host> being the
> name of an existing host.
> 
> As for parsing URI's, I've not written a parser personally but I did
> work with someone who wrote a "Perl-compatible regular expression" that
> was exeuted by a "PCRE" C package and it worked straightforwardly.
> 
> Though I don't really have a strong opinion about which way the Yang
> module does it.
> 
> Dale