Zusammenfassung

  • Revision 00 des at-URI-Entwurfs hält fest, dass ein DID mit mehreren unkodierten Doppelpunkten in der Authority von at:// nicht zur generischen Grammatik aus RFC 3986 passt. Diese Fassung ist deshalb nach RFC 7595 nicht dauerhaft registrierbar.
  • IANA führt at seit 2023 als Provisional. Der Eintrag belegt den Registerstatus, nicht formale IETF-Prüfung, allgemeine Parser-Interoperabilität oder eine dauerhafte Bindung von Handle, DID, Repository, Record und Inhalt.

Der neue Entwurf beginnt nicht bei null. at:// wird bereits verwendet. Gerade deshalb ist seine offene Syntaxgrenze strategisch wichtiger als eine weitere Funktionsbeschreibung.

draft-newbold-atp-aturi-00 trägt das Datum 1. Oktober 2026. Im Kopf steht Standards Track als Ziel. Der eingefrorene Datatracker-Datensatz ordnet das Dokument jedoch den Individual Submissions zu und enthält keinen Stream, Status oder Standardisierungsgrad. Es ist weder RFC noch WG-Annahme oder IESG-Entscheidung.

Das Schema verweist auf Konten und Records im Authenticated Transfer Protocol. Nach at:// steht eine Authority aus lesbarem Handle oder permanentem Account-Identifier; Collection und Record Key können folgen. Ein spezialisierter Resolver kann diese Zeichenfolge erfolgreich verarbeiten.

Die Hürde liegt im DID. Ein Wert wie did:plc:… enthält mehrere Doppelpunkte. RFC 3986 strukturiert die Authority dagegen als optionales Userinfo, Host und optionalen Port. RFC 7595 erlaubt einem Scheme nicht, die allgemeine URI-Syntax umzudefinieren. Revision 00 sagt daher ausdrücklich, dass ihre heutige DID-Authority nicht für eine permanente Registrierung infrage kommt.

Das ist keine Feststellung technischer Wirkungslosigkeit. Ein eigener Parser kann die Authority als undurchsichtigen Identitätswert behandeln. Die Quellen dokumentieren weder eine abgelehnte permanente Anfrage noch eine angeordnete Migration. Die Begrenzung gilt für die eingereichte Syntax, nicht für jede mögliche Zukunft.

Im IANA-Register ist at seit Juni 2023 vorläufig eingetragen. RFC 7595 sieht Provisional für Schemes vor, die außerhalb einer einzelnen privaten Umgebung verwendet werden, auch bevor sie standardisiert sind. Dafür gilt First Come First Served. Permanent verlangt Expert Review und die Gestaltungsanforderungen aus Abschnitt 3.

Die zugehörige Expertennotiz begrenzt die Aussage weiter. Provisional bedeutet weder formale IETF-Prüfung noch Empfehlung für den allgemeinen Einsatz im offenen Internet. Die Notiz dokumentiert Sorgen über den kurzen Namen at und Vorschläge wie atproto oder atp; dies könne eine spätere permanente Anfrage erschweren. Zugleich ist die Notiz ausdrücklich keine Position von IETF oder IANA.

Vier Zustände müssen also nebeneinander stehen: reale Nutzung, vorläufiger Registereintrag, Standards-Track-Absicht eines individuellen Entwurfs und fehlende permanente Eignung der beschriebenen Syntax. Wer daraus ein einziges „registriert“ macht, verliert die Entscheidungsgrundlage.

Auch ein Handle ist kein dauerhafter Principal. Es kann auf ein anderes DID zeigen oder neu vergeben werden. Eine alte Referenz kann dadurch ausfallen oder ein anderes Repository treffen. Der Entwurf verlangt deshalb, Handle-Referenzen vor langfristiger Speicherung in einen permanenten Account-Identifier aufzulösen.

Das DID ist wiederum weder Standort noch Inhalt. Die Authority bezeichnet das Konto; die Repository-Auflösung findet den Dienst. Collection und Key bezeichnen einen veränderlichen Record. Ein AT URI ist nicht inhaltsadressiert. Für eine starke Referenz empfiehlt die Implementierungsdokumentation zusätzlich einen CID-Hash.

Der operative Nachweis braucht Syntaxprofil und Revision, Parser und Version, Handle oder DID, zeitgebundene Handle-Auflösung, Repository-Endpoint, Collection/Key und abgerufene Revision, optionalen CID und das Ergebnis der Anwendung. Parser-Erfolg ersetzt keinen späteren Schritt.

Die offizielle Dokumentation nennt Python urllib und JavaScript url-parse als funktionierende Beispiele, Go net/url und viele Rust-Crates als nicht passend. Das ist eine wichtige Warnung, aber keine unabhängige Vollerhebung. Produktionssysteme müssen ihre genaue Kombination testen.

Heng Lus Running-Code Primacy schützt den laufenden Dienst vor symbolischer Auslöschung und den Standardisierungsprozess vor erfundener Zustimmung. Minimum Initial Specification trennt Handle, Identität, Hosting, Record und Hash. Reality Layers hält Registerstatus, Ausführung und Ergebnis auseinander.

Es geht nicht darum, ob Standard oder Deployment gewinnt. Es geht darum, dass jede Instanz nur das belegt, wofür sie zuständig ist.

Quellen