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> wrote:

>
>
> On Dec 4, 2025, at 7:08 PM, Martin Thomson <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
> To unsubscribe send an email to uri-review-leave@ietf.org
>