hyperlinking fails for certain reference names (here: "HTTP/1.1")

[reschke]

See https://datatracker.ietf.org/doc/html/rfc9110#section-6.5.1:

   A trailer section is only possible when supported by the version of
   HTTP in use and enabled by an explicit framing mechanism.  For
   example, the chunked transfer coding in HTTP/1.1 allows a trailer
   section to be sent after the content (Section 7.1.2 of [HTTP/1.1]).

This incorrecty handles this as internal link, as "[HTTP/1.1]" is not recognized as link target.

[cabo]

Of course not; HTTP/1.1 is not a valid XML ID.
(Note that this is also true of displayreference per https://ietf-tools.github.io/xml2rfc/#name-to-attribute-required -- which is ignored by RFC 9110.)
So this points to another need for an upgrade of the heuristics; however, there doesn't appear to be documentation that could be guiding this.

[reschke]

A pragmatic approach would be to allow those characters that are actively used in <displayreference>s.

And yes, good catch: the processor(s) did not complain about that. As we can't fix the RFCs that have been published, we might want to extend the set of allowed characters.

[cabo]

A pragmatic approach would be to allow those characters that are actively used in s.

I think your comment is missing something.
Since I can guess what you mean: Yes, exactly, this is what we should be doing.

And yes, good catch: the processor(s) did not complain about that. As we can't fix the RFCs that have been published, we might want to extend the set of allowed characters.

The grammar doesn't check the name. This is an example where the boundaries of what RFCXML is are defined by the implementation, not by the documents that ostensibly govern that implementation. That is theoretically a problem, but here it also is a reflection of the fact that these documents resisted change for so long.

[rjsparks]

I fixed Julian's comment. If you suspect something is missing like that in the future, try to look at the source if the interface will let you.

[reschke]

FWIW, added diagnostics in reschke/xml2rfc@e840688

[reschke]

Diagnostics from published RFCs:

9110: HTTP10 -> HTTP/1.0 -> /
9110: HTTP11 -> HTTP/1.1 -> /
9110: HTTP2 -> HTTP/2 -> /
9110: HTTP3 -> HTTP/3 -> /
9111: HTTP11 -> HTTP/1.1 -> /
9112: HTTP10 -> HTTP/1.0 -> /
9113: RFC9112 -> HTTP/1.1 -> /
9114: RFC9112 -> HTTP/1.1 -> /
9114: RFC9113 -> HTTP/2 -> /
9204: HTTP2 -> HTTP/2 -> /
9204: HTTP3 -> HTTP/3 -> /
9205: HTTP11 -> HTTP/1.1 -> /
9205: HTTP2 -> HTTP/2 -> /
9205: HTTP3 -> HTTP/3 -> /
9218: HTTP2 -> HTTP/2 -> /
9218: HTTP3 -> HTTP/3 -> /
9220: HTTP3 -> HTTP/3 -> /
9220: HTTP2 -> HTTP/2 -> /
9250: I-D.ietf-quic-http -> HTTP/3 -> /
9292: RFC9113 -> HTTP/2 -> /
9292: RFC9112 -> HTTP/1.1 -> /
9292: RFC9114 -> HTTP/3 -> /
9297: RFC9112 -> HTTP/1.1 -> /
9297: RFC9113 -> HTTP/2 -> /
9297: RFC9114 -> HTTP/3 -> /
9298: RFC9112 -> HTTP/1.1 -> /
9298: RFC9113 -> HTTP/2 -> /
9298: RFC9114 -> HTTP/3 -> /

So this is entirely caused by the HTTP WG's citation recommendations.

A pragmatic fix for this tool would be to allow the "/". For the vocabulary, we'll need a similar discussion.