Q1: How should RFC 8890 be used in a protocol review?
Multiple Choice
RFC 8890 is Informational IAB guidance, not a wire-format specification or protocol conformance standard. Sections 2-4 provide a lens for identifying human users, substantiating impacts, and comparing trade-offs; they do not turn every asserted harm into an automatic veto. A review should use the document to improve its evidence and choices without describing the result as RFC 8890 compliance.
Q2: Who counts as an end user in RFC 8890? Select all that apply.
Multi-Select
RFC 8890 Section 2 uses `end user` for human beings, including people represented by software and people affected indirectly, such as subjects of photographs or sensor-equipped spaces. An organization remains a stakeholder and a group of humans, but its operator role does not itself become the human end user; likewise, an agent may represent a person without being that person. Reviews must map protocol roles to the represented and affected humans before weighing interests.
Q3: What priority does RFC 8890 recommend when stakeholder interests genuinely conflict?
Multiple Choice
RFC 8890 Sections 1 and 3 recommend favoring end users when their interests genuinely conflict with those of other parties, and Section 4 describes how to investigate the effects. Deployment control, scale, bandwidth, latency, author convenience, and process needs are not sufficient priorities by themselves. The recommendation applies after identifying the affected humans, establishing the conflict, and comparing realistic alternatives.
Q4: Why is a higher adoption rate alone insufficient evidence of an end-user-positive design?
Multiple Choice
RFC 8890 Section 3 does not reject measurement; it warns that deployment or other selected success metrics can hide whether technology empowers users or asserts power over them. Higher adoption neither eliminates stakeholder conflicts nor proves that affected humans retain agency, safe alternatives, or acceptable exposure. Operational metrics therefore need accompanying evidence about switching, control, and negative impacts.
Q5: What is the strongest review method when designers claim a change is good for users?
Multiple Choice
RFC 8890 Section 4.1 says technical designers have no unique insight into what is good for users and calls for impact analysis, consultation, outreach on affected communities' terms, and suitable feedback mechanisms. Requiring those communities to attend the IETF's usual venues would not meet that goal. Technical metrics remain useful, but a claimed user benefit needs evidence from the affected population rather than intent or internal consensus alone.
Q6: Which design observations align with RFC 8890? Select all that apply.
Multi-Select
RFC 8890 Section 4.2 uses the browser user-agent role to illustrate representation, service access, user choice, and the value of multiple implementations with lower switching costs. Section 4.5 separately warns against prioritizing architectural purity or document-author convenience for their own sake. The relevant question is whether the architecture gives humans meaningful representation and alternatives, not merely whether it is tidy for implementers.
Q7: Whose interests must this A2A review examine as end-user interests?
Multiple Choice
A company deploys an agent that summarizes employee messages and sends results to customers. The gateway operator calls the company the sole end user because it pays for the service.
RFC 8890 Section 2 requires the review to look past organizational and software roles to the human beings represented or affected. The paying company and network operator are stakeholders, but payment or deployment does not make an organization the only end user, and an agent is not itself a human. The analysis must trace the people represented, observed, acted upon, or otherwise affected and keep their potentially different interests visible.
Q8: What is the justified RFC 8890 review finding for this logging proposal?
Multiple Choice
An A2A operator proposes indefinite logging of full prompts and tool outputs to simplify debugging. The review records no retention need, misuse scenario, affected people, less-invasive alternative, or consultation.
RFC 8890 Sections 4.1 and 4.3 call for engagement with affected communities and evidence about negative impact instead of bare assertions of either harm or benefit. Because the document is Informational, it does not create a categorical logging rule; equally, a possible operational benefit does not justify unlimited content or retention. Encryption protects one property but does not answer questions about collection, secondary use, or power, so the proposal needs a specific purpose, feasible alternatives, and a documented trade-off.
Q9: Which two actions fit RFC 8890 when two groups of end users have conflicting needs? Select all that apply.
Multi-Select
A fraud-control feature helps buyers recover stolen funds but publishes seller identity data in jurisdictions where disclosure can cause physical harm. Both groups present credible evidence.
RFC 8890 Section 4.4 calls for minimizing negative impact, considering environments where users can be harmed, and thoroughly documenting unavoidable compromises. Group size alone does not capture severity, and Section 2 allows one person to occupy several roles, so a seller does not cease to be a human end user. Both groups must remain in the analysis while reviewers compare less-harmful alternatives and make residual trade-offs explicit.
Q10: Which conclusion properly combines protocol security with an RFC 8890 review?
Multiple Choice
An A2A gateway validates OAuth grants and session-bound proofs. To improve abuse response, one mandatory broker receives every task body and retains it for all participating services. Users cannot choose another broker or export their history; affected workers were not consulted.
A valid grant and session-bound proof establish protocol properties such as permission and credential-to-session binding; they do not establish net human benefit, data-governance quality, or switching freedom. RFC 8890 is Informational and does not categorically ban the architecture. Sections 2 and 4.1-4.4 instead require an independent review of direct and indirect human users, community evidence, negative impacts, and unavoidable conflicts alongside the cryptographic analysis.
