Hi Peter, I'll reply inline…

> On 15 Sep 2026, at 06:27, Peter McGoron <xxxxxx@mcgoron.com> wrote:
>
> https://srfi.schemers.org/srfi-275/srfi-275.html#utf-8-interpretation
>
>> If the information is available, then invalid sequences of UTF-8
> octets should raise an assertion violation with the offending octet and its position within the bytevector as irritants. This information may not be available, in which case the irritants consist of the irritants are the offending octet alone.
>
> Is signalling an error required (with the irritants depending on the information available), or is signalling optional? If signalling is optional, what are the allowed behaviors on invalid UTF-8 bytes?

Signalling is not optional. Invalid UTF-8 bytes must always error. Does my 'should' then 'may' language create ambiguity?

> Also, is an assertion violation raised even when the text specified "an error" is raised?

No, an assertion violation should only be raised when I use the language explicitly. I'm very unsure of the least-restrictive language which would admit using conditions if available. I have found it difficult to tell what the typical conventions are with respect to conditions in existing SRFI proposals.

> ____________________
>
> https://srfi.schemers.org/srfi-275/srfi-275.html#notation-and-convention
>
> SRFI 97 libraries have a library name that precedes the sublibraries. So the SRFi 97 convention would be:
>
> * (srfi :275 uris-and-iris iri)
> * (srfi :275 uris-and-iris uri)
> * (srfi :275 uris-and-iris normalize)
> * (srfi :275 uris-and-iris path)
> * (srfi :275 uris-and-iris utils)
>
> I would also note the R7RS-Small convention, which is similar to what is currently in the SRFI:
>
> * (srfi 275 iri)
> * (srfi 275 uri)
> * (srfi 275 normalize)
> * (srfi 275 path)
> * (srfi 275 utils)
>
> _____________________

OK, I will probably just remove the reference to SRFI 97, as I misunderstood it.

> https://srfi.schemers.org/srfi-275/srfi-275.html#iri-authority
>
> Procedures should generally return the same number of values for each invocation. If not, it is difficult to use the procedure in a let binding:
>
>    (let-values (((user host port) (iri-authority iri)))
>      ;; Unspecified what happens when the procedure returns a single #f
>      ...)

I agree this is confusing behaviour in the authourity procedures. I'm likely just going to ditch the single-argument case. I had an idea that `case-receive` could be employed but that's not very widespread.

Thanks again,
Duncan