How English Works | The Protocol

Two machines can be built by different companies, in different countries, using different programming languages, and still communicate.

How?

They do not need to share the same internal design.

They need to agree on the interaction.

Who speaks first?

What kind of message is allowed?

What does that message mean?

What should the recipient do?

How is success reported?

What happens when the message is invalid?

This is protocol territory.

A protocol is English formalised into rules for interaction between parties that do not need to know each other’s internal machinery.

Quick Read

One-sentence answer: a protocol works when it gives participants shared roles, message forms, semantics, state transitions and error rules so independently built systems can interpret each other’s intentions consistently enough to coordinate.

RFC 9110 defines HTTP as a family of stateless application-level request/response protocols with a generic interface, extensible semantics and self-descriptive messages. A client constructs a request that communicates its intention; a server interprets that message in relation to a target resource and responds with one or more response messages.

That architecture gives us the protocol’s main language components:

roles: who may send or receive;
messages: what units of communication exist;
syntax: how a valid message is structured;
semantics: what the message means;
state: what participants may assume before and after exchange;
status: how outcomes are represented;
error handling: what happens when communication fails;
versioning: how interaction rules evolve without breaking everything at once.

The Protocol Is Not the Procedure

A procedure tells one actor or organisation how to carry out a task.

A protocol defines the interaction boundary between parties.

Procedure:

Open the system, enter the request, verify the response and archive the receipt.

Protocol:

The client sends a request containing the method and target. The server returns a response containing a status code and optional content.

The procedure belongs inside one participant.

The protocol governs the interface between participants.

procedure = internal route
protocol = shared interaction contract

Roles Matter Because the Same Program Can Change Roles

RFC 9110 defines client and server as roles performed for a particular interaction, not permanent identities. The same program may act as client in one connection and server in another.

This teaches an important language lesson.

Protocol nouns often describe what an entity is doing now rather than what it eternally is.

role language describes position in the exchange

Confusing identity with role can create bad assumptions about who is allowed to initiate, respond, forward or terminate a message.

Messages Need Both Syntax and Meaning

A message can be perfectly formatted and still mean the wrong thing.

Likewise, a sender can intend the right thing but encode it in invalid syntax.

Protocol design therefore separates:

syntax = what form is valid
semantics = what the valid form means

HTTP makes this explicit through methods, targets, fields, status codes and representation metadata.

English does the same thing in ordinary life.

“Can you close the window?” is grammatically a question about ability but pragmatically often functions as a request.

Protocol language cannot afford that level of implied ambiguity when machines need deterministic interpretation.

Request and Response Create a Conversation Pattern

HTTP’s most familiar pattern is request followed by response.

client intention → request message → server interpretation → response message

This pattern sounds simple.

It solves several coordination problems.

Who initiates?
Which object is being addressed?
What action is requested?
How does the receiver report outcome?
What information accompanies the outcome?

A protocol often becomes easier to reason about when its conversational turns are explicit.

Methods Are Verbs with Contracted Meaning

HTTP methods such as GET, POST, PUT and DELETE are verbs in a highly controlled vocabulary.

The method does not merely label a message.

It tells the recipient what kind of intention the sender is expressing.

This resembles procedural verbs but with a crucial difference:

protocol verb = shared semantic promise between participants

If a sender uses a verb inconsistently with its defined meaning, independent implementations stop being able to reason about the request safely.

Status Codes Compress Outcomes into Shared Categories

A response needs to tell the client what happened.

HTTP uses status codes to compress classes of outcome.

success;
redirection;
client-side error;
server-side error;
intermediate informational state.

The number itself is useful because both parties know the category.

The accompanying reason and content can provide further detail.

status code = compressed shared interpretation of the outcome

This connects directly to Error Message and Empty State. A protocol-level status tells a system what happened at the interaction boundary; a user-facing message must then translate that state for a human receiver.

Stateless Does Not Mean Memory Never Exists

RFC 9110 defines HTTP as stateless: each request can be understood in isolation without requiring the meaning of earlier requests on the same connection.

This does not mean web applications cannot remember users.

It means that HTTP’s core message semantics do not depend on connection history.

Applications can build state using cookies, tokens, databases or other mechanisms above the protocol.

protocol state rules define what participants may safely assume

This is a subtle English lesson. “Stateless” is a technical local definition, not an ordinary claim that nothing anywhere remembers anything.

Self-Describing Messages Reduce Hidden Context

RFC 9110 describes HTTP messages as self-descriptive.

The request carries method, target and other metadata needed to interpret it.

This reduces the amount of invisible shared memory participants must maintain.

In organisational communication, the same principle helps.

Please approve it.

Approve what?

By when?

Under which version?

Self-describing messages include enough identity and context that the receiver does not need to reconstruct the whole conversation from memory.

Error Handling Is Part of the Protocol, Not an Embarrassing Edge Case

RFC 9110 explicitly addresses invalid protocol elements and recovery.

Different applications may choose different error-handling strategies.

A browser may recover from malformed input to keep the user moving.

A safety-critical system may prefer to reject the same ambiguity.

Good protocols therefore define enough error semantics that participants can distinguish:

invalid message;
unsupported message;
temporary failure;
permanent failure;
successful outcome with unusual content.

Failure is another message state, not the absence of protocol.

Retries Can Accidentally Repeat an Action

A client sends a request.

The connection fails before the response arrives.

Should the client retry?

That depends partly on whether repeating the request could repeat a harmful or costly action.

Protocols therefore need concepts such as safety and idempotence—whether repeating an operation has the same intended effect as performing it once.

The deeper language problem is:

When the sender does not know whether the first request succeeded, what can be repeated safely?

This is why retry behaviour belongs to the interaction contract rather than being left to improvisation.

Timeouts Give Silence a Meaning

Silence is ambiguous.

The recipient may be busy.

The message may be lost.

The request may still be processing.

The connection may be broken.

Protocols often use timeout rules to convert indefinite silence into a state the sender can act on.

no response before threshold → timeout state → defined next action

The threshold itself becomes part of the protocol’s operational meaning.

Too short, and healthy slow responses look like failure.

Too long, and genuine failure blocks progress unnecessarily.

Ordering Matters When Messages Depend on Earlier Messages

Some protocols allow independent messages.

Others require sequence.

For example:

authenticate → open session → submit work → receive result → close session

If the sender skips the authentication step, the later message may be syntactically valid and contextually invalid.

Protocols therefore sometimes define legal state transitions.

valid message depends on both form and current protocol state

This is where protocol begins to resemble grammar with memory: certain moves are allowed only after certain earlier moves.

Compatibility Depends on What Old Participants Can Ignore

Protocols evolve.

New fields appear.

New methods appear.

New status codes appear.

A robust extension model asks:

Can old participants safely ignore unknown optional fields?
What happens when an unknown method appears?
Which changes require a new major version?
How is capability negotiated?

RFC 9110 emphasises extensibility and version semantics because the web could not survive if every protocol change required every participant to upgrade simultaneously.

compatibility is the art of changing the language without making yesterday’s listener misunderstand tomorrow’s sentence

Version Numbers Are Compressed History

A version label such as:

Protocol v2

tells participants that the interaction contract has a history.

The important questions are:

What changed?
Is the change backward-compatible?
Which version does each participant support?
What happens when versions differ?

Version negotiation is therefore another form of language alignment.

Before exchanging substantive messages, participants may need to agree which grammar and semantics they are both using.

Intermediaries Complicate the Conversation

HTTP allows proxies, gateways and other intermediaries.

Now the message may travel through parties that are neither the original sender nor the final receiver.

This creates new questions:

Which fields may intermediaries modify?
Which semantics must survive?
Which metadata describes the original source?
How does the receiver know what changed in transit?

Human organisations have the same problem.

A message passes from director to manager to team.

If each intermediary paraphrases freely, the final receiver may receive a different instruction.

protocols preserve meaning across chains of participants

Protocols Reduce the Need for Trust in Internal Design

A browser does not need to know how a server stores its files.

The server does not need to know how the browser draws pixels.

They coordinate through the shared interface.

This is one of the most powerful ideas in protocol design.

agree on the boundary; remain independent behind the boundary

Standards and specifications often define the parts of that boundary.

The protocol adds temporal interaction: what message can happen now and what response should follow.

Primary School: Invent a Two-Person Protocol

Two students need to exchange classroom books without speaking.

Create three cards:

REQUEST — book title
YES — available
NO — unavailable

Then introduce a problem:

What happens if no reply arrives?

The students must add a timeout or retry rule.

The activity teaches that communication needs rules beyond vocabulary.

Lower Secondary: Separate Syntax from Semantics

Give students a simple message format:

REQUEST | item | quantity

Then test:

REQUEST | book | 2
REQUEST | 2 | book
REQUEST | book | many

Ask which messages are structurally valid and which carry meaningful values.

The distinction prepares students for schema and protocol thinking together.

Upper Secondary: Audit the Interaction Contract

What roles exist?
Who may initiate?
What message types exist?
What does each message mean?
What state assumptions are allowed?
How are outcomes encoded?
What happens on timeout or malformed input?
Which operations are safe to retry?
How does version compatibility work?
Can intermediaries preserve meaning?

This turns protocol reading into a lesson in grammar, state, coordination and systems design.

Ten Failure Modes of Protocol English

Role ambiguity. Participants cannot tell who may initiate, respond or forward.
Syntax-semantic mismatch. A message is structurally valid but interpreted differently by sender and receiver.
Status ambiguity. Outcomes are not represented in a shared way.
Hidden-state dependence. A message makes sense only if the receiver remembers undocumented prior context.
Error silence. Invalid or unsupported messages have no defined state.
Retry duplication. Repeated requests accidentally repeat the underlying action.
Timeout ambiguity. Silence has no operational interpretation.
State-order violation. A valid message arrives at an invalid point in the interaction.
Version fracture. New features break older participants without negotiation or fallback.
Intermediary drift. Meaning changes as messages pass through translators, proxies or organisational layers.

How to Design a Better Protocol

Start with the interaction, not the internal implementation.

Which roles participate?
What messages exist?
What syntax makes each message valid?
What semantics does each message carry?
Which states and transitions are legal?
How are success and failure represented?
What timeout, retry or recovery rules apply?
Which changes can older participants safely ignore?
How are protocol versions negotiated?
What must intermediaries preserve?

Then perform the black-box test:

Could two teams who know nothing about each other’s internal implementation build compatible participants using only the protocol definition?

The Deeper Idea: Protocols Turn Agreement into Interaction

A standard can say what counts.

A schema can say what structure is valid.

A protocol adds time.

Who speaks.

What they may say.

What it means.

What happens next.

shared rules + ordered messages = coordinated behaviour

This is why protocols make independent systems feel as though they understand one another.

They do not share a mind.

They share an interaction language.

Reader Checklist

Who are the participants?
What messages can they exchange?
What does each message mean?
Which state assumptions are legal?
How is outcome represented?
What happens on error?
Can requests be retried safely?
What does silence mean?
How do versions coexist?
Could independent implementations interoperate?

Research and Further Reading

RFC 9110 — HTTP Semantics

Final idea: a protocol is good when two strangers can exchange messages, recover from failure and evolve over time without needing access to each other’s internal world.