Zusammenfassung

  • Version 05 von JMAP Object Metadata führt am 28. Oktober den Wert Binary ein: genau @type und ein gültiges, aufgefülltes base64-Feld. Der Server bewahrt die gültige Form exakt; fehlerhafte Werte werden beim Schreiben abgewiesen.
  • Der Wert zählt bei der Verschachtelung als Tiefe null. Trotzdem können Patch- und Abfragepfade nicht durch ihn hindurch; Textfilter finden seinen Inhalt nie. Version 04 enthielt diesen Abschnitt noch nicht.

Der Eintrag ist da. Das Suchfeld kommt nicht hinein.

Im Beispiel des Entwurfs liegt ein 32-Byte-Fingerabdruck in einem herstellereigenen Namensraum. Nach dem Vorhandensein des Eintrags lässt sich fragen. Nach einer Bytefolge im Fingerabdruck lässt sich mit dem Textfilter nicht suchen. Ein Patch auf das innere base64-Feld scheitert ebenfalls. Die Kapsel sieht in JSON wie ein Objekt aus, gilt im Protokoll jedoch als einzelner Wert.

Der neue Abschnitt löst ein Formatproblem: JSON-Zeichenketten tragen Unicode-Text, nicht beliebige Rohbytes. Er verlangt genau zwei Felder und Base64 mit Füllzeichen. Ein fehlerhafter Wert führt zu invalidProperties, ein Pfad durch die Kapsel zu invalidPatch. Der Server ist Verwahrer der Zeichenfolge. Der Namensraum bestimmt, welche Bedeutung die Bytes haben.

Dieser Namensraum kann ein registrierter Name oder die kleingeschriebene Domain des Anbieters sein. Für die eigene Domain ist keine vorherige Registrierung bei IANA nötig. Der Server entscheidet, ob er solche Namensräume für den jeweiligen Objekttyp zulässt. Lesen dürfen gemeinsame Metadaten Nutzer mit Zugriff auf das Objekt; private Metadaten gehören zum jeweiligen Nutzer. Diese Rechte standen schon vor Version 05 im Entwurf. Neu ist die versiegelte Form innerhalb der vorhandenen Rechte.

Tiefe null klingt großzügig, sagt aber nichts über den Speicherbedarf. Die Tiefe begrenzt Verschachtelung. Quoten und mögliche Größenlimits begrenzen Platz; ein Überschreiten ergibt overQuota. Selbst gewöhnliche Textfilter darf ein Server bei zu hohen Implementierungskosten ablehnen. Wer „durchsuchbare Metadaten“ einkauft, braucht deshalb drei Antworten: Welcher Feldtyp liegt vor, welcher Filter funktioniert, und wie werden die gespeicherten Bytes berechnet?

Laut IETF-Datatracker ist das Dokument weiterhin ein Arbeitsgruppen-Internet-Draft. Eine konkrete Serverprobe müsste gültige Bytes schreiben, identisch zurücklesen, die Suche und den Patch testen und den Quotenverbrauch zeigen. Ohne diese Spur bleibt die Kapsel eine präzise Regel auf Papier.

Quellen: Version 05; Version 04; IETF-Status.