RFC: define trailing DNS root-dot handling in request-signing canonicalization

[bokelley]

Summary

Define whether an explicit trailing DNS root dot is stripped, preserved, or rejected when deriving request-signing @authority and @target-uri, and publish a conformance vector for the decision.

Context

The Python SDK normalizes IDN hosts through UTS-46. That normalizer strips a trailing root dot, while the former ASCII-only path preserved it. Without one normative rule, equivalent host spellings can produce different signature bases:

• https://example.com./p
• https://example.com/p
• A-label and U-label forms of the same IDN host with a trailing dot

The Python SDK currently strips one trailing dot before branching so ASCII, A-label, and U-label inputs agree. This is an interim interoperability choice, not a protocol decision. Other implementations following RFC 9421 and RFC 3986 literally could preserve the wire form and silently diverge.

Requested specification work

1. State the normative trailing-root-dot rule in the @authority / @target-uri canonicalization steps.
2. Add root-dot-* accept/reject cases to the current request-signing canonicalization vectors under dist/compliance/<version>/test-vectors/.
3. Cover ASCII, A-label, and U-label spellings that identify the same DNS name.
4. Note the wire-compatibility consequence for mixed old/new SDK deployments.

SDK tracking

Python: adcontextprotocol/adcp-client-python#986

The Python-local regression test should be replaced by the vendored upstream vector once this lands.

[bokelley]

Triage

Classification: Spec question / RFC
Bucket(s): spec / protocol, compliance-suite
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: RFC 9421 §2.2.2–2.2.3 and RFC 3986 §3.2.2 are both silent on trailing-dot normalization — two conformant implementations (Python via UTS-46, Go/Node via net/url/new URL()) produce different signature bases for the same logical host, causing hard auth rejection with no actionable error. Strip is correct; reject-single is too strict (curl and Python urllib emit the dot legitimately); preserve breaks cross-implementation parity. Requires a normative MUST, not a vector-only advisory. Signing profile changes are never patch-eligible per AdCP playbook → ships 3.2 as minor only. Implementation is already in the source tree.
• adtech-product-expert: Trailing dots are rare in production ad tech traffic but the failure mode is a hard 401/403 with no actionable error signal — the worst class of silent cross-vendor auth failure. Scope is minimal and proportionate. Python SDK already strips; Go/TypeScript implementers that preserve need to update, but no live flows should break in practice. Needs WG vote; cannot land on 3.1.x.

My take: Both experts converge on the same ruling. The implementation is already committed to main (MUST language in docs/reference/url-canonicalization.mdx, six source canonicalization vectors, profile-3.2/negative/002-multiple-trailing-dots.json, changeset stamped minor). What remains is WG ratification of the normative decision. Proposed decision record for WG review:

---

Proposed DR-0015 (draft — for WG ratification):

---
id: DR-0015
title: Strip one trailing DNS root-label dot in request-signing host canonicalization
class: normative
status: recorded
date: 2026-08-24
decided: ~2026-08
decided_by: (pending WG ballot)
refs: ["#6813"]
dissent: none
---

## Decision

After UTS-46 Nontransitional ToASCII processing, a hostname ending in exactly
one trailing DNS root-label dot MUST have that dot removed before the @authority
and @target-uri components are emitted. Removal applies identically to ASCII
inputs, A-labels, and U-labels; implementations MUST NOT preserve the dot on an
ASCII fast-path while removing it on an IDN path. A hostname with more than one
trailing dot (empty DNS label) MUST be rejected before canonicalization.

## Rationale

RFC 9421 and RFC 3986 are both silent on root-dot normalization. Without an
explicit rule, two RFC 9421-conformant implementations — Python's UTS-46 normalizer
(strips as a side-effect of ToASCII) vs. Go net/url or Node new URL() (preserves
per RFC 3986 literal reading) — produce different signature bases for the same
logical host, causing hard auth rejection with no actionable error signal.

## Implications

Settles the ASCII/A-label/U-label parity requirement for root-dot handling.
Does not address other DNS normalization (label length, punycode equivalence
for non-root labels). Signing profile changes are never patch-eligible; this
ships 3.2 only. 3.1.x SDKs that preserve the dot should ship an errata note;
retroactive enforcement is not mandated on 3.1.x. The Python SDK regression
test at adcp-client-python#986 should be retired in favor of the vendored
upstream vector once 3.2 ships.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01YPBWdYHwqZxDUKiK5EGN88

---

Generated by Claude Code