RFCs are dense but they are not difficult, and they follow conventions that make them scannable once you know them.

the keywords are load-bearing#

RFC 2119 defines a small vocabulary, and in a specification these words are technical terms, not English:

• MUST / REQUIRED / SHALL — absolute requirement. Violating it makes your implementation non-conforming.
• MUST NOT / SHALL NOT — absolute prohibition.
• SHOULD / RECOMMENDED — there may be valid reasons to ignore this, but understand the implications first. In practice: everyone does it, and if you do not, something will break eventually.
• SHOULD NOT — same, inverted.
• MAY / OPTIONAL — genuinely optional. Critically: an implementation that does not do it must interoperate with one that does, and vice versa.

When reading, look for the capitalised words first. They are the actual requirements; everything around them is explanation. Skimming an RFC by jumping between MUSTs is a legitimate and efficient way to read one.

the structure is consistent#

Abstract — one paragraph. Read it to decide whether you want this document.

Introduction / Terminology — read the terminology. Specifications define ordinary-looking words precisely, and misreading one is the most common source of implementation bugs.

The body — the actual protocol.

Security Considerations — mandatory in every RFC and consistently the most interesting section. It is where the authors say what they could not fix, what attacks apply, and what implementers get wrong. If you read one section, read this one.

IANA Considerations — registries. Where you find the canonical list of registered values, which is often the thing you actually needed.

ABNF grammar — usually an appendix. The precise syntax, in a formal grammar. If you are writing a parser, this is authoritative and the prose is not.

the things that trip people up#

Updated and obsoleted. An RFC is never edited. It is replaced. Always check the header for "Obsoleted by" — implementing an obsolete specification is a common and embarrassing mistake, and HTTP/1.1 alone has been re-specified several times.

Errata. Published RFCs have errata filed against them. Check them; some are substantive corrections.

Not all RFCs are standards. The series includes Informational, Experimental, Best Current Practice, Historic, and April Fools jokes. The status is in the header. "It's an RFC" is not the same as "it's a standard."

The grammar wins over the prose. Where the ABNF and the description disagree, the ABNF is normative. This is the single most useful thing to know when a specification appears ambiguous.

the reading strategy#

For a specification you need to implement:

1. Abstract, to confirm it is the right document.
2. Check the header for obsoletions, then the errata.
3. Terminology section, properly.
4. Security Considerations — early, not last. It tells you what the hard parts are before you have written anything.
5. Skim for MUST and MUST NOT to get the shape of the requirements.
6. Then the relevant sections in detail, with the ABNF beside you.

That is maybe ninety minutes for a substantial specification, and it is dramatically cheaper than the alternative, which is discovering the requirements one interoperability bug at a time.

why bother#

Because the specification is the only source that is actually authoritative. Blog posts, Stack Overflow answers and library documentation are all someone's interpretation, and interpretations drift.

When two implementations disagree — and they will — the specification is what settles it. Being the person on the team who can read one and say "we are wrong, section 4.2 says the header is case-insensitive" is a genuinely useful thing to be, and it costs one afternoon of learning the conventions.

the canon#

RFC 1149 — "A Standard for the Transmission of IP Datagrams on Avian Carriers." IP over carrier pigeon. Specifies encapsulation, MTU, and the failure characteristics. Notably: it was actually implemented and tested in Bergen in 2001, achieving a 55% packet loss rate and ping times measured in hours.

RFC 2324 — the Hyper Text Coffee Pot Control Protocol, which gave the world HTTP 418 "I'm a teapot." Still returned by a nonzero number of production servers and still occasionally proposed for removal, which reliably generates more discussion than any real feature.

RFC 1925 — "The Twelve Networking Truths." Not a joke, exactly. A list of things that are simultaneously funny and among the most useful engineering aphorisms ever written:

(3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.

(6a) It is always possible to add another level of indirection.

(11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.

Number 11 is the most predictive sentence in computing.

RFC 748 — TELNET RANDOMLY-LOSE Option, the first April Fools RFC, which parodied the specification format so precisely that it reads as a real document until you notice what it specifies.

why they are well written#

Here is the thing: a joke specification only works if the reader can follow the technical content exactly. The humor lives in the gap between rigorous form and absurd content, and the gap only exists if the form is genuinely rigorous.

So the author cannot hide behind jargon. Cannot be vague. Cannot leave the failure modes unspecified, because the failure modes are the joke.

RFC 1149 specifies the MTU, the encapsulation, the retransmission behavior, and the security considerations. It is a more complete specification of a transport protocol than a lot of real protocol documents, in one page.

what to steal#

Specify the failure modes. The joke RFCs always do, because failure is funny. Real specifications frequently do not, because failure is embarrassing. Failure is also the part your implementer most needs.

Be short. Every one of these fits on a page or two. Length is not thoroughness.

Use concrete examples. The absurd ones are memorable; ordinary concrete ones are just as clear and less funny, which is fine.

Write the security considerations section honestly. RFC 1149's is a single sentence about the possibility of the carrier being intercepted by a predator. It is more informative than a great many real ones, which say "security considerations are out of scope for this document" — a sentence that should be banned.

the serious point#

Technical writing quality is not about vocabulary or formality. It is about whether the reader can reconstruct what you meant.

The joke RFCs are readable because their authors were writing for an audience they wanted to make laugh, which requires being understood. Most specification authors are writing for an audience they want to satisfy, which does not.

If you want to test whether your specification is clear, hand it to someone and ask them to implement it without asking you a question. Every question they need to ask is a defect.

The pigeon RFC would pass that test. Most of what I have written would not.

the tradition#

It continues, annually, and it is one of the better things about a standards organization that could easily have become entirely humorless.

An institution that can laugh at its own form is one that understands the form is a tool rather than a ritual. That is worth more than it sounds.

It is still worth understanding what it actually changed, because a few of the consequences affect how you build.

the problem it solved#

HTTP/2 introduced multiplexing: many logical streams over one TCP connection. That fixed head-of-line blocking at the HTTP layer.

It did not fix it at the TCP layer. TCP delivers bytes in order. If one packet is lost, everything behind it waits, including data for streams that were completely unaffected. On a lossy connection — mobile, congested wifi — HTTP/2 could be worse than HTTP/1.1 with six connections, because one loss stalled everything instead of one sixth of everything.

QUIC moves the transport to UDP and implements reliability, ordering, and congestion control per stream. A lost packet stalls only the stream it belonged to.

what else came with it#

Encryption is mandatory and integrated. TLS 1.3 is part of the protocol rather than a layer on top. The handshake is one round trip, or zero for a resumed connection.

Connection migration. A QUIC connection is identified by a connection ID, not by the four-tuple of IP addresses and ports. Change networks — wifi to cellular — and the connection survives. Your download does not restart.

This is the feature users notice without knowing why. Walking out of a building while a video plays used to stall it.

Better loss recovery. QUIC distinguishes between packet loss and reordering more accurately than TCP, and its acknowledgment format carries more information. Recovery is faster.

Evolvability. TCP is implemented in kernels and middleboxes and cannot change, because the internet is full of devices that will drop anything unfamiliar. QUIC is in userspace and encrypted, so its internals are invisible to middleboxes and can actually be updated.

That last point is arguably the most important long-term consequence. Transport protocol ossification was a genuine crisis and QUIC is the escape hatch.

the practical consequences for you#

Domain sharding is now actively harmful. Splitting assets across static1.example.com and static2.example.com was a workaround for HTTP/1.1's connection limit. Under HTTP/2 it was pointless. Under HTTP/3 it is worse than pointless, because each domain requires a separate connection with a separate handshake and separate congestion state.

One origin. If you still have sharding from a 2014 optimization guide, remove it.

Concatenating and spriting are counterproductive. Same reasoning. Many small files multiplex fine and cache better individually.

Priority matters and is under-configured. HTTP/3 has an extensible priority scheme. Most servers use defaults. If you have a page where certain resources are critical, priority hints (fetchpriority) are worth setting and are widely supported.

UDP blocking is real but small. Some corporate networks block UDP/443. Clients fall back to HTTP/2 automatically, so this is a performance issue rather than a correctness one. Do not build anything that requires HTTP/3.

Your observability may not see it. A lot of network monitoring tooling was built for TCP. Check whether your tools actually understand QUIC or are silently reporting nothing.

the parts that were harder than expected#

CPU cost. QUIC's userspace implementation and per-packet encryption use more CPU than kernel TCP. This has improved substantially with offload support and better implementations, and it is a real cost at high volume.

Middlebox hostility. Some networks throttle or block UDP because it looks like something they should throttle. This is improving as QUIC becomes normal traffic.

Debugging is harder. You cannot read a QUIC connection with tcpdump the way you could read HTTP/1.1. qlog and browser devtools help. The tooling is younger.

the assessment#

For a user on a good connection, HTTP/3 is roughly a wash. For a user on a bad connection — mobile, congested, high latency, lossy — it is a substantial improvement, and those users are a large fraction of the world.

That is exactly the right kind of improvement: invisible to the people who were already fine, meaningful to the people who were not.

Enable it, remove your HTTP/1.1-era workarounds, and go back to not thinking about the transport layer.

WSL is open source#

The Windows Subsystem for Linux is now open source at github.com/microsoft/WSL. Not all of it — some Windows-side components remain closed — but the substantial majority, including the init system, the networking daemons, and the file sharing layer.

This was the single most requested item on the WSL issue tracker for years. The practical effect is that people can finally debug the parts of WSL that go wrong, which historically meant filing an issue and waiting.

The strategic read: WSL won. It is how a very large number of developers run Linux tooling on a Windows machine, it removed most of the reason to dual-boot, and open-sourcing it costs Microsoft nothing now that the position is secure. It is a mature move from a company that spent the nineties doing the opposite.

GitHub Copilot coding agent#

Copilot gets a delegated mode: assign an issue to it, and it opens a pull request. It runs in GitHub Actions, follows repository instructions in .github/copilot-instructions.md, and its pull requests go through normal review and CI.

Notably it cannot approve its own pull requests and its Actions runs require approval. Those are the correct guardrails and it is good that they shipped with them rather than after an incident.

The integration point is the interesting bit. An agent that operates on issues and pull requests slots into a workflow every team already has, rather than requiring a new one. That is a much lower adoption barrier than "install this IDE."

MCP in Windows#

Windows gets native support for the Model Context Protocol: an MCP registry, built-in servers exposing filesystem, windowing, and shell capabilities, and a permission model gating what an agent can reach.

An operating system vendor adopting a protocol that a model company published six months ago is fast by any standard. It also tells you Microsoft has concluded that the agent-to-system interface is going to be standardized and would rather be the platform for it than fight it.

The security model is where this gets interesting and where I would like to see more detail. An OS-level MCP surface means any agent with the right permission can drive the machine. The consent flow, the scoping granularity, and the audit trail are the whole ballgame, and "there is a permission model" is not yet enough information to evaluate it.

also announced#

NLWeb, a project to let websites expose a natural-language query interface with MCP underneath. Positioned as "HTML for the agentic web." Ambitious; adoption is everything and adoption is unknowable.

Edit, a new command-line text editor for Windows, open source, small. A genuine gap — Windows has had no default CLI editor since edit.com — and filling it is a nice piece of housekeeping.

Windows AI Foundry, the rebranded local model runtime story, with Foundry Local for running models on-device.

the pattern#

Microsoft's developer strategy for a decade has been: meet developers where they are, adopt other people's standards, open-source the layers where control is not worth the friction, and monetize the cloud underneath.

It keeps working. Build 2025 was more of it, executed well.

Ironwood#

The seventh-generation TPU, and the first Google has explicitly positioned for inference rather than training. Large HBM capacity per chip, high interconnect bandwidth, deployable in pods of thousands.

The strategic point is not the specs. It is that Google is the only hyperscaler with a mature, decade-old, production-proven alternative to buying Nvidia. AWS has Trainium and Inferentia, which are real but younger. Microsoft has Maia, which is very young. Google has been running TPUs in production since 2015 and has an entire compiler stack (XLA) and framework story (JAX) built around them.

That translates directly into pricing freedom. When Google prices Gemini aggressively, they are not eating a margin on someone else's silicon.

A2A#

Agent2Agent: a protocol for agents from different vendors to discover each other and collaborate on tasks. Announced with a long list of partner companies.

The mental model is that MCP connects an agent to tools and data, while A2A connects an agent to other agents. An agent publishes an "agent card" at a well-known URL describing its capabilities; other agents discover it and delegate tasks over a JSON-RPC-ish protocol with support for long-running work and streaming updates.

My honest read: the problem is real, the timing is early, and the number of partner logos on the announcement slide is inversely correlated with how much production usage a protocol has on day one. Multi-agent systems in 2025 mostly do not work well enough to need a standard for interoperating — the hard part is that agents fail in the middle of tasks, not that they cannot find each other.

But standards need to exist before they are needed, and having the conversation now beats having it in 2027 with four incompatible implementations.

Gemini 2.5 Flash#

The cost-efficient reasoning model, with a controllable thinking budget. You set how many tokens the model may spend reasoning, including zero.

config = types.GenerateContentConfig(
    thinking_config=types.ThinkingConfig(thinking_budget=1024)
)

This is the right API shape and I expect everyone to converge on it. The decision of how much to think is workload-specific, it is the primary cost lever in a reasoning model, and hiding it inside the model's own judgment takes control away from the person paying the bill.

Set it to zero for classification. Set it high for planning. Measure the quality difference on your own task, because the curve is steeper for some tasks than others and there is no general answer.

the rest#

A great deal of "agentic" branding applied to existing products, an agent development kit, and a marketplace. Cloud vendor conferences have a genre and this one was firmly in it.

The signal-to-slide ratio was better than most.

That is the moment a protocol stops being a vendor's format and starts being infrastructure.

what MCP is, briefly#

A protocol for connecting language models to external context and tools. A server exposes three primitive types:

• Resources — data the model can read (files, database rows, API responses).
• Tools — functions the model can call, with JSON Schema parameters.
• Prompts — reusable templates the user can invoke.

The transport is JSON-RPC 2.0 over stdio for local servers or HTTP with server-sent events for remote ones. That is deliberately unexciting; the value is in the shape of the interface, not the wire format.

{
  "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": {
    "name": "query_db",
    "arguments": { "sql": "select count(*) from orders where day = '2025-03-25'" }
  }
}

why this mattered enough to win#

The problem MCP solves is combinatorial. Before it, connecting M AI clients to N data sources meant M × N bespoke integrations, each one a slightly different function-calling schema with slightly different auth. Every new assistant had to rebuild every connector.

MCP makes it M + N. Write one server for your internal ticketing system and every MCP-speaking client can use it. That is the same argument that won for LSP in editors, and it won for the same reason: the integration burden was crushing the ecosystem and everyone knew it.

The LSP comparison is not incidental — MCP's designers cite it explicitly, and the JSON-RPC choice is a direct inheritance.

the security part, which is underdiscussed#

An MCP server is a program you run that a model can invoke. That is a substantially larger attack surface than it appears.

• Prompt injection through resources. If a server returns content from an untrusted source, that content is now in the model's context and can attempt to influence tool calls. This is the central unsolved problem of the entire agent category and MCP does not fix it.
• Tool description poisoning. The tool descriptions themselves go into the model's context. A malicious server can write a description that manipulates behavior.
• Over-broad servers. A filesystem server with root access is a filesystem server with root access. The convenience of "just point it at my home directory" is how this goes wrong.

Practical guidance while the ecosystem matures: run servers with the narrowest possible scope, treat any server you did not write as untrusted code, and do not combine a server that reads untrusted content with a server that can take destructive action in the same session. That last one is the composition hazard and it is easy to walk into.

what happens next#

Expect: an official governance structure, a registry, and a fight about authorization semantics. Expect every developer tool company to ship a server within a quarter. Expect at least one significant security incident involving a popular community server, because that is what happens to every successful plugin ecosystem, without exception.

Standards win when the alternative is worse for everyone including the people who would prefer to own the standard. That happened here, unusually fast.