OAuth PoP adoption, DKIM2 keys, and emailcore plaintext rules

IETF working groups spent the day on adoption calls and requirement disputes spanning OAuth token binding, email authentication, DNS delegations, and traffic engineering. The highest-volume threads focused on proof-of-possession mechanisms, DKIM2 key metadata, and whether SMTP receivers must accept plaintext mail.

OAuth call for HTTP Message Signatures PoP

The OAuth working group opened a call for adoption of a draft defining OAuth Proof of Possession Tokens with HTTP Message Signatures. Fifteen participants voiced support while raising comparisons to DPoP and related design concerns across 25 messages. The decision will matter to implementers of token-binding and HTTP signature schemes who need clear guidance on how clients prove key possession.

DKIM2 key validity field and format debate

A 111-message thread on the ietf-dkim list, involving 16 participants, examined a proposal to add a key validity field for DKIM2. Discussion turned on JSON versus tag=value encoding, parser ambiguity, and the consensus rules in RFC 7282. Email authentication developers planning DKIM2 support have a direct interest in how key lifetime and format questions are resolved.

Emailcore last-call dispute on plaintext SMTP

Last-call discussion of draft-ietf-emailcore-as continued around a DISCUSS ballot and the question of whether the document must require SMTP receivers to accept plaintext mail. Seventeen participants exchanged 64 messages in a heated exchange over document status and mandatory receiver behavior. The outcome will shape baseline compliance expectations for email server operators and protocol authors.

DELEXT delegation type ranges in DNSOP

DELEG and DELEXT authors proposed four delegation type ranges that control NS inclusion and referral behavior. Ten participants on the dnsop list examined the semantics and resolver implications in 25 messages. Resolver and authoritative-server developers evaluating extended delegation mechanisms will want to track how the ranges are defined.

TEAS power-aware traffic engineering feasibility

The TEAS list debated whether distributed power-aware traffic engineering is feasible in connection with the adoption call for draft-many-teas-power-steering-01. Eleven participants produced 72 messages of technical argument on the draft's approach. Network engineers working on energy-aware routing can use the exchange to gauge practical limits of distributed power steering.

PLANTS MTC use-cases adoption call

The PLANTS working group opened a call for adoption of draft-gray-plants-mtc-deploy-use-cases-01, closing 2026-10-02. Twelve participants offered split views on scope and value outside WebPKI across 18 messages. Contributors to certificate and transparency plant models have a short window to influence whether the use-cases draft is taken up.

v6ops 5G IPv6-only draft adoption call

A call for adoption began for draft-ma-v6ops-5g-ipv6only-04 on 464XLAT IPv6-only operation in 5G, ending 2026-10-01. Ten participants discussed prefix delegation and MTU considerations in 14 messages. Mobile operators and IPv6 deployment engineers hold a direct stake in whether the document advances as working-group material.

CBOR serialization working-group last call

The CBOR working group opened and extended last call on its serialization draft. Twelve participants supplied routine technical comments on bstr wrapping and data-model boundaries over 40 messages. CBOR implementers should review the text while the last-call window remains open.