Zusammenfassung

  • .priv und .shared bestimmen im RFC 5257 Sicht- und Schreibbereiche für dauerhafte Anmerkungen. Sie belegen weder eine Aussage des Absenders noch eine institutionelle Billigung.
  • COPY übernimmt geeignete gemeinsame Anmerkungen, aber nur die privaten Werte des aktuell handelnden Nutzers. Identische Nachrichten können deshalb in unterschiedlichen Kontext- und Entscheidungsräumen landen.

Der grüne Status war jünger als die Nachricht

Eine archivierte E-Mail trug gut sichtbar den gemeinsamen Status „freigegeben“. Der Status wirkte wie eine Eigenschaft des Dokuments: unverändert, selbstverständlich, fast so alt wie die Nachricht selbst. Tatsächlich hatte ihn Wochen später ein Automationskonto gesetzt. Beim Kopieren in ein anderes Postfach wanderte er mit, während die private Warnung einer Prüferin zurückblieb.

RFC 5257 erklärt, wie ein solcher Zustand technisch entstehen darf. Die Anmerkung ist ein eigener, hierarchisch benannter Eintrag an der Nachricht oder einem ihrer Teile. Sie wird nicht in den ursprünglichen Nachrichtentext oder dessen Absenderfelder eingefügt. Dass die Oberfläche beides zusammen zeigt, schließt die Herkunftsketten nicht zusammen.

Für Führung und Revision folgt daraus eine einfache, aber unbequeme Regel: Was neben einem Datensatz steht, spricht nicht automatisch mit der Autorität dieses Datensatzes. Dauer, Suchbarkeit und visuelle Nähe ersetzen keine Urheberschaft.

Privat und gemeinsam sind Reichweiten, keine Gütesiegel

Zu jedem Attribut gehören implizit eine .priv- und eine .shared-Variante. Beim Abrufen oder Suchen kann der Suffix entfallen und beide erfassen. Beim STORE, beim APPEND und bei der Sortierung nach Anmerkungen muss der Client die Variante ausdrücklich nennen.

So kann eine Person in einem gemeinsam genutzten Postfach eine eigene Gedächtnisstütze führen, während das Team einen gemeinsamen Bearbeitungsstand pflegt. Doch die Begriffe sagen nur, in welchem Sicht- und Zugriffsraum der Wert liegt. .priv bedeutet weder Ende-zu-Ende-Verschlüsselung noch juristische Vertraulichkeit oder Unsichtbarkeit gegenüber jeder Administration. .shared bedeutet weder geprüft noch wahr noch von der Organisation genehmigt.

Die falsche Wahl hat gegensätzliche Folgen. Sensible Einzelnotizen im gemeinsamen Raum erweitern den Kreis der Leser. Ein betrieblicher Übergabestatus im privaten Raum bleibt für das Team unsichtbar. Das Protokoll bietet die Grenze; die verantwortliche Organisation muss die Bedeutung klassifizieren.

Ein Recht erlaubt einen Vorgang, keine Stellvertretung

Ohne ACL-Erweiterung hängt der Zugriff davon ab, ob das Postfach nur lesend oder lesend und schreibend ausgewählt wurde. Mit ACL steuert das Recht r das Lesen und Schreiben privater Anmerkungen sowie das Lesen gemeinsamer Werte. Das neue Recht n erlaubt, gemeinsame Anmerkungen anzulegen oder zu ändern.

Diese Trennung ist operativ wertvoll. Ein Dienst kann einen gemeinsamen Bearbeitungsstand ändern, ohne umfassendere Postfachrechte zu erhalten. Das Recht n sagt jedoch nur, dass der Server die Änderung dieses Akteurs in diesem Geltungsbereich akzeptiert. Es sagt nicht, dass der Akteur die Nachricht besitzt, den Absender vertritt oder außerhalb des Postfachs eine bindende Entscheidung treffen darf.

Eine Revision muss daher Schreiber, Berechtigung und damalige ACL festhalten. „Das Workflow-Konto schrieb unter n den gemeinsamen Wert“ ist überprüfbar. „Der Kunde stimmte zu“ verlangt einen Nachweis aus der Autoritätskette des Kunden.

Dauerhafte Speicherung ist kein unveränderliches Protokoll

RFC 5257 verlangt dauerhafte Speicherung statt eines bloßen Sitzungszustands. Das ermöglicht Synchronisation mit getrennt arbeitenden Clients. Der Wert bleibt trotzdem änderbar.

STORE kann ihn anlegen oder ersetzen. Das Speichern von NIL löscht ihn. Für einen fehlenden Wert liefert der Abruf NIL, für dessen Größe null. Ohne gesonderten Verlauf sieht „nicht vorhanden“ gleich aus, ob der Wert nie existierte, bewusst gelöscht wurde oder am Ziel einer Migration nicht gespeichert werden konnte.

Für Offline-Arbeit empfiehlt die Spezifikation Conditional STORE. Damit lässt sich erkennen, dass sich der Zustand seit dem letzten Abbild geändert hat. Eine erkannte Konkurrenz schützt gegen blindes Überschreiben, entscheidet aber nicht, welcher Inhalt sachlich richtig ist oder welcher Akteur im Geschäftsprozess legitimiert war. Technische Konflikterkennung ist keine inhaltliche Freigabe.

Die Serverfähigkeit ist noch keine Postfachzusage

Ein Server kann ANNOTATE-EXPERIMENT-1 bekanntgeben. Das ausgewählte Postfach meldet dennoch seinen konkreten Zustand: NONE verbietet die Nutzung, READ-ONLY nur Änderungen, NOPRIVATE private Werte. Eine Zahl begrenzt die Wertgröße; zusätzlich darf es eine Höchstzahl von Anmerkungen je Nachricht geben.

Bei Migrationen reicht daher kein Blick auf das Capability-Banner. Das Zielpostfach kann eine Nachricht aufnehmen, aber einen privaten oder zu großen Wert ablehnen. Auch fehlende Schreibrechte können die Kontextübernahme verhindern. Der erfolgreiche Transport der Nachricht beweist nicht die erfolgreiche Lieferung aller Anmerkungen.

Größen- und Anzahlfehler gehören in einen eigenen Metadatenbeleg. Wer sie unter einem grünen Nachrichtenergebnis verbirgt, lässt einen Datensatz vollständig erscheinen, obwohl sein Entscheidungsumfeld unvollständig ist.

COPY erzeugt absichtlich kein vollständiges Paket

Bei einem COPY auf demselben Server kopiert eine ANNOTATE-fähige Implementierung alle gemeinsamen Anmerkungen, aber nur die privaten Anmerkungen des aktuell handelnden Nutzers. Private Werte anderer Nutzer darf sie nicht übernehmen. Zielberechtigungen, Nur-Lese-Zustand, fehlende Unterstützung und Größenlimits können die Menge weiter verkleinern.

Das ist guter Schutz der Privatsphäre und zugleich eine Grenze der Beweiskraft. Die Nachricht ist kein versiegeltes Paket aus Inhalt und sämtlichem Wissen darüber. Eine private Untersuchung reist mit, eine andere bleibt zurück. Gemeinsame Etiketten kommen an, sofern das Ziel sie akzeptiert. Zu große Werte fehlen. Die gleichen Nachrichtenbytes stehen danach in einem anderen Wissensraum.

Auch ein kopierter gemeinsamer Wert erhält keine nachträgliche Autorität. Er kann viel später von einem anderen Konto unter einer anderen ACL geschrieben und mehrfach weiterkopiert worden sein. COPY erhält den Wert, nicht automatisch seinen Anlass, seine Urheberschaft oder sein Mandat.

Suchbarkeit macht eine unbelegte Aussage wirkmächtig

Anmerkungswerte können durchsucht werden; Nachrichten lassen sich nach privaten oder gemeinsamen Werten sortieren. Damit beeinflusst eine Randnotiz Warteschlangen, Prioritäten, Aufbewahrung und Automatisierung. Je stärker sie Handlungen steuert, desto wichtiger wird eine überprüfbare Provenienz.

Ein Wert kann syntaktisch gültig, durch die ACL lesbar und fehlerfrei kopiert sein und trotzdem veraltet oder falsch sein. Die Registrierung eines Standardnamens oder eines Herstellernamensraums definiert die Interpretationsfläche, bestätigt aber keine konkrete Instanz.

RFC 5464 behandelt später Metadaten auf Server- und Postfachebene statt je Nachricht. Diese eigene Reichweite ist aufschlussreich: „Metadaten“ bilden keine einheitliche Autorität. Objekt, Schreiber, Bewegungsregel und Verbraucher entscheiden darüber, was ein Wert aussagen kann.

Für die Anmerkung braucht es einen eigenen Beleg

Für folgenreiche Werte sollten Postfach und UID, Nachrichten- oder Körperteilbereich, Eintragsname, .priv/.shared, Identität und Zugang des Schreibers, ACL- und Capability-Abbild, Hashes des alten und neuen Werts, Zustandsmarke, Serverergebnis, Löschereignis, Größen- oder Quotenentscheidung und jede ausgelöste Folgeaktion erhalten bleiben.

Bei einer Kopie kommen Quelle, Ziel, Akteur, unterstützte Modi sowie jedes kopierte oder übersprungene Attribut mit Grund hinzu. Die Darstellung muss Schreiber, Zeitpunkt und Sichtklasse zeigen und darf die Anmerkung nicht wie Text des Absenders aussehen lassen.

Auch die Sprache des Berichts muss präzise bleiben. „Nach dieser Änderung enthielt die gemeinsame Anmerkung ‚freigegeben‘“ ist prüfbar. „Der Absender gab frei“ benötigt dessen Autoritätskette. „Der gesamte Prüfungskontext wurde übernommen“ gilt nur mit einem vollständigen Kopierbeleg.

RFC 5257 schafft nützlichen, dauerhaften Kontext. Führungsverantwortung beginnt dort, wo dieser Kontext nicht die Stimme des Datensatzes annehmen darf, den er lediglich begleitet.

Quellen