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

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?

On Tue, Dec 16, 2025, at 14:23, Dale R. Worley wrote:
> I notice that in the simple uri typedef in RFC 6991, the description
> includes this text:
>
>          Objects using the uri type MUST be in US-ASCII encoding,
>          and MUST be normalized as described by RFC 3986 Sections
>          6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
>          percent-encoding is removed, and all case-insensitive
>          characters are set to lowercase except for hexadecimal
>          digits, which are normalized to uppercase as described in
>          Section 6.2.2.1.
>
> It's possible that the I-D may want to require some of this
> normalization.  But that decision doesn't seem to affect the validity of
> this representation of URIs.

I'd argue that this is not a good idea for RFC 6991 as well.  Normalization requirements like these would seem to improve interoperability, but they frequently have the opposite effect.  Strings that were equal appear differently as a result and - when normalization is imprecisely defined (as here) it is also inconsistently implemented, so once-equal URIs compare as not equal.

Consider https://example.com/a%2fb  Is the pct-encoded "%2f" unnecessary or not?

As Tim said: 

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

That's an architectural principle to stand behind right there.

(Roy gave more extensive advice about what it means to configure HTTP, which identified a range of different needs for identifiers.  I would also pay attention to that, though Roy's message goes well beyond the subject of this thread.)

Received on Tuesday, 16 December 2025 03:53:35 UTC