Hi folks,

Thanks for your kind and constructive comments so far.

I would appreciate some comments on the following parts of the new draft:

a) The basic path design. This splits out the internal path object with a basic API. Some of the procedures are derived from Racket's path library, but uses e.g. RFC 3986 procedures for concatenating like the merge paths procedure. These paths are restricted to characters allowed in IRI path segments (the regular URI path characters + RFC 3987's ucschar range). Characters outside of this range can still be escaped (allowing escapes might be unwise for a general-purpose path structure). Racket paths are here https://docs.racket-lang.org/reference/Manipulating_Paths.html.

b) The get-uri / get-iri procedures which work on a port and return an URI or IRI, if they reach a particular character. I think we should define such a procedure as IRIs and URIs are pervasive in a bunch of other document formats and wbeb standards. So it's convenient to have a procedure like these. Supporting a particular stop character lets one e.g. stop fetching IRI characters from a data source at some closing character (e.g. > in many RDF syntaxes).

c) I have omitted the in-place sub-libraries as suggested, but I don't know if the language which remains in the preamble is helpful. The idea is that the in-place nsetters would have the same error behaviour (as in raise the same parse errors) if implemenations defined them, but it might be too strong to incluse such an instruction. (I mean in this section https://srfi.schemers.org/srfi-275/srfi-275.html#pure-and-impure-interfaces)

Thanks,
Duncan

> On 12 Aug 2026, at 00:45, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> I've just published draft #2 of SRFI 275. It was submitted by Duncan Guthrie, author of the SRFI.
> Here are Duncan's comments on the draft:
> The main changes between the original proposal and this revision are as follows:
> Invalid UTF-8 sequences in escapes are detected and explicitly rejected.
> Generic encode-string and decode-string procedures are provided. The updaters for fields now automatically escape characters which are invalid within the particular component. Character sets for each component are now exported, as well as the common character sets such as the reserved range.
> Paths are explicitly represented as a record comprising a vector of (encoded) segments, which are tagged with whether the path is absolute (leading slash), or relative. A basic path manipulation API is added based on the needs of the library, but which is expected to be generally useful, as URIs are often used to represent resources like paths.
> The in-place API is no longer explicitly defined, but it is said that the in-place setters must have identical error behaviour to the functional updaters, if they are defined.
> Username+password splitting into two values is given and the behaviour is documented.
> Additional parsers are exposed. string->absolute-iri only admits the absolute-IRI production in RFC 3987. There is an additional get-iri procedure. This procedure works directly on a port, and exposing this is advantageous when building streaming parsers for data which contains IRIs, like JSON-LD or RDF/Turtle.
> This necessitated rewriting the sample implementation to take a recursive-descent approach, as it seemed tricky to retrofit the checks for invalid UTF-8 sequences with the previous parser combinator approach.
> Here is the commit summary:
>     • Add table of contents.
>     • Improve horz. and vert. scrolling of last table.
>     • Second draft
>     • reflect SRFI 97 / R6RS library references, normalize spelling
>     • Miscellaneous clarifications and formatting
>     • Clarify behaviour with respect to prefixing ./ to colons in initial segment
>     • Make sure to mention the path sub-library up-front
>     • Update table of contents.
>     • Publish second draft.
> Here's the diff:
> https://github.com/scheme-requests-for-implementation/srfi-275/compare/draft-1..draft-2 Regards,
> SRFI Editor