Hello Artyom and John,

Thanks for writing back!

I think query decoding (or paths as suggested in a different email by Peter Bex today as well) might be in scope, and I've seen a couple of other implementations like Erlang/Otp do it. For this proposal I primarily focussed on correctness with respect to abstract syntax and normalisation.

If we were to omit this sort of additional processing from the SRFI (as currently), then I think we would probably need to expose the internal representation of the IRI or URI to the programmer, so that they could work with the field reliably accross implementations. Specifically, I think we want to try to avoid the situation where the programmer has to process a string representation directly, because then they probably have to parse with respect to percent-encodings themselves - it is very tricky!

The sample implementation is based on SRFI 160 u16vectors to represent both UTF8 octets and percent-encoded escapes. It seems to be very important to separate characters and the percent-encodings because interpretation of these during normalisation is surprisingly tricky to get right. I assume that string representations would likely involve many more encoding/decoding/parsing steps in order to ensure internal consistency.

Another reason we might want to expose this internal representation is so that normalisation schemes can be portably added by the programmer (see below) but I'm not sure how we'd do this reliably without specifying a particular internal representation. requiring this seems to be too prescriptive which was why I didn't specify the raw interface.

The raw interface in the sample implementation is documented as follows. Note the split record type with no common fields, this is another reason I didn't specify in the SRFI document (because I wasnt' entirely happy with the design I had to split those):
https://codeberg.org/dguthrie/scheme-iri/src/commit/c40d3cf668d5b7c56d2aee699903a221fb237217/doc/programming-interface.md#abstract-record-types-and-internal-programming-interface

Thougts? Do we have any examples of similar internal/external representation we could borrow from?

With respect to John's points specifically:

For (1), I specify support for in-place mutation because of the internal representation I used, but made it optional for similar reasons as I wrote abvoe. I was a little on the fence when writing this up and I described a split immutable/optional mutable setter interface pretty late in drafting. I think it would be diserable to make the document more terse, and make room for procedures like query alist, just to say that implementations may provide in-place setters with the same error behaviour as the functional updaters as it's already quite long.

For (2), As you say normalisation is currently completely independent of scheme. I did not even support HTTP or default ports. I am not sure about this one, but generally speaking, I dislike the approach of many existing implementations in silently normalising different schemes as it was really inconvenient when I was trying to identify scheme-independent test cases.

I could instead imagine we might have standalone procedures like `normalize-http-scheme' and extending the general `normalize-uri' procedure with optional argument(s) of a scheme-specific normalisation. I suspect doing it well migth also involve a registry of schemes and their normalisation, and to make it extensible like in a dictionary.

For (3), my personal interest here is in IRIs, where domain names can be within most of the UCS, and where there is little to no normalisation. It seems like support for these could be developed separately without too much trouble. And omitting/including this raises the question of exposing the internal representation.

For (4), As you will see from my spelling in this email I didn't notice this as I'm from Scotland. I agree with consistency with the R6RS, and it's a very simple change compared to question of internal/external representation.

Thanks,
Duncan

> On 16 Jun 2026, at 04:26, John Cowan <xxxxxx@ccil.org> wrote:
>
> I agree that these query manipulation procedures should be provided, as well as a fourth that converts an alist to a query string.
>
> In addition:
>
> 1. I think there is no need to support in-place mutation. Although there is no fixed limit on the size of a URI, in practice about 8000 characters is as big as they get.
>
> 2..There is no support for non-generic schemes such as data: (RFC 2397).
>
> 3. There is no support for internationalized domain names (RFC 5890/5891).
>
> 4. It is confusing to use the spelling "normalise" whrn R6RS uses "normalize". Although "-ize" spellings are used by a minority outside the U.S., they are not absolutely wrong.
>
>
>
>
>
> On Mon, Jun 15, 2026, 9:53 PM Artyom Bologov <xxxxxx@aartaka.me> wrote:
> Hi y’all,
>
> Having skimmed the document, I noticed absence of query handling helpers
> that are often present in implementation-specific URI-handling
> APIs. Three operations are missing:
>
> • Query parameter parsing, something like (iri-query->alist iri) => alist.
>
> • Query encoding: (query-encode string) => %-escaped-string
>
> • Query decoding: (query-decode string) => %-deescaped-string
>
> Is that in scope for this SRFI?
>
> Best of luck,
> --
> Artyom Bologov
> https://aartaka.me