Summary

  • The first Internet-Draft for the at URI scheme says the deployed at:// form is not fully compatible with RFC 3986 because DIDs place multiple literal colons in the authority component. The same draft says this version is not eligible for permanent registration under RFC 7595.
  • IANA has listed at as provisional since 2023. That proves registry presence, not formal IETF review, permanent status, generic-parser interoperability or durable binding among a handle, account identity, repository, record and record bytes.

The uncomfortable fact in a new standards document is not that at:// fails to work. It is that it does work. Applications already use the identifier to point at accounts and records in the Authenticated Transfer Protocol. That running use gives the scheme practical weight. It does not make every layer above it settle automatically.

draft-newbold-atp-aturi-00, dated 1 October 2026, writes down that boundary with unusual candour. Its header proposes Standards Track. Its frozen Datatracker record still classifies it as an individual submission with no stream, state or standards level recorded. It is revision 00, not an RFC, not an IETF consensus result and not proof that any permanent-registration request has been accepted or rejected.

The syntax looks familiar: at://, an authority, and optionally a collection and record key. The authority may be a human-readable account handle or a permanent account identifier. The operational problem appears when the permanent identifier is a DID such as did:plc:…. Literal colons are part of that identifier.

RFC 3986 gives an authority a shared grammar: optional user information, a host and an optional colon-delimited port. A scheme may prohibit user information or ports, but RFC 7595 says a scheme definition cannot override the overall URI syntax. Revision 00 therefore makes a precise admission: putting a multi-colon DID into an authority after // violates that generic grammar, so the syntax described in this version is not eligible for permanent registration.

That is a current-design finding, not a funeral notice. The draft does not say the identifier is unusable, that IANA rejected it or that the IETF ordered a migration. It says the opposite of the first claim and supplies no evidence for the other two. A protocol-specific parser can treat the authority as an opaque identity string and resolve it successfully. Permanent URI registration asks a different question: can the scheme live inside the common contract expected by the wider URI ecosystem?

IANA's registry shows why the distinction matters. at has been provisionally registered since 1 June 2023. RFC 7595 allows provisional registration for a scheme observed or intended for use outside one private organization. The procedure is First Come First Served. Permanent registration uses Expert Review and requires the Section 3 design conditions.

The designated-expert note attached to the at row is equally careful. It says provisional status does not mean formal IETF review or an IETF recommendation for general use on the open Internet. It records concern that the short name “at” could be confused with other uses and notes suggestions such as atproto or atp. It says that concern could impede a later permanent request. It also says the note itself is not an IETF or IANA position. Those caveats must travel together.

This produces four records where a dashboard may show one green badge: the scheme is used; the scheme has a provisional registry row; revision 00 aspires to Standards Track; and permanent registration remains unavailable to the exact syntax it describes. None erases the others. Running use demonstrates utility. Registry presence prevents an invisible name collision. A draft exposes a change surface. Permanent review remains a separate institutional act.

The identity chain has the same structure. A handle is readable and movable. AT Protocol documentation warns that a handle can later resolve to another DID, and a reused handle can make an old reference point at another repository. Revision 00 therefore says a handle-based reference should be resolved to a permanent account identifier before long-term storage. Display may remain friendly; durable authority should not depend on the friendly label.

Even the DID is not the record. The authority identifies an account, not necessarily the network host that stores its repository. Resolution discovers the hosting location. The collection and record key identify a logical record, but the record may change or disappear. An AT URI is not content-addressed. When exact content matters, the implementer guidance recommends carrying a CID hash as well.

A useful receipt therefore has at least seven coordinates: the exact URI profile and draft revision; parser and version; input handle or DID; handle-to-DID resolution with time; repository endpoint; collection, key and retrieved record revision; and optional CID over the bytes relied upon. An eighth record belongs to the application action that followed. A successful parse proves none of those later stages by itself.

Parser evidence also needs boundaries. Official documentation names Python urllib and JavaScript url-parse as workable examples, while saying Go net/url and most popular Rust URL crates do not handle the documented form. That is valuable implementation guidance. It is not an independent census of every version, binding, application or future release. Each deployment must record what it actually executed.

Heng Lu's Running-Code Primacy prevents a standards badge from overruling working systems; it also prevents working systems from manufacturing a standards decision. The Minimum Initial Specification asks the shared layer to expose the few invariants that everyone needs: handle, permanent account identity, repository location, record coordinate and content binding are different things. Reality Layers keeps an IANA label, a parser result, a fetched object and a user outcome from collapsing into the word “supported”.

The durable conclusion is not “standards beat deployment” or “deployment beats standards”. It is that authority is specific. The protocol can authorize how an AT record is named and resolved. IANA can record the scheme's current registration status. A permanent review can judge the syntax presented to it. An application decides what evidence it requires before acting. Trustworthy infrastructure retains every handoff.

Sources