Hi Ivan,

> On 8 Aug 2026, at 23:41, Ivan Raikov <xxxxxx@gmail.com> wrote:
>
> Hello Duncan,
>
> Thanks again for your work on this SRFI. Below are my responses to your points:
>
> - On 1.5 (Round-trip invariant and character-set exports)
>
> The design with a generic `encode-string` plus component-aware parsers that interpret percent-encodings is a good split. It makes the behavior of each entry point unambiguous without coupling them together. Exporting the RFC 3986 character sets would be very helpful for applications doing custom encoding.

OK, that's encouraging. Thanks! It seems to work quite well in practice.

> - On 3.1 (`uri-relative-from`)
>
> The uri-generic procedure `(uri-relative-from uabs base)` returns a new URI which represents the relative location of the first URI (`uabs`) with respect to the second URI (`base`).
>
> It dispatches on six cases in order:
>
> 1. Schemes differ -> return the `uabs` URI unchanged (no relative form exists).
> 2. Authorities differ (schemes are same) -> strip the scheme; return a network-path reference (`//authority/path...`).
> 3. `uabs` has a null path (e.g. "http://a" with no trailing slash) -> strip the scheme; no relative path can be formed.
> 4. Paths differ -> strip scheme and authority; compute the relative path from dot-normalized copies of both paths.
> 5. Queries differ but paths are identical -> strip scheme, authority, and path; return "?query#fragment" only.
> 6. Only fragment differs (or both URIs are identical) -> strip scheme, authority, and query; return just the final path name (or "." for a directory-only `uabs`).
>
> The relative path computation (Case 4 above) is the only non-trivial part: strip common leading directory segments from both paths, then prepend one ".." for each remaining directory in the base path.
>
> You are right that there are no official RFC test cases for this operation. The test vectors in section 3.1 are drawn from the uri-generic test suite and cover all six structural cases above. The round-trip invariant `(uri-relative-to (uri-relative-from T B) B) = T` provides the correctness criterion.
>
> Without including this procedure, applications doing link relativisation must implement this dispatch themselves, and the edge cases (null path, query-only difference, directory vs. name distinction) are easy to miss or get wrong.

OK, I think it's a good idea, but I've opened a pull request for a second draft to the SRFI repository which doesn't include it yet. I would probably just port that part of your library to the sample implementation.

This seemed like a good point at which to update the document, as the path sub-library is already quite a substantial modification.

https://github.com/scheme-requests-for-implementation/srfi-275/pull/1

> - On 3.2 (`uri-path-absolute?` and `uri-path-relative?`)
>
> The path library at the scheme-iri repo seems like a clean approach. Making segments explicit in the representation addresses both this and the empty-segment preservation issue (section 2.4) at once. Exporting these predicates from `(srfi 275 path)` makes sense, as they are utility operations that belong naturally alongside a path record type.
>
> - On 4.1 (Username and password accessors)
>
> If option (b), i.e. a single `uri-userinfo` accessor with documentation on how to split it is the easier path for now, that is perfectly workable. The SRFI should document explicitly the "%3A" case: a percent-encoded colon in the userinfo is not a username/password separator. That is another common trap for URI handling.

In the updated draft I have added helper procedures for this. They just split the string representation (or the encoded representation) on the first plain colon. In the sample implementation, internally it's a single field still. There is also a helper procedure in a utility sub-library which behaves the same for strings retrieved from an IRI or URI.

The field is still retrieved with `iri-user' or `uri-user' but I wonder if `iri-userinfo' &c to match the RFCs' ABNF would be better.

> - On 4.3 (Parse modes and the RFC 3986 reference)
>
> Upon rereading RFC 3986, I do realize that it does not say anything about how implementations should handle parse errors. I wrote this incorrectly from memory.
>
> The point I should have made is that RFC 3986 §4 defines two distinct productions with different constraints:
>
> - §4.1 `URI-reference`: the permissive form, which accepts both absolute URIs and relative references, with or without a fragment.
> - §4.3 `absolute-URI`: the strict form, which requires a scheme, disallows a fragment component (`absolute-URI = scheme ":" hier-part [ "?" query ]`).
>
> These two RFC productions then map directly onto two exported procedures in uri-generic: one that returns #f (or signals a condition) for anything outside the permissive form, and a second that enforces the `absolute-URI` production specifically. It is useful in practice: the lenient form for testing whether a candidate string is URI-shaped at all, the strict form when an absolute URI is required by contract.
>
> If your recursive-descent parser already produces the appropriate record type based on how the parse proceeds, the main question is only whether to export a separate procedure that rejects non-absolute inputs with an error. Given that you have added distinct parsers for absolute and non-absolute URIs, it sounds like the infrastructure for this is already in place.]

That helps a lot, thanks. I think the behaviour you describe is already exhibited, then.

More generally I find the 'URI-reference' language in the RFCs quite confusing because they also concern relative references, which is why I picked `string->uri' to do what your uri-reference procedure does. I actually implemented the `string->absolute-uri' procedure as in applications like RDF (N-Triples), they reject non-relative IRIs. But they also admit IRIs with a fragment, which isn't an RFC 3987 'absolute-IRI', so possibly another procedure is needed!

It has occured to me that procedures named like 'rfc-uri-reference' like for the path predicates could be helpful as it would make it explicit that we're working with the RFCs' language.

Thanks,
Duncan