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

Interesting discussion...

________________________________
From: Tim Bray
Sent: Thursday, December 4, 2025 10:21:05 PM
To: Kent Watsen <kent+ietf@watsen.net>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>; tom petch <ietfa@btconnect.com>; art@ietf.org <art@ietf.org>; uri@w3.org <uri@w3.org>; uri-review@ietf.org <uri-review@ietf.org>; Martin Thomson <mt@lowentropy.net>
Subject: Re: [Uri-review] Re: [art] Alternative representation of URIs in YANG

I think the reason that you’re running into friction is that what you’re doing feels weird to people who think about Web architecture.  A core premise is that URIs are short-ish strings and that most software in most software doesn’t need to and in fact SHOULD NOT poke around inside them.  These strings are the keys into the Web’s vast and flat information space, and they have proved to be highly successful for integrating wildly diverse things together.

In practice, what can you actually do with a URI? You can compare it to another URI (super important for supporting caching) and you can feed it to an API, many of the most successful being RESTfully flavored and all of them taking URI strings as input.  There are libraries in basically every programming language that can parse and validate and try to retrieve or update whatever it is a URI (expressed as a string) identifies.

I guess specifying a minimum list of URI schemes is OK, but having a maximum, i.e. limiting the allowed schemes, is likely not a good idea because new ones come along and occasionally are useful.

Your expressing them as a structure is going to make comparing them more difficult than it is for strings.   There’s more to comparing URIs than you might think, see https://datatracker.ietf.org/doc/html/rfc3986#section-6


I appreciate that this all may sound a bit vague and arm-wavy but my feeling is that URIs are specified as strings and are passed to APIs as strings and any expression that is not a string is thus a bit jarring.  -Tim


On Dec 4, 2025 at 6:39:38 PM, Kent Watsen <kent+ietf@watsen.net<mailto:kent%2Bietf@watsen.net>> wrote:


On Dec 4, 2025, at 7:08 PM, Martin Thomson <mt@lowentropy.net<mailto:mt@lowentropy.net>> wrote:

A URL is a URI that is also a locator.  That is, if you can resolve it, it will lead you to something.

Yes, locators is our primary interest.  We have zero interest in URNs.


Those are definitely more likely to use the same authority form that HTTP does, but there isn't a firm guarantee.

Grrr


The only safe container for a URI generically is a sequence of bytes or characters (the difference between each is important in many cases, but not here).  The same is generically true for URLs as well, though under certain narrower definitions it might be safe to carry them in other ways.  See https://url.spec.whatwg.org/ for an example of one such narrow definition.  However, that definition includes file: and blob: URLs, which are more complicated than you might like.

Egads, I don't see an out yet.

Context:
  - The must-have schemes are http: and https:
  - The nice-to-have schemes include file:, ftp:, scp:, and mailto:
  - Lesser nice-to-haves include: ws: wss:
  - No interest in the blob: scheme

FWIW, in the YANG module, it is possible to make the "scheme" field be an enumeration.  That is, the scheme can be locked down to any subset of the above.

Is there a suitable name for some subset of the above?  How about:

  *   constrained-url
  *   structured-url
  *   decomposed-url
  *   http-and-https-url
  *   any other suggestion, besides a sequence of bytes or characters ;)

Kent


_______________________________________________
Uri-review mailing list -- uri-review@ietf.org<mailto:uri-review@ietf.org>
To unsubscribe send an email to uri-review-leave@ietf.org<mailto:uri-review-leave@ietf.org>