Zusammenfassung

  • terms.txt in Revision 00 schlägt Prüfungen für signierte Bot-Anfragen, erklärte Zwecke, Nutzerdelegationen und Zahlungsbelege vor, bevor ein Ursprung Inhalte ausliefert.
  • Die Signatur ordnet eine Erklärung zu; die Quittung dokumentiert genau eine Auslieferung. Keine von beiden beweist die Wahrheit des Zwecks oder beherrscht die spätere Verwendung.
  • Daniel Kade schlägt ein Zugriffsverpflichtungsregister vor, das vorgelagerte Durchsetzung, nachgelagerte Prüfung und Vertragspflicht trennt. Das ist redaktionelle Analyse, keine IETF-Vorgabe.

Aus einer Bitte soll eine Entscheidung werden

robots.txt ist eine weithin bekannte Konvention. RFC 9309 sagt jedoch ausdrücklich, dass ihre Regeln keine Zugriffsautorisierung darstellen. Ein Crawler wird um Rücksicht gebeten; seine Betreiberidentität, sein Nutzungszweck, eine Zahlung oder die tatsächliche spätere Verwendung werden dadurch nicht geprüft.

Die terms.txt-Revision 00 setzt am Ursprung an. Unter /.well-known/terms.txt, gestützt auf den Mechanismus für bekannte URIs, könnten Pfadblöcke einen registrierten Zweck erlauben, berechnen oder ablehnen. Sie könnten den Umfang der Wiedergabe begrenzen und für bestimmte Inhalte eine Nutzerdelegation verlangen.

Ein automatisierter Client würde den separaten Web-Bot-Auth-Entwurf nutzen. Eine HTTP Message Signature deckt die vollständige Ziel-URI und Access-Intent ab; bei Bedarf auch Delegation und einmaligen Zahlungsbeleg. Vor der Auslieferung prüft der Ursprung Schlüssel, Zeitfenster, Nonce, Integrität der Erklärung, Ziel und Umfang einer Delegation, zutreffende Bedingungen sowie einen gültigen, unverbrauchten Beleg.

Das sind Tatsachen, über die der Ursprung entscheiden kann. Bei Nichterfüllung verwendet der Entwurf 403 und beschreibt den Grund mit Problem Details: ungültige Signatur, Wiederholung, abgelehnter Zweck, zu weit gehende Nutzung, fehlende Delegation oder Zahlung. Er erfindet keine Semantik für den reservierten Status 402 und benutzt 401 nicht ohne WWW-Authenticate. Damit bleibt die Entscheidung innerhalb der bestehenden HTTP-Semantik.

Der Schlüsselhalter ist nicht automatisch das Unternehmen

Web Bot Auth kann zeigen, dass der Inhaber eines Schlüssels, der unter einer aufgelösten Agentenkennung veröffentlicht ist, die Anfrage signiert hat. Der Ursprung kann diese Kennung wiedererkennen, begrenzen oder sperren. Die Signatur benennt jedoch nicht von selbst die juristische Person hinter dem Schlüssel.

Auch andere Vertrauensbeziehungen bleiben offen. Ein Identitätsanbieter soll eine Nutzerdelegation für Ursprung, Agent und Umfang ausstellen. Wie der Ursprung diesem Anbieter vertraut, ist nicht geregelt. Ein Abrechnungsdienst soll Zahlungsbelege ausgeben; sein Verhältnis zu den Beteiligten liegt ebenfalls außerhalb des Entwurfs. Ein interoperables Format macht einen Vermittler noch nicht legitim oder unfehlbar.

Die Syntax des Bedingungsdokuments verlangt deshalb operative Disziplin. Ein Parse-Fehler verwirft die gesamte Datei; Clients behandeln den Ursprung dann so, als habe er keine Bedingungen veröffentlicht. Versionshistorie, Vorabprüfung, atomare Veröffentlichung und externe Beobachtung sind nötig, damit ein Tippfehler den sichtbaren Regelzustand nicht unbemerkt umkehrt.

Drei Beweise dürfen nicht zu einem werden

Revision 00 beschreibt selbst drei Ebenen. Vor der Auslieferung kann der Ursprung prüfbare Voraussetzungen durchsetzen. Danach lassen sich Erklärung und beobachtbares Verhalten auditieren. Jenseits davon gilt eine vertragliche Ebene: Sobald der Inhalt den Ursprung verlassen hat, kann HTTP nicht bestimmen, ob er in einer Suche, einer Zusammenfassung, einem Modell oder einer vollständigen Kopie landet.

Eine gültige Signatur bedeutet: Diese Schlüsselinhaberin hat diese Erklärung abgegeben, und die abgedeckten Felder wurden nicht verändert. Sie bedeutet nicht: Der erklärte Zweck ist wahr. Eine Access-Receipt-Quittung bedeutet: Diese Darstellung wurde unter diesen Bedingungen für diese Anfrage ausgeliefert. Sie bedeutet nicht: Jede spätere Kopie hielt die Bedingungen ein.

Der HTTP-Cache macht die Begrenzung messbar. Würde ein Cache dieselbe Antwort an einen zweiten Client geben, bliebe die Quittung an die erste Anfrage gebunden. Der Ursprung hätte die zweite Auslieferung weder signiert noch protokolliert. Deshalb verlangt der Entwurf bei quittierten Antworten Cache-Control: no-store. Individuelle Zurechnung kostet Wiederverwendung; eine spätere cachefähige Variante müsste dieses Problem neu lösen.

Der Verfahrensstand ist Teil der Nachricht

Der Datatracker-Eintrag führt terms.txt als individuellen Internet-Draft ohne Stream und ohne formellen Rang im IETF-Standardisierungsprozess. Die Dokumenthistorie verzeichnet die manuelle Veröffentlichung von Revision 00 am 11. September 2026. Es gibt keine Arbeitsgruppenannahme, keinen zuständigen Area Director, keine IESG-Genehmigung und keinen RFC.

Im Kopf des Dokuments steht zwar das Ziel Standards Track, im Datatracker fehlt derzeit ein beabsichtigter RFC-Status. Das Ziel des Autors ist kein Beschluss. Die Arbeitsgruppenentwürfe zum Vokabular für KI-Nutzungspräferenzen und zu deren HTTP-Verknüpfung sind benachbarte, aber eigenständige Vorhaben.

Der angeführte Referenzcode liefert ebenfalls keinen fertigen Konformitätsnachweis. Der Text nennt 24 Prüfungen und Laufzeitmessungen, sagt aber zugleich, dass v0.1 älter ist und bei Zielbindung, Statuscodes, Tokenformat, Kennung, Quittungsfeldern, Zahlungsdarstellung, Caching und Link-Relation abweicht. Laufender Code belegt eine Erprobung; er ersetzt weder den aktuellen Text noch einen unabhängigen Interoperabilitätstest.

Ein lokales Register statt einer universellen Behauptung

Daniel Kade schlägt ein Zugriffsverpflichtungsregister vor. Jede Zeile verbindet Ursprung und Pfad mit ID und Hash der Bedingungen, erklärtem Zweck und Nutzungsniveau, Agentenkennung und Identitätsgrenze, Delegationsaussteller und Umfang, Zahlungsautorität, Entscheidung vor der Auslieferung, Antwort- und Inhalts-Hash, Quittungskennung, späterer Beobachtung, Vertragspflicht, Streitverantwortung, Ablauf, Widerruf und Nachfolgeregel.

Heng Lus Policy Mirror zeigt, wo Beleg und Entscheidung auseinanderfallen. Die Minimum Initial Specification hält die gemeinsame Schicht klein und bewahrt örtliche Entscheidungen. Why BTW Media Exists verlangt, eine reale Neuigkeit nicht mit ihrer erhofften Wirkung zu verwechseln. Die Stärke von terms.txt liegt nicht in Allwissen, sondern in einer ehrlich markierten Beweisgrenze.

Quellen

  1. terms.txt im Datatracker
  2. terms.txt-Historie
  3. terms.txt Revision 00
  4. Web-Bot-Auth-Entwurf
  5. Vokabular für KI-Nutzungspräferenzen
  6. HTTP-Verknüpfung von KI-Präferenzen
  7. RFC 9309 — Robots Exclusion Protocol
  8. RFC 9421 — HTTP Message Signatures
  9. RFC 9457 — Problem Details
  10. RFC 9110 — HTTP Semantics
  11. RFC 9111 — HTTP Caching
  12. RFC 8615 — Well-Known URIs
  13. RFC 8126 — IANA-Registrierungsleitlinien
  14. The Policy Mirror
  15. Minimum Initial Specification
  16. Why BTW Media Exists