Repository navigation
docs: ten :rfc: citations name sub-section anchors RFC 1122 and RFC 719 do not render #950
Description
Describe the bug
Ten :rfc: citations name sub-section anchors that their RFCs do not render — the same defect class as #944, in two other documents. Each renders a live link to nothing.
RFC 1122 renders anchors for its five top-level sections only:
$ curl -s -A 'Mozilla/5.0' -L https://www.rfc-editor.org/rfc/rfc1122.html \
| grep -o 'id="section-[0-9.]*"' | sort -u
id="section-1" id="section-2" id="section-3" id="section-4" id="section-5"
$ ... | grep -c 'id="section-[0-9]*\.[0-9]'
0
Yet :rfc:1122#section-3.3.2`` is cited at nine sites:
pcapkit/foundation/extraction.py:817
pcapkit/foundation/reassembly/tcp.py:84
pcapkit/foundation/reassembly/ipv4.py:56
pcapkit/foundation/reassembly/reassembly.py:312
docs/source/contributing/pep.rst:761
docs/source/contributing/pep.rst:770
docs/source/pcapkit/foundation/reassembly/tcp.rst:315
docs/source/pcapkit/foundation/reassembly/ip/ipv4.rst:164
tests/foundation/reassembly/test_timeout.py:48
RFC 719 is worse — its rendered page carries no id= attributes at all, so every fragment on it is dead:
$ curl -s -A 'Mozilla/5.0' -L https://www.rfc-editor.org/rfc/rfc719.html | grep -c 'id="'
0
and pcapkit/vendor/ipv4/ts_flag.py:23 cites :rfc:719#section-3.1``.
Expected behavior
The enclosing top-level section, matching the ruling on #944 and #947: #section-3 for RFC 1122, and for RFC 719 either no fragment at all or a #page-N — but RFC 719 renders no anchors whatsoever, so no fragment is the only honest option there.
1122#section-3.3.2 is Reassembly, which is what all nine sites are about, so #section-3 ("INTERNET LAYER PROTOCOLS") keeps the citation pointing at prose that supports them while losing the sub-section precision. Worth confirming that trade is acceptable before the sweep, as it was for #944.
Notes
- Found by the cross-review of docs: retarget every dead :rfc:
959sub-section anchor (#944) #946 while checking whether that PR'sKNOWN_DEAD_ANCHORSdenylist was complete — it asked the right question: which other RFCs cited here also lack sub-anchors. Out of scope for docs(const,vendor): six :rfc:959#section-4.1citations name an anchor RFC 959 does not have #944, which named only RFC 959. - Once fixed, both belong in
KNOWN_DEAD_ANCHORSintests/project/test_rfc_anchor_fragments.pyso they cannot return. RFC 719 needs a different denylist shape from 959 and 1122 — for 719 every fragment is dead, not an enumerable set, so listing individual ones understates it. - Older RFCs are the pattern here. RFC 959 (1985), 1122 (1989) and 719 (1976) all predate per-subsection anchors; RFC 8684-era documents render them. A sweep of every pre-1990 RFC cited with a sub-numbered fragment would likely find more, and is the right scope for this issue rather than fixing these ten in isolation.
- Sequenced behind docs: retarget every dead :rfc:
959sub-section anchor (#944) #946, which is actively editingtests/project/test_rfc_anchor_fragments.py.
System information
pcapkitcommit210bdb419, Python 3.14.7, CPython, Linux.
Activity
docs: retarget every dead :rfc:`959` sub-section anchor (#944)
JarryShaw commentedon Sep 30, 2026
If RFC doesn't provide anchor link, just drop them if anchored ref won't generate hyperlinks; if they can still generate hyperlinks to the RFC itself, we can just keep the section anchors as a notation to reader.
JarryShaw commentedon Sep 30, 2026
Ruling recorded, and measurement says the second branch applies — the anchors stay. (#950, 14:07:28Z: drop the anchor only if an anchored ref would generate no hyperlink; if it still links to the RFC itself, keep the anchor as a notation to the reader.)
Measured rather than reasoned about. Rendered the roles through this repo's own Sphinx and read the emitted HTML:
sphinx.roles.RFC.build_uriappends the fragment to the document URL and returns a plainnodes.reference, so a hyperlink is always generated and always reaches the RFC — a dead fragment only means the browser stays at the top of the page instead of jumping. There is no case here where the link fails to render.So no change is needed for either RFC: all ten sites keep their anchors as notation. Closing on that basis rather than on a sweep.
But this cuts across #944 and #947, and I would rather flag it than quietly leave the two inconsistent. Those rulings retargeted thirteen RFC 959 citations —
#section-4.1to#section-4,#section-5.3to#section-5— and #946 implements that. Under the principle here, none of them needed changing, because each already generated a working link. The question put to you on #944 was which replacement to use, which presupposed replacing; it was not "should we replace at all".Asked on #946 rather than decided here. My lean is that #946's retargeting stands — a fragment that actually resolves is better than one that does not, and you ruled for it twice — with this issue's principle covering the cases where no better anchor exists. RFC 719 is the clean example: it renders no anchors at all, so there is nothing to retarget to and the notation is all that is available.
needs: decisionoff.docs: retarget every dead :rfc:`959` sub-section anchor (#944)
docs: retarget every dead :rfc:`959` sub-section anchor (#944)
docs: retarget every dead :rfc:`959` sub-section anchor (#944)
docs: retarget every dead :rfc:`959` sub-section anchor (#944, #947)
docs: retarget every dead :rfc:`959` sub-section anchor (#944, #947)
docs: retarget every dead :rfc:`959` sub-section anchor (#944, #947)
docs: retarget every dead :rfc:`959` sub-section anchor (#944, #947)