Skip to content

Write a pcapkit/vendor/tls crawler for ContentType and HandshakeType #2495

Description

@JarryShaw

Summary

pcapkit.const.tls.content_type.ContentType and pcapkit.const.tls.handshake_type.HandshakeType (#2441) both cite a live IANA TLS-parameters registry and claim full coverage, but no pcapkit/vendor/tls/ crawler exists to back them -- flagged in #2441's own review and merged on the stated reasoning that the crawler would follow.

Why it matters

Every other const module is generated and re-crawled; these two are hand-maintained, so a future IANA addition silently goes stale.

Next step

Write pcapkit/vendor/tls/content_type.py and handshake_type.py following the existing crawler template (pcapkit/vendor/default.py), add both to pcapkit/vendor/__init__.py's __all__, and regenerate the two const modules from them.

Activity

  1. added
    choreMaintenance work: tooling, repo hygiene, no library behaviour change
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 31, 2026
  2. moved this to Pending in PyPCAPKiton Oct 31, 2026
  3. JarryShaw commented on Oct 31, 2026

    @JarryShaw
    OwnerAuthor

    ALL const MUST have its own vendor crawler.

    If it's a hand tailored/maintained registry, use the DATA attribute for the crawler. There're existing presidents for this and the current convention doc on main is incorrect. There's no exception from this ruling.

  4. JarryShaw commented on Oct 31, 2026

    @JarryShaw
    OwnerAuthor

    Ruling reconciled: no exception. ARPHRD still needs a crawler -- the DATA-attribute pattern already used elsewhere for hand-tailored registries, not a live-URL scrape. Reworking const-vendor-pairing.rst to drop the exception section and documenting that pattern, plus writing the ARPHRD crawler, against the real precedent rather than guessing at it.

  5. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 31, 2026
  6. JarryShaw commented on Oct 31, 2026

    @JarryShaw
    OwnerAuthor

    ARPHRD side done as PR #2497: new DATA-attribute crawler, const module regenerated as a no-op, doc rewritten per the no-exception ruling. TLS crawler (the other half of this issue) is separate work, not started.

  7. moved this from Pending to WIP in PyPCAPKiton Oct 31, 2026
  8. added
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    and removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 31, 2026
  9. JarryShaw commented on Oct 31, 2026

    @JarryShaw
    OwnerAuthor

    Reopening: PR #2497 closed this automatically via the "Closes #2495 in part" keyword, but the TLS crawler (the other half) is not done. Relabelling pending since no worker is on it.

  10. moved this from Done to Pending in PyPCAPKiton Oct 31, 2026
  11. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Oct 31, 2026
  12. moved this from Pending to WIP in PyPCAPKiton Oct 31, 2026
  13. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Nov 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    choreMaintenance work: tooling, repo hygiene, no library behaviour change

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions