authority-form -- the RFC 9112 §3.2.3 corpus

PROVENANCE: OURS, HAND-DERIVED FROM RFC 9112 §3.2.3 (not extracted from any text)

This directory is UNLIKE test/conformance/rfc3986/, whose every file is DERIVED from
the vendored RFC 3986 text by cmake/UriCorpus.cmake and re-derived by the lane
uri.harness.corpus-provenance. RFC 9112 is NOT vendored in this repo (only RFC 3986
is, at test/vendor/rfc3986.txt), and it lists no example targets, so there is nothing
to extract: corpus.scm is HAND-AUTHORED from RFC 9112 §3.2.3

    authority-form = uri-host ":" port

which reuses RFC 3986 §3.2's `host` and `port` verbatim. It is the sibling of
test/conformance/host/ and test/conformance/charset/, each a hand-derived
corpus rather than a generated one.

It is therefore a SEPARATE provenance with a SEPARATE count: it is never
averaged into the normative §5.4 / §1.1.2 figures or the charset/host corpora, and it is NOT guarded by the corpus-provenance lane.

WHAT IS HERE

  corpus.scm   authority-form targets, each graded against BOTH entry points at once:
               the LENIENT `uri-parse-authority-form` and the STRICT
               `uri-parse-authority-form-validate`. Every input is the RAW target --
               no scheme, no "//", no "http://" prefix -- so the authority begins at
               OFFSET 0 and every recorded offset is already the caller's.

WHAT authority-form IS

  A CONNECT request-target: `host:port`, with no scheme and no "//". It is a strict
  SUBSET of RFC 3986 `authority = [ userinfo "@" ] host [ ":" port ]` --

    - NO userinfo (§3.2.3 drops the `[ userinfo "@" ]` prefix);
    - a REQUIRED, non-empty port (the ":" is not optional and §3.2.3's prose is
      MUST-level that a real port is sent -- so `host:` with an empty port, which RFC
      3986's `port = *DIGIT` permits, is INVALID authority-form); and
    - NO path/query/fragment (it is neither a URI nor a relative-ref).

  The LENIENT form is non-validating, like `uri-parse`: it splits the authority and
  rejects ONLY a trailing path/query/fragment (`not-authority-form`, at the first byte
  past the authority). The STRICT form adds, LEFTMOST-first: `userinfo-forbidden`
  (the "@"), the RFC 3986 host grammar via `validate-authority` (a host/port charset
  fault, e.g. `invalid-reg-name`), and `port-required` (at the target's end).

HOW IT IS GUARDED

  - the corpus IS the RFC 9112 §3.2.3 spec table: each row's (lenient, strict) verdict
    with its exact code and ABSOLUTE offset is asserted through the two entry points by
    the lane uri.unit.authority-form. Unlike the host corpus, there is no fourth
    oracle here: the HOST grammar's correctness already rides on the host corpus's
    three-provenance guard (validate-authority <-> (uri test host-oracle) <-> the
    host corpus), and
    authority-form adds only the splice/-2 re-map, the `not-authority-form` floor, and
    the two §3.2.3 rules -- a small policy guarded by this table plus mutation
    witnesses (the -2 re-map, the leftmost host < port order, the bracket-aware userinfo
    rule, the `host:` empty-port boundary, and the not-authority-form floor).
  - the leftmost order userinfo -> host -> port is pinned across three rows:
    `user@ho st:443` and `user@host` pin userinfo BEFORE host and BEFORE port (userinfo
    wins over a later host space / a missing port), and `ho st` (a bad host with NO
    port) pins host BEFORE port -- a validator that checked port before the host grammar
    would report port-required@5 instead of the leftmost invalid-reg-name@2 and redden.
  - the bracket-aware userinfo rule is pinned both ways: `user@[::1]:443` (a real
    userinfo "@" BEFORE the "[") is userinfo-forbidden, while `[a@b]:443` (an "@" INSIDE
    the literal) is NOT userinfo -- it falls through to the host grammar (invalid-userinfo,
    as the host corpus reports for http://[a@b]). A first-"@"-anywhere scan would mis-fire
    userinfo-forbidden on the second and redden.

A KNOWN ABNF EDGE, DELIBERATELY NOT A ROW

  `:443` (empty host, present port) is ACCEPTED by both forms: `uri-host` includes
  `reg-name = *( ... )`, which the ABNF permits to be EMPTY, so an empty host is
  grammatically valid (adjudicate against the ABNF, not intuition).
  It is left out of the corpus rather than implying an empty-host CONNECT target is
  meaningful; the port-required boundary is pinned by `host:` and `host` instead.

WHAT IS NOT HERE, AND WHY

  origin-form and absolute-form request-targets already parse in `relative-ref` and
  `uri` mode; asterisk-form (`*`) is a one-byte literal the caller checks, not a
  parse. RFC 9112 is not vendored and no authority-form generator exists;
  this corpus is hand-derived, as the charset and host corpora are.
