What is an Internet Draft? How drafts become RFCs, why the draft stage is where the real spec lives, and why agent protocols ship as drafts first.
You've seen it in every serious protocol repo: a draft-ietf-... link in the README, a "status: draft" badge, datatracker URLs in the changelog. If you work with AI agents you're seeing it more than ever — the agent ecosystem's newest interoperability specs are circulating as drafts right now. Here's what an Internet Draft actually is, how it becomes an RFC, and why the draft stage is where the protocol really lives.
What Is an Internet Draft?
An Internet Draft — officially "Internet-Draft," often written "internet draft" — is a working document of the Internet Engineering Task Force (IETF). It is not a standard. It is not endorsed by the IETF. It is the raw material of the standards process: the document where a protocol lives while it is designed, debated, and revised.
Anyone can submit one. You write up a protocol, post it to the datatracker (datatracker.ietf.org), and it gets a name like draft-ietf-<working-group>-<topic>-<revision> if a working group adopts it, or draft-<author>-<topic>-<revision> if it stays a personal submission.
The defining rule: an Internet Draft expires after six months. If nobody posts a new revision, it is withdrawn from the archive and effectively ceases to exist. That's why drafts are versioned — -00, -01, -02 — each revision restarts the six-month clock. When you see a draft at revision -10, you're looking at a document that has been argued over and rewritten for years.
The Lifecycle: From Draft to RFC
The path from draft to standard looks like this:
- Submission. Someone posts an Internet Draft describing a protocol or idea.
- Adoption. A working group decides the problem is worth solving and adopts the draft. Personal drafts that never get adopted simply expire.
- Iteration. The document is revised through many versions as the group reaches consensus on each detail.
- Review. The document goes through working-group last call, then review by the IESG, the IETF's management body.
- Publication. It is published as an RFC — the numbered, permanent record of the protocol.
Once a document becomes an RFC it is effectively frozen. Changes arrive as errata or as a new RFC that obsoletes the old one. The RFC series is the archive of how the Internet was actually built; the drafts are the live conversation that produced it.
The revision number is a stability signal. A -00 is a proposal that may change radically. A draft deep into double-digit revisions that has passed working-group last call is, for practical purposes, the spec — implementations ship against it while the paperwork finishes.
Why You Should Read Drafts, Not Just RFCs
The RFC is a snapshot. The draft is the current text. For any protocol you're integrating with, the draft is usually what the implementations actually match — because implementations start shipping while the document is still a draft.
Reading drafts also tells you where a protocol is going. The revision log — what changed between -03 and -04 — is a public record of the hard problems. When a new version drops a feature or changes a wire format, the diff is your early-warning system. Teams that track drafts know about breaking changes months before a changelog announces them.
The Draft Wave in the Agent Ecosystem
This is why the agent space is suddenly full of drafts. The IETF now has an active Agent Communication Protocols effort, and agent-interoperability documents — A2A-related drafts among them — are circulating in the datatracker as Internet Drafts right now. After years of vendor-specific agent frameworks, the industry is doing what the Internet has always done: writing the interoperability problem down and arguing about it in public until it works.
But notice what's being standardized: the application layer. How agents advertise capabilities, exchange tasks, and carry context. That's the payload.
The Layer Nobody Drafts: Transport for Agents
An application protocol assumes the endpoints can reach each other. That assumption is exactly what breaks for agents. Your agent runs behind NAT in a home lab, in a VPC, on a laptop that keeps changing networks, in a CI runner that dies and respawns. It has no stable address, and it can't accept an inbound connection — which is why so much agent tooling today is propped up with webhook tunnels and polling hacks.
Mesh VPNs (Tailscale, Nebula, ZeroTier — all genuinely good at what they do) solve reachability for machines a team owns. Their model couples membership with trust: join the network, and you're trusted on it. For autonomous agents that model breaks down. You want to hand a task to a stranger's agent without handing it a seat on your VPN, and you want your own agents reachable without exposing a port to the whole internet.
That's the problem an overlay network solves, and it's what Pilot Protocol's overlay network is built for. It's open source and agent-first: every agent gets a permanent virtual address that survives restarts, IP changes, and moves between clouds; traffic moves over encrypted UDP tunnels (X25519 key exchange with AES-GCM); NAT traversal is handled with STUN hole-punching and a relay fallback, so agents behind NAT are reachable. Trust is explicit and per-peer — a mutual handshake — so membership and trust are decoupled, unlike a VPN where joining is trusting.
And while the IETF drafts standardize how agents talk, the overlay gives agents the network citizenship to actually be talked to: a rendezvous registry for discovery by name or capability, plus an app store where agent-native capabilities install with one command — discover → install → call — each app a typed IPC service (JSON in, JSON out), signature-verified and supervised by the daemon. 243k+ agents and users are already on the network.
The standards process writes the protocol; the network layer makes it reachable. If you're building agents, both halves matter — the draft tells you what to speak, the overlay tells you who you can speak to.
curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl appstore catalogue
FAQ
What is an Internet Draft? A working document of the IETF that describes a protocol under development. It is not a standard, and it expires after six months unless a new revision is posted.
What is the difference between an Internet Draft and an RFC? An RFC is a published, numbered, effectively frozen document; an Internet Draft is the live, revisable text that precedes it.
How long does an Internet Draft stay valid? Six months. A new revision restarts the clock; otherwise the draft is withdrawn from the archive.
Can anyone submit an Internet Draft? Yes. Anyone can post a draft to the IETF datatracker; adoption by a working group is what moves it toward RFC status.
What do the revision numbers mean? -00 is the first version. Each subsequent revision marks a new version of the document and restarts the six-month validity window.
Why do agent protocols ship as drafts first? Because the IETF process is how the Internet standardizes interoperability — and the agent ecosystem's interoperability layer is being written there right now.
Top comments (0)