Hi Wolfgang,

The behaviour of string->iri is to parse a string into an IRI object, which
in the reference implementation is mechanised as an (opaque) record type
with an internal bytevector encoding.

In the reference implementation, the different IRI and URI components are
encoded as SRFI 160 u16vectors where 0-255 are regular UTF-8 octets, and
256-511 represent hex escapes. This allows for normalisation in a single pass
and it seems to be fairly efficient as it avoids having to reparse (and
potentially reinterpret) escapes, which is pretty error-prone. The IRI (and
URI) object is therefore a record containing fields with this internal
representation (albeit paths are a vector of segments encoded like this).

The error behaviour section is only relevant when updating because these
conflicts would not arise during parsing a whole URI or IRI.  In the reference
implementation, when I update a given field of an URI or IRI, the particular
string is parsed into the internal representation then this raw representation
is set with the record's internal in-place setter.

The current design (at least for IRIs) assumes UTF-8 string input. If the IRI
is formatted in anything else there would have to be additional normalisaton
and pre-processing which I think we want to avoid. The most relevant section
of RFC 3987 is here:
https://www.rfc-editor.org/info/rfc3987/#section-3.1

I think the output strings are all UTF-8? The way serialisation of a component
(or a whole URI or IRI) works is to interpret the internal representation as
UTF-8 octets, using utf8->string or similir. If there's a way to ensure a
string has a pure ASCII encoding in the R6RS, the reference implementation
doesn't use it.Should this language be clarified?

The behaviour of the getters and setters can be thought of as an abstraction
which interprents the internal representation of these components as strings.

In principle URIs are not dependent on unicode at all, with the exception of
the procedures suggested by Ivan Raikov for encoding/decoding according to
a specific character set. I think we want both URIs and IRIs (to represent
non-ASCII) in a modern programming interface, though.

Thanks,
Duncan

> On 4 Aug 2026, at 18:15, Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>
> Hi Duncan,
>
> Thanks for your work on SRFI 275.  I've enjoyed studying it.
>
> What is the error behavior of 'string->iri'?  I was trying to interpret
> the information in the "Error behavior of setters and updaters" section
> in the context of parsing a string, but I'm not sure that's right.
>
> I was also wondering about encoding.  Must the argument to
> 'string->iri' be a UTF-8 string?  Similarly, should we expect
> 'iri->string' to return a UTF-8 string?
>
> Thanks, and best regards,
>
> Wolfgang
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>