Hi Duncan,

Just a quick note: I'm enjoying this conversation a lot, and I'm
(re-)learning quite a bit of how our eggs work :)

On Tue, Jun 16, 2026 at 02:50:25PM +0000, D Guthrie wrote:
> I make a very particular tradeoff because I rarely updated fields and I wanted
> to serialise as efficiently as possible. Serialisation makes no checks for
> internal consistency, but this led to the setters restricting their arguments
> to valid string data and explicitly erroring.

Makes sense.  You could get the same serialization performance by doing the
encoding in the setters, of course.

> Apart from reserved characters, I assumed that IRIs (as they can contain
> almost any data in the UCS) would be most often used, then converted to URI
> if one needed to restrict the character range. It seemed unlikely an error
> would be raised for an IRI, so the behaviour felt reasonable.
>
> Just so I can understand this, in the Chicken library, if you feed it a
> hostname string like "crêpe", what happens? I.e. do you percent encode during
> serialisation or do you percent encode immediately when updating the record?

Our serialization uses percent-encoding (not punycode), so you'll get
"http://cr%C3%AApe" in uri-common.  Uri-generic does not do this, it
expects the user to do the encoding and (currently) does not verify that
everything is properly encoded.  If you hand it an unencoded string,
it'll just emit that as-is in the URI (which then cannot be parsed back,
although in the CHICKEN 6 version it does get parsed, so there's an
inconsistency there I'll have to look into).

As I explained in my earlier post, this is a bit of a footgun in
normal use, that's why uri-common does all of this transparently.

> If I understand correctly, it sounds somewhat similar (except with respect to
> reserved characters) to how I currently implement normalisation of invalid
> characters in both URIs and IRIs, albeit it's currently difficult to set them
> at all without working directly on the raw internal representation.

I think your library is closer to uri-generic, except for the automatic
splitting of path components.

> Ah, thanks for the pointer, that helps a lot. When I was looking at
> existing implementations I looked at uri-common but only found test cases
> specific to specific schemes, I wasn't aware of the split and I assumed
> you had fewer test cases. I'd have cited your test suite in the first draft
> of the SRFI if I'd known about it. I'm guessing we have many of the same
> cases given many were compiled by Klyne.

We've taken his original test suite as a basis, but extended it quite a
bit over the years.  It should cover more cases.

> Just to clarify, what is the expected behaviour with respect to the
> reserved characters? If I fed you <http://foo/a:b> and then <http://foo/a%3Ab>,
> what would you consistently encode those as?

In uri-common, both would be decoded to '(/ "a:b") and if you set the
path to '(/ "a:b") it would get consistently encoded to "a%3Ab".
It is possible to set the path by hand to "a:b", but then you have
to extract the underlying uri-generic object and update the path in
that.

But uri-common *does* attempt to preserve the URI's components as
parsed, so if you don't manipulate them, they will stay as-is, to
ensure safe passage through, say, a proxy built with uri-common.

Cheers,
Peter