Primary Domain
Internet Standards
Within the Primary Domain facet, Internet Standards intelligence groups reporting by primary domain so readers can follow a focused area of internet infrastructure, governance, connectivity markets, or digital capital. The page brings together related articles, public evidence, institutions, companies, people, regional exposure, operating dependencies, and market context that may otherwise sit across separate category pages. It explains the domain, the likely actor class, the market or governance context, and the source material readers should use when comparing signals. Operators, analysts, and governance readers can see how the same domain appears across events, profiles, market shifts, public-source evidence, regional dependencies, and longer-cycle infrastructure decisions over time.
IETF
Daniel Fox Franke and the NTS Unique Identifier That Did Not Name the Client
A number can identify a conversation without identifying either speaker. In the time-security design co-authored by Daniel Fox Franke, the client invents a long random value for one request, the server returns it unchanged, and the client rejects a response that cannot match that…
IETF
K. K. Ramakrishnan and the Repeated ECE Flag That Was Not a Congestion Count
One marked data packet can leave a trail of ECE-bearing acknowledgements. In the classic TCP mechanism co-authored by K. K. Ramakrishnan, that repetition is intentional: the receiver keeps a congestion echo asserted until the sender’s CWR response closes the interval. Counting…
IETF
Bob Hinden and the Zero Payload Length That Did Not Mean an Empty Packet
An IPv6 capture can present an apparently decisive fact: the base header says the payload length is zero. Bob Hinden’s standards work helps show why that observation is not yet a conclusion. When a Hop-by-Hop Options header follows and bytes remain, zero is a dispatch value: the…
IETF
Ralph Droms and the DHCP Acknowledgement That Was Not Address Ownership
A DHCPACK can feel like a title deed: the network has answered, the client has configured an address, and traffic begins. Ralph Droms's DHCP specification defines something more disciplined. In the ordinary allocation path, the acknowledgement commits a server-side binding and…
IETF
Scott Rose and the Authenticated Data Bit That Was Not End-to-End Proof
The `AD` flag in a DNS response can carry a valuable result: a validating recursive resolver believes the relevant answer and authority data is authentic. It can also be dangerously overread. The flag does not authenticate its own trip to a client, describe every validation…
IETF
Nat Sakimura and the Critical Header a Valid Signature Could Not Ignore
A JSON Web Signature can pass its mathematical check and still be unusable. RFC 7515 made room for that outcome through `crit`: an integrity-protected list that tells a verifier which extensions it must understand before it may accept the message. The distinction is easy to miss…
IETF
Justin Richer and the Active Token That Could Not Approve the Request
An OAuth resource server asks about a bearer token and receives the most reassuring two-word answer in the exchange: `active: true`. The token is current, the authorization server recognizes it and the request can move forward. Yet one decision is still missing. The introspection…
IETF
Rifaat Shekh-Yusef and the Nonce Count That Could Not Number the Transaction
The first authenticated request carries `nc=00000001`. It looks uncannily like the beginning of a transaction ledger: neat, monotonic and attached to a credential check. But in the HTTP Digest scheme edited by Rifaat Shekh-Yusef, that small hexadecimal field has a narrower…
IETF
Tatu Ylonen and the SSH Window That Could Not Acknowledge the Command
An automation runner pushes a command through SSH, sees the channel window reopen and watches the encrypted connection close cleanly. The dashboard marks the job complete. Yet none of those events says that the remote application committed the intended change. Tatu Ylonen’s RFC…
IETF
Tim Bray and the Duplicate JSON Name That Could Not Be One Value
A request crosses an API gateway, an authorization service and an audit store. Each component says it parsed the same JSON entity successfully. Yet one kept the last occurrence of a name, another rejected the entity, and a third retained both. The disagreement began before…
IETF
Peter Saint-Andre and the Certificate Match That Could Not Choose the Service
The certificate was valid for the name the client checked. That sentence sounds like the end of authentication, but it hides the first and more consequential choice: why did the client check that name? Peter Saint-Andre and Rich Salz make the order explicit in RFC 9525. The…
IETF
Alexey Melnikov and the Authentication Success That Could Not Grant a Service
The status light turned green. The credentials had been accepted, an identity had been associated with the session, and the exchange was over. Yet the next operation could still be refused without contradiction. The architecture Alexey Melnikov and Kurt Zeilenga set out in RFC…
IETF
Alissa Cooper and the Privacy Review That Could Not Issue a Safety Certificate
The review workbook had answers in every cell: identifiers listed, observers named, retention discussed, defaults justified. What it did not have was a truthful final cell marked “safe”. Alissa Cooper and her co-authors designed RFC 6973 to make privacy reasoning inspectable, not…
IETF
Barry Leiba and the Capital Letters That Could Not Create Authority
A requirements scanner finds `MUST` in a specification and reports certainty. It has found a word, not yet an obligation. Barry Leiba’s RFC 8174 drew a clean boundary around the special vocabulary of BCP 14, but the boundary works in both directions: capitals activate defined…
IETF
Michelle Cotton and the Code Point That Arrived Before Its RFC
The awkward moment comes before a standard is finished: two implementations need the same numeric language to meet, but the registry would normally wait for publication. Michelle Cotton’s RFC 7120 turned that timing gap into a visible, expiring state. Its most important word is…
IETF
Erik Kline and the DHCP Code That Was Assigned but Not Vacant
A standards registry said 160; a live network said the number already had another life. The resulting collision did not make the registry irrelevant, nor did it make undocumented use legitimate. It showed something more operationally useful: an authoritative assignment can define…