Summary

  • RFC 8890 gives human end users priority when their interests conflict with other parties, yet explicitly denies the IETF, governments and civil-society participants an automatic mandate to know or represent what all users want.
  • A user agent is an HTTP client program. It can sandbox a service, express a scoped setting and preserve choice among implementations; none of those technical functions proves human presence, informed consent or collective authorization.
  • Representation claims should be replaced by a joined receipt: affected cohort, alleged harm or benefit, consultation limits, preference and default, capability boundary, viable alternatives, measured switching cost and observed outcome.

The request reaches a service, but the person does not. A client program chooses the method, adds headers, applies stored settings, withholds some capabilities and exposes others. It may act because someone clicked a link, because a background task woke, or because a crawler scheduled itself. HTTP calls all of these programs user agents.

That old technical name creates a modern political temptation. If the program stands between a service and a person, perhaps it represents the person. If a standards participant designs the program's constraints, perhaps that participant represents users. If a government or advocacy organization attends the room, perhaps affected people have been represented. Mark Nottingham's RFC 8890 blocks each shortcut while making an apparently stronger claim: when the interests of end users conflict with other parties, the Internet Architecture Board says end users should be the priority.

Priority without an automatic representative is the document's productive tension. It forces a standards process to ask who bears the effect and how that effect is known. It does not issue a certificate allowing an implementer, institution or author to answer on their behalf.

The HTTP role begins with a request, not a mandate

RFC 9110 defines a user agent as a client program that initiates a request. A browser is the familiar case, but the role also covers command-line tools, spiders, household appliances, mobile applications and scripts. The specification says a human need not be interacting with the program when a request occurs.

This definition establishes protocol agency: which component selected and emitted an HTTP message. It does not establish the legal or political agency of the human affected by the result. A background client can refresh content while its owner sleeps. A crawler has no human principal for each fetched page. A shared device can apply one default to several people. An accessibility tool may transform content in ways a site never sees.

The distinction changes what can be claimed from telemetry. A request can identify a program family, configuration or declared preference where those signals are available. It cannot by itself prove who was present, whether the person understood the choice, whether another person was affected, or whether the selected program expresses all relevant interests.

Calling the component an agent is therefore a functional description, not a transfer of sovereignty. The durable receipt begins with the program and its configured authority. Any claim about the person needs additional evidence.

RFC 8890 chooses the human and refuses to invent a single human

RFC 8890's end user is the human whose activity the Internet supports. The person may be indirect: someone photographed by a connected camera, someone entering a sensor-equipped room, or someone affected by software that runs without immediate interaction. Protocol administration is not the test. Human consequence is.

Those humans are not a stable bloc. The same person can be a reader and publisher, buyer and seller, service consumer and service provider. Privacy, reachability, safety, flexibility and affordability may pull in different directions. A design that helps one group of users can impose cost on another. The phrase “users want” therefore hides the first unanswered question: which users, in which role, under which conditions?

The document is unusually direct about institutional limits. The IETF has no unique insight into what is good for end users and cannot assume its own experience matches theirs. Government-sponsored participants do not automatically represent all users in their jurisdiction. Civil-society advocates can bring expertise and valuable evidence without necessarily carrying a mandate from the larger community. Consultation with affected communities improves the evidence but cannot formally guarantee representation.

This is not a reason to abandon the priority. It is a reason to keep priority and representation in different columns. Priority is a decision rule for resolving competing interests. Representation is an authorization claim that requires a principal, scope and accountability. The first does not silently create the second.

The browser boundary is valuable precisely because it is bounded

RFC 8890 uses the user agent as an example of imperfect but useful representation. A website normally receives a constrained channel through the browser rather than arbitrary access to the person's system. Code runs inside a sandbox. The agent exposes selected capabilities, mediates prompts and can refuse requests. This architecture shifts some control away from the remote service.

The benefit is real without being universal. A sandbox can prevent one class of direct access while leaving tracking, manipulation, inaccessible design or harmful defaults unresolved. A permission prompt can show a choice while exhausting the person into acceptance. An extension can protect one workflow and expand another attack surface. A vendor can remove a service capability and still choose a default that favors its own business.

The right audit question is consequently narrow: which user interest does this control protect, against which service capability, for which request or origin, with what default and enforcement? The answer belongs to the control, not to the user agent as a whole.

RFC 6973 provides useful separation. User participation, consent, preference expression, data minimization and security are related but not interchangeable. A “do not” signal, a permission state or a local privacy setting is evidence of one scoped mechanism. Its receipt should record who set it, whether it arrived as a default, its recipient and duration, whether it can be revoked, and whether the receiving party actually honors it.

A program may carry that signal faithfully and still be unable to express a different concern. A person outside the request may be affected but have no control at all. Software mediation can transmit a preference; it cannot infer a mandate for every interest the interface omitted.

Harm needs an issue record, not a volume meter

RFC 8890 does not supply a mechanical definition of negative end-user impact. It asks the relevant standards process to discuss the alleged harm and reach a reasoned conclusion. A bare assertion that a proposal harms users is not sufficient. Ignoring a harm because its proponent lacks numbers or leaves the room is not sufficient either.

RFC 7282 explains why counting voices cannot resolve the problem. Rough consensus is about addressing issues, not measuring how many people spoke. A hum can reveal the room's state and prompt further inquiry; it does not dispose of a technical objection. The issue persists after the person who raised it departs.

An end-user impact record should name the affected cohort, the mechanism that produces benefit or harm, the evidence available, the alternatives considered, the distribution of costs and the remaining uncertainty. When users' interests conflict, testing the pessimal environment is more informative than describing an average person who does not exist. If a technical compromise remains unavoidable, the disposition should say who bears it and why.

This turns a moral claim into reviewable work without pretending the work is value-free. It also exposes an agency problem: the participants choosing the compromise may receive the upside while absent users bear the downside. Attendance at the standards table cannot erase that divergence.

A consultation log is not a proxy ballot

RFC 8890 calls for meeting affected communities on their own terms, tailoring feedback mechanisms and avoiding surprises. That changes the direction of work. A mailing list, BOF or working-group meeting may be an excellent venue for protocol specialists and a poor venue for a community that does not use those channels, cannot attend in that language or will only experience the consequence later.

RFC 8752 records one concrete ESCAPE workshop that gathered perspectives about publishers, content aggregation and the open Web. The workshop is evidence of an effort, the views presented and the issues identified. It is not a certificate that its participants represented every publisher, advertiser, reader or person described by the systems discussed.

A useful consultation receipt records who organized the outreach, which community was sought, how invitations were distributed, which languages and access needs were supported, who responded, which groups remained absent, what issues were raised, what changed and why other requests did not. It preserves the gap between “heard from” and “authorized by.”

That gap protects both sides. Engineers can use evidence without falsely attributing collective consent. Advocates can contribute expertise without being burdened with a fictional mandate. Affected people remain principals whose absence must be visible rather than converted into approval.

Choice becomes credible only after an exit test

RFC 8890 finds value in multiple user-agent implementations because alternatives can lower switching cost and give implementers an incentive to serve users. RFC 9518 develops the mechanism further: switching among implementations or deployments can constrain centralization, but only when alternatives actually exist and substitution is affordable.

An install button is not proof of exit. Moving user agents can require transferring data and preferences, preserving credentials, replacing extensions, restoring accessibility, accepting different security warnings, recovering managed workflows and changing a platform default. The destination may lack a feature or may reproduce the same dependency. A person may technically be allowed to leave yet unable to do so without losing accumulated work.

Specification design affects that market. Excessive complexity can narrow the set of independent implementations. Too little specification can force proprietary extensions that also make replacement difficult. Counting brands says little if they share one engine, one distribution gate or one policy dependency.

The exit receipt should therefore measure time, expertise, coordination, lost functionality, data portability, default status, organizational policy, ability to return and outcome after the move. It should also identify who can select the intermediary and who cannot. Switching turns an abstract representation claim into contestable performance: an agent that stops protecting a user's interest can lose the role only if the exit path is real.

Intermediary power needs selection, scope and revocation

RFC 9518 proposes two useful boundaries for intermediaries. Third-party participation should follow a positive act by at least one primary party, and the intermediary's observation or control should be limited to what its function requires. The RFC is an Independent-stream Informational document expressing Nottingham's views, not community consensus or universally enforced law.

As an audit frame, however, the boundaries are concrete. Record how the user agent was selected; whether it was installed, defaulted or mandated; what resources it can see; which requests or responses it may transform; what it retains; which service capabilities it blocks; how the person can revoke authority; and what replacement entails. The record should separate a visible choice from a platform decision made before the person arrived.

The positive act does not authorize everything that follows. Selecting a browser to retrieve a page does not consent to every secondary use. Selecting an enterprise-managed client may express the employer's policy rather than the affected person's preference. A useful intermediary remains an agent with a defined task, not a principal with unlimited discretion.

Three RFCs, three different authority statements

Mark Nottingham is attributable to this argument, but he is not sovereign over it. RFC 8890 names him as author and was published in the IAB stream as an Informational RFC. Its status says it represents IAB consensus at publication; it is not an Internet Standard and does not represent IETF consensus. Nottingham's contemporaneous explanation describes it as guidance intended to persuade rather than bind.

RFC 9110 is different. It is an IETF Standards Track specification edited by Roy Fielding, Mark Nottingham and Julian Reschke, built through collective HTTP standardization. Its definition of the user-agent role is normative protocol work, not a claim that any editor controls implementations.

RFC 9518 is different again. It is an Independent-stream Informational RFC and explicitly states that it represents the author's views. Its analysis of switching, complexity and intermediary power offers a testable frame, not a vote of the Internet community.

The current IETF Datatracker profile documents Nottingham's extensive work across HTTP, URLs, RSS/Atom and QUIC and lists dated responsibilities. Those records establish contribution and a public trail. They do not establish ownership of HTTP or the Web, control of browser policy, authority over IETF outcomes or a mandate to speak for all users.

Build the receipt that the word “represent” conceals

Start with affected humans, including people who never issue the request. Divide them by role and context rather than gathering them under a singular user. State the alleged interest, benefit or harm and the mechanism connecting design to consequence. Preserve the consultation perimeter and absences.

Then record the technical chain: selected user agent, installation or default source, active preference state, sandbox and capability boundary, observable enforcement, alternative implementations and real exit cost. Finish with outcomes for the tested cohorts and the standards disposition of conflicts. Do not let a successful setting prove consultation, a consultation prove authorization, or an alternative name prove switchability.

This chain is more demanding than saying the browser represents the user. It is also more faithful to RFC 8890. The Internet can be for end users without pretending they are one constituency with one delegate. A user agent earns its place by the limits it enforces, the choices it preserves and the evidence that people can withdraw the role—not by claiming their voice.

Sources