Skip to content

docs(vendor,const): MPTCPOption cites RFC 8684, which obsoletes 6824 (#2330) - #2380

Merged
JarryShaw merged 1 commit into
mainfrom
docs/2330-mptcp-rfc-citation
Oct 27, 2026
Merged

JarryShaw merged 1 commit into
mainfrom
docs/2330-mptcp-rfc-citation

Conversation

@JarryShaw

@JarryShaw JarryShaw commented Oct 27, 2026 •

Copy link
Copy Markdown
Owner

What is the purpose of your pull request?

  • docs — documentation

Description

Closes #2330.

  • Problem: the class docstring of the MPTCPOption crawler, mirrored into the generated const module, and two citations in pcapkit/protocols/transport/tcp.py (the Multipath TCP option-kind map entry, and _read_mode_mp's generic Figure 3) all cited RFC 6824. IANA's "MPTCP Option Subtypes" and "TCP Option Kind Numbers" registries cite RFC 8684, which obsoletes 6824 as of 2020-03, and Figure 3 is identical in both RFCs. The eight other 6824 citations in tcp.py stay — those document the legacy v0 wire layouts (the ADD_ADDR IPVer nibble, the MP_PRIO 4-octet AddrID form) the parser still accepts, which 8684 itself records as removed.
  • Fix: cite 8684 at all four sites. The crawler/const pair is edited identically, no re-crawl.
  • Test: tests/const/test_const_mp_tcp_option_rfc_2330_unit.py pins the table against the obsoleted RFC rather than a single value (so a legitimate future IANA assignment, which 8684 §7.2 allows, won't fail it), the class docstring and the two tcp.py sites against the registries' own RFC, and template/module agreement. 5 of 6 tests fail on the parent commit; the agreement check passes there since both sides said 6824 together.

@JarryShaw JarryShaw added docs Pull requests that change documentation only (docs: subject prefix) const Regenerated IANA or vendor constant tables; members keep their numeric values labels Oct 27, 2026
@github-actions github-actions Bot added this to the PyPCAPKit v1.5 milestone Oct 27, 2026
@JarryShaw JarryShaw moved this to In review in PyPCAPKit Oct 27, 2026
@JarryShaw

Copy link
Copy Markdown
Owner Author

Review: NEEDS CHANGES at 296aa57cf (Sonnet). The two-line code change is correct and the RFC relationship independently confirmed (RFC 8684 Proposed Standard March 2020, obsoletes 6824; IANA registry cites 8684 throughout). Four issues, all prose/scope:

  1. "Each assertion fails on the parent commit" overclaims — only 3 of 4 fail; test_the_template_and_the_module_agree passes on main (both sides said 6824 together). It guards against a one-sided fix, not the original defect.
  2. 2 of the 10 remaining 6824 citations in tcp.py are the SAME defect, not legitimate v0-layout documentation — the option-kind map comment and _read_mode_mp's docstring both cite plain RFC 6824 for something RFC 8684 §7.1/Figure 3 also covers identically. No issue tracks these (checked).
  3. Test docstring misstates IANA: claims "every record carries an rfc8684 spec" (false — the 0x9-0xe Unassigned record has none) and "every member comment cites 8684#section-..." (false — Reserved_for_Private_Use cites plain :rfc:8684`` with no section).
  4. Test docstring has counted-number violations ("the two invariants", "installed on one leg only" — also inaccurate, 3 workflow jobs install vendor).

Fix in progress.

@JarryShaw
JarryShaw force-pushed the docs/2330-mptcp-rfc-citation branch from 296aa57 to 4f0d6d7 Compare October 27, 2026 10:58
@JarryShaw

Copy link
Copy Markdown
Owner Author

Amended 296aa57cf → 4f0d6d789: fixed the 2 scope-gap citations in tcp.py (verified against live IANA XML + both RFC texts fetched directly — option kind 30 → 8684, Figure 3 byte-identical modulo indentation), corrected the test docstring's 2 false IANA claims, dropped the counted-number violations (also caught a factual error in my own review: it's 4 workflow jobs installing vendor, not 3), and relaxed the table-wide pin from "equals 8684" to "excludes 6824" per the reviewer's optional nit — RFC 8684 §7.2 allows future registry assignments to cite a different RFC, so the original pin would have broken on a legitimate future update. 6/6 tests pass, transport suite (247 tests) clean.

@JarryShaw

Copy link
Copy Markdown
Owner Author

Review: NEEDS CHANGES at 4f0d6d789 (Sonnet, round 2). Code/tcp.py fixes, RFC/IANA facts, and the relaxed test all independently confirmed correct (1534-test regression, 15 mutation checks, byte-for-byte crawler re-derivation). Two prose issues remain in the test module's own docstring:

  1. The CI sentence is wrong about integration — it has the same latest-interpreter-only condition as test, not an unconditional install. Qualifier needs attaching to both, or the clause dropped (it's been wrong twice now).
  2. Three counted numbers survived from round 1's fix ("the two subtype-agnostic citations", "two places", "the two assertions above").

Fixing both directly.

…2330)

Problem: the class docstring of the MPTCPOption crawler, mirrored into the
generated const module, and two citations in pcapkit/protocols/transport/
tcp.py (the Multipath TCP option-kind map entry, and _read_mode_mp's generic
Figure 3) all cited RFC 6824. IANA's "MPTCP Option Subtypes" and "TCP Option
Kind Numbers" registries cite RFC 8684, which obsoletes 6824 as of 2020-03,
and Figure 3 is identical in both RFCs. The eight other 6824 citations in
tcp.py stay -- those document the legacy v0 wire layouts (the ADD_ADDR IPVer
nibble, the MP_PRIO 4-octet AddrID form) the parser still accepts, which
8684 itself records as removed.

Fix: cite 8684 at all four sites. The crawler/const pair is edited
identically, no re-crawl.

Test: tests/const/test_const_mp_tcp_option_rfc_2330_unit.py pins the table
against the obsoleted RFC rather than a single value (so a legitimate future
IANA assignment to an unassigned subtype, which 8684 section 7.2 allows,
won't fail it), the class docstring and the two tcp.py sites against the
registries' own RFC, and template/module agreement. 5 of 6 tests fail
on the parent commit; the agreement check passes there since both sides
said 6824 together.
@JarryShaw
JarryShaw force-pushed the docs/2330-mptcp-rfc-citation branch from 4f0d6d7 to 0e3b8d0 Compare October 27, 2026 11:25
@JarryShaw

Copy link
Copy Markdown
Owner Author

Amended 4f0d6d789 → 0e3b8d073: fixed the integration CI claim (shares test's latest-interpreter-only condition, not unconditional) and dropped the 3 counted numbers that survived round 1's fix. Also fixed the "5 of 6 assertions" → "tests" nit. Prose-only, 6/6 tests still pass.

All findings across both rounds now addressed.

@github-actions

Copy link
Copy Markdown
Contributor

Coverage: 91.58% (unit tier, Python 3.15, 0e3b8d073, Unit Tests run success)

Package Statements Missed Branches Partial Cover
pcapkit (top level) 104 4 20 2 95.16%
pcapkit/const 19601 881 2620 867 92.12%
pcapkit/corekit 2596 74 818 37 96.51%
pcapkit/dumpkit 282 3 102 3 98.44%
pcapkit/foundation 3029 23 1050 25 98.82%
pcapkit/interface 138 4 52 3 96.32%
pcapkit/protocols 17455 218 4598 185 98.15%
pcapkit/toolkit 914 36 334 10 95.51%
pcapkit/utilities 502 7 144 5 98.14%
pcapkit/vendor 4432 1988 1018 167 51.87%

Per-file detail: the coverage-html artifact of this run.

@JarryShaw

Copy link
Copy Markdown
Owner Author

Ready to merge.

Review: GOOD TO GO (Sonnet, round 2) at 0e3b8d073.
CI: Required checks passed, 0 failures (only the non-blocking experimental GraalPy leg still pending).
Mergeable, 0 unresolved threads.

@JarryShaw JarryShaw added the review: good-to-go Cross-review at the current head says ready; CI state is separate label Oct 27, 2026
@JarryShaw
JarryShaw merged commit fea3246 into main Oct 27, 2026
62 checks passed
@JarryShaw
JarryShaw deleted the docs/2330-mptcp-rfc-citation branch October 27, 2026 15:10
@github-project-automation github-project-automation Bot moved this from In review to Done in PyPCAPKit Oct 27, 2026
@JarryShaw JarryShaw removed the review: good-to-go Cross-review at the current head says ready; CI state is separate label Oct 27, 2026
JarryShaw added a commit that referenced this pull request Oct 28, 2026
Problem: of the 60 pull requests merged in the #2312-#2407 range, only
#2334, #2336, #2337, #2340 and #2348 wrote a 1.5.0 changelog entry, and
#2398 and #2403 only reworded lines that were already there. Every other
user-visible change in the range -- wire-semantics fixes, maker guards,
reassembly behaviour, public-API and error-message changes -- went
unrecorded, so the entry no longer describes the release.

Fix: one entry per user-visible pull request, in each module section's
existing style and ordered by the issue it closes. Two pairs share a
bullet, since each is the direct follow-up of the other: #2393 with
#2401, and #2405 with #2407. The diff on the entry file is purely
additive.

Internal-only work is left out deliberately: dependency and action bumps
(#2387 to #2391), test-only and docs-prose passes (#2333, #2376, #2379,
#2380, #2402), the unreachable-branch removal (#2378), and the #: comment
marker the HIP Group and Packet crawlers now write (#2381). That last one
renders nothing either way: the marker lands inside the generated
_missing_ body, conf.py's exclude-members drops _missing_ from autodoc,
and a comment in a method body is not an attribute comment to begin with.

#2392 and #2403 are recorded together, under Added rather than Fixed, for
the declarations they introduce: __proto_key__ on the seven classes owning
a __proto__ registry (#2392), __proto_dest__ on the four enum registries
and Vendor.PROTO_DEST to generate it (#2403). Both PRs added the autodoc
entries, so both are rendered public attributes. #2392's rejection-message
change is deliberately not recorded as a fix: the bare "code must be ..."
text it prefixed came from _check_code, which #2193 introduced and which
is in no release tag -- absent at v1.5.0b14 -- so no released version ever
emitted it. #2403 is no longer skipped as internal because it reworded an
existing bullet to name __proto_dest__ while nothing credited the
attribute's introduction.

Four claims are corrected against the source rather than carried over:
FTP_DATA shipped in pcapkit/protocols/application/ftp.py from 1.0.0, not
1.4.0 (class FTP_DATA(Raw) is there at v1.0.0); #2365's pre-fix fallback
read cmmd.value, so a .value-carrying object was accepted unchecked
rather than raising; #2399 left the dpkt adapter and the adapters'
ModuleNotFound raises alone, so it claims no universal prefix; and
#2397's old tail did name the version it got, so the entry quotes it and
gains the :issue:`2302` it was missing. #2370's "a Section Header Block
... still fails" sentence is dropped: #2369 settles the byte order first,
and an SHB built from raw octets with ctx=None now rebuilds byte-exact in
both byte orders.

CHANGELOG.md is regenerated with util/changelog_md.py.

Test: tests/project/ in full, 0 failures, including test_changelog_md.py's
in-step and supported-subset checks; util/changelog_md.py --check reports
the two files in step; the entry parses under docutils with no structural
warning.
JarryShaw added a commit that referenced this pull request Oct 28, 2026
Problem: of the 60 pull requests merged in the #2312-#2407 range, only
#2334, #2336, #2337, #2340 and #2348 wrote a 1.5.0 changelog entry, and
#2398 and #2403 only reworded lines that were already there. Every other
user-visible change in the range -- wire-semantics fixes, maker guards,
reassembly behaviour, public-API and error-message changes -- went
unrecorded, so the entry no longer describes the release.

Fix: one entry per user-visible pull request, in each module section's
existing style and ordered by the issue it closes. Three pairs share a
bullet, since each is the direct follow-up or counterpart of the other:
#2393 with #2401, #2405 with #2407, and #2392 with #2403. The diff on the
entry file is purely additive.

Internal-only work is left out deliberately: dependency and action bumps
(#2387 to #2391), test-only and docs-prose passes (#2333, #2376, #2379,
#2380, #2402), the unreachable-branch removal (#2378), and the #: comment
marker the HIP Group and Packet crawlers now write (#2381). That last one
renders nothing either way: the marker lands inside the generated
_missing_ body, conf.py's exclude-members drops _missing_ from autodoc,
and a comment in a method body is not an attribute comment to begin with.

#2392 and #2403 are recorded together, under Added rather than Fixed, for
the declarations they introduce: __proto_key__ on each class owning a
__proto__ registry (#2392), __proto_dest__ on the enum registries and
Vendor.PROTO_DEST to generate it (#2403). The bullet names those classes
and registries rather than counting them, per the no-counted-numbers rule
for the unreleased entry. Both PRs added the autodoc entries, so both are
rendered public attributes. #2392's rejection-message
change is deliberately not recorded as a fix: the bare "code must be ..."
text it prefixed came from _check_code, which #2193 introduced and which
is in no release tag -- absent at v1.5.0b14 -- so no released version ever
emitted it. #2403 is no longer skipped as internal because it reworded an
existing bullet to name __proto_dest__ while nothing credited the
attribute's introduction.

Four claims are corrected against the source rather than carried over:
FTP_DATA shipped in pcapkit/protocols/application/ftp.py from 1.0.0, not
1.4.0 (class FTP_DATA(Raw) is there at v1.0.0); #2365's pre-fix fallback
read cmmd.value, so a .value-carrying object was accepted unchecked
rather than raising; #2399 left the dpkt adapter and the adapters'
ModuleNotFound raises alone, so it claims no universal prefix; and
#2397's old tail did name the version it got, so the entry quotes it and
gains the :issue:`2302` it was missing. #2370's "a Section Header Block
... still fails" sentence is dropped: #2369 settles the byte order first,
and an SHB built from raw octets with ctx=None now rebuilds byte-exact in
both byte orders.

CHANGELOG.md is regenerated with util/changelog_md.py.

Test: tests/project/ in full, 0 failures, including test_changelog_md.py's
in-step and supported-subset checks; util/changelog_md.py --check reports
the two files in step; the entry parses under docutils with no structural
warning.
JarryShaw added a commit that referenced this pull request Oct 28, 2026
Problem: of the 60 pull requests merged in the #2312-#2407 range, only
#2334, #2336, #2337, #2340 and #2348 wrote a 1.5.0 changelog entry, and
#2398 and #2403 only reworded lines that were already there. Every other
user-visible change in the range -- wire-semantics fixes, maker guards,
reassembly behaviour, public-API and error-message changes -- went
unrecorded, so the entry no longer describes the release.

Fix: one entry per user-visible pull request, in each module section's
existing style and ordered by the issue it closes. Three pairs share a
bullet, since each is the direct follow-up or counterpart of the other:
#2393 with #2401, #2405 with #2407, and #2392 with #2403. The diff on the
entry file is purely additive.

Internal-only work is left out deliberately: dependency and action bumps
(#2387 to #2391), test-only and docs-prose passes (#2333, #2376, #2379,
#2380, #2402), the unreachable-branch removal (#2378), and the #: comment
marker the HIP Group and Packet crawlers now write (#2381). That last one
renders nothing either way: the marker lands inside the generated
_missing_ body, conf.py's exclude-members drops _missing_ from autodoc,
and a comment in a method body is not an attribute comment to begin with.

#2392 and #2403 are recorded together, under Added rather than Fixed, for
the declarations they introduce: __proto_key__ on each class owning a
__proto__ registry (#2392), __proto_dest__ on the enum registries and
Vendor.PROTO_DEST to generate it (#2403). The bullet names those classes
and registries rather than counting them, per the no-counted-numbers rule
for the unreleased entry. Both PRs added the autodoc entries, so both are
rendered public attributes. #2392's rejection-message
change is deliberately not recorded as a fix: the bare "code must be ..."
text it prefixed came from _check_code, which #2193 introduced and which
is in no release tag -- absent at v1.5.0b14 -- so no released version ever
emitted it. #2403 is no longer skipped as internal because it reworded an
existing bullet to name __proto_dest__ while nothing credited the
attribute's introduction.

Four claims are corrected against the source rather than carried over:
FTP_DATA shipped in pcapkit/protocols/application/ftp.py from 1.0.0, not
1.4.0 (class FTP_DATA(Raw) is there at v1.0.0); #2365's pre-fix fallback
read cmmd.value, so a .value-carrying object was accepted unchecked
rather than raising; #2399 left the dpkt adapter and the adapters'
ModuleNotFound raises alone, so it claims no universal prefix; and
#2397's old tail did name the version it got, so the entry quotes it and
gains the :issue:`2302` it was missing. #2370's "a Section Header Block
... still fails" sentence is dropped: #2369 settles the byte order first,
and an SHB built from raw octets with ctx=None now rebuilds byte-exact in
both byte orders.

CHANGELOG.md is regenerated with util/changelog_md.py.

Test: tests/project/ in full, 0 failures, including test_changelog_md.py's
in-step and supported-subset checks; util/changelog_md.py --check reports
the two files in step; the entry parses under docutils with no structural
warning.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

const Regenerated IANA or vendor constant tables; members keep their numeric values docs Pull requests that change documentation only (docs: subject prefix)

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

docs(vendor,const): MPTCPOption's docstring cites RFC 6824, which RFC 8684 obsoletes

1 participant