docs(const,vendor): Method.get cites RFC 959 §4 for a case-insensitivity rule stated in §5.3

[JarryShaw]

Describe the bug

Method.get's docstring explains its own case-sensitivity by contrast with FTP, and cites the wrong section of RFC 959 for the contrast:

pcapkit/const/http/method.py:268      pcapkit/vendor/http/method.py:173
    case-insensitive because :rfc:`959#section-4` says FTP
    command codes are not.

RFC 959 §4 is FILE TRANSFER FUNCTIONS and contains no case-sensitivity language at all. The statement is in §5.3 COMMANDS:

The command codes are four or fewer alphabetic characters. Upper and lower case alphabetic characters are to be treated identically.

Reproduction

$ curl -s -A 'Mozilla/5.0' -L https://www.rfc-editor.org/rfc/rfc959.html -o rfc959.html
$ grep -n -i 'upper and lower' rfc959.html
2469:      Upper and lower case alphabetic characters are to be treated
$ grep -n 'id="section-4"\|id="section-5"\|id="section-6"' rfc959.html
1329:...id="section-4"...4.  FILE TRANSFER FUNCTIONS
2333:...id="section-5"...5.  DECLARATIVE SPECIFICATIONS
2920:...id="section-6"...6.  STATE DIAGRAMS
$ grep -n '5\.3\.  COMMANDS' rfc959.html
2458:   5.3.  COMMANDS

Line 2469 sits between section-5 (2333) and section-6 (2920), so it is inside §5, not §4. That is the only such sentence in the document — note it wraps across lines 2469-2470, so a single-line grep for treated identically finds nothing.

Expected behavior

:rfc:959#section-5``, which is the finest anchor RFC 959 renders (only section-1..`section-8` exist, per #944). Alternatives: `#page-45`, where §5.3 begins, or leave `#section-4` and reword the prose to stop attributing the claim to a section that does not make it.

Notes

• Distinct from docs(const,vendor): six :rfc:959#section-4.1 citations name an anchor RFC 959 does not have #944, which is about the anchor being dead. This is the anchor being live and wrong. docs(const,vendor): six :rfc:959#section-4.1 citations name an anchor RFC 959 does not have #944's ruling ("Sure section-4 is good.") was given before this was known, and docs: retarget every dead :rfc:959 sub-section anchor (#944) #946 applies it to all six sites as ruled rather than widening scope — so this site currently cites a section that does not say what the docstring says it says.
• The two pcapkit/{const,vendor}/ftp/command.py pairs are fine: §4 does contain §4.1 FTP COMMANDS, which supports "type of kind of command".
• Found while verifying docs: retarget every dead :rfc:959 sub-section anchor (#944) #946's cross-review finding. Template and generated copy, so both halves are hand-edited; no crawl or regeneration needed.
• #946's new KNOWN_DEAD_ANCHORS denylist cannot catch this class — the anchor exists.

System information

• pcapkit commit 210bdb419, Python 3.14.7, CPython, Linux.

[JarryShaw]

Correcting my own framing: this is not a new finding, and the repo already ruled on it.

tests/protocols/application/test_ftp_unit.py:86-102 has said so since #582:

The citation is section 5.3 (COMMANDS, which gives the command syntax), not section 4.1 (FTP COMMANDS, which only lists the per-command semantics); #582 cited 4.1 and a cross-review caught it. Verified against the RFC text: the sentence sits between the 5.3 and 5.4 headings.

So §5.3-not-§4.1 was established once already, and the habit outlived the correction. That makes this a recurrence rather than a discovery, and it widens the scope: the same misattribution is on seven sites, not one —

pcapkit/const/http/method.py:268        pcapkit/vendor/http/method.py:173
docs/source/contributing/conventions/registry-protocol.rst:224,281,337,443
tests/const/test_const_enum_no_mint.py:2111

Line 281 is the clearest: it cites 959#section-4.1 directly above the quote "Upper and lower case alphabetic characters are to be treated identically" — §5.3's own sentence, attributed to §4.1 in the same table row.

That same docstring also drew the distinction this issue needs: ftp/command.py's citations are the command-kind claim, which §4 does support, so those are correct and are not in scope here.

#946 now fixes the dead anchor at all thirteen 959 sites (including two #section-5.3 roles, also dead) but deliberately does not re-point any of these seven, because which section they should name is this issue's question. The choice is unchanged: #section-5 is the finest live anchor, #page-45 is where §5.3 begins, or reword the prose to stop attributing the rule to a section that does not state it.

My lean is #section-5, matching what #946 already did to the two roles that only carried the case claim. Still yours to call.

[JarryShaw]

Sure section-5 works

[JarryShaw]

Ruling — #section-5. Verbatim:

Sure section-5 works

So the seven sites that attribute FTP command case-insensitivity to §4 now cite :rfc:`959#section-5, the finest live anchor RFC 959 renders:

pcapkit/const/http/method.py:268        pcapkit/vendor/http/method.py:173
docs/source/contributing/conventions/registry-protocol.rst:224,281,337,443
tests/const/test_const_enum_no_mint.py:2111

#946 already retargeted these to #section-4 to kill the dead #section-4.1 anchor; this moves them one further, to the section that actually states the rule. The two ftp/command.py pairs stay at #section-4 — they carry the command-kind claim, which §4 does support, as tests/protocols/application/test_ftp_unit.py has documented since #582.

needs: decision off, wip on. Folding into #946 rather than raising a second PR, since it is the same files and the same defect class, and #946 has not merged.

[JarryShaw]

Applied in #946 at 0d025d24d — six of the seven sites now cite :rfc:959#section-5``:

pcapkit/const/http/method.py:268        pcapkit/vendor/http/method.py:173
tests/const/test_const_enum_no_mint.py:2111
docs/source/contributing/conventions/registry-protocol.rst:224, 281, 443

The seventh, registry-protocol.rst:337, is left at #section-4 and flagged on the PR rather than moved. Its row claims the RFC presents the kind and conformance letters upper case (A/P/S, M/O/H), which is §4.1's command list — not §5.3's case-insensitivity rule. I had listed it among the seven when asking, so applying the ruling literally there would have made that citation worse.

Staying wip until #946 merges.