Methodology
Every page on protocols.page is sourced directly from official specifications. If a protocol has an RFC, we cite the RFC. If it has a W3C Recommendation, we cite that. No secondary sources, no vendor blog posts.
Where the data comes from
The primary source for internet protocols. Status codes, headers, wire formats, and behavior descriptions cite specific RFC numbers and sections.
HTML Living Standard, WebRTC, WebTransport, ActivityPub, CORS, and other web platform specifications.
AMQP, MQTT 5.0, SAML, and enterprise integration standards published by OASIS.
For protocols without an RFC: yaml.org 1.2.2 spec, atproto.com spec, nostr NIPs, GraphQL Foundation spec, protobuf.dev.
Port number assignments, MIME types, protocol parameters, and service names from the official IANA registry.
How protocols are organized
Protocols are grouped into 5 layers based on their role in the computing stack. This is a practical grouping for developers, not a strict OSI model mapping.
| Layer | What belongs here |
|---|---|
| Internet Protocols | Core networking, transport, security, and name resolution. |
| Application Protocols | API styles, messaging protocols, and authentication frameworks. |
| Data Formats | Serialization formats and standards for structuring data. |
| AI & Agent Protocols | Protocols designed for AI systems and agent communication. |
| Future Protocols | Active IETF drafts and community standards gaining adoption. |
What each page covers
Overview
What the protocol does, what problem it solves, and when to use it. Sourced from the spec introduction.
Version history
How the protocol has evolved across versions, with the year and the key changes each version introduced.
Quick reference
A table of the most-used fields, ports, codes, or parameters with their values and spec citations.
Sub-sections
Status codes, wire types, record types, grant types, exchange types – depending on the protocol's structure.
Examples
Real wire format examples, request/response pairs, or code samples illustrating correct usage.
Related protocols
Links to protocols that are commonly compared, combined with, or used alongside this one.
How we decide what to add
A protocol is added when it has an official specification we can source from, and when developers regularly encounter it and look it up. We prioritize breadth of accurate coverage over depth of invented detail.
Protocols marked proposed are active IETF drafts or community specs without a final RFC. The content is sourced from the current draft version, which is noted on the page.