Zusammenfassung

  • RFC 3382 ergänzte IPP um eine optionale Collection-Syntax, die unterschiedlich typisierte, benannte Mitglieder in einem Wert bündelte und auch Verschachtelung sowie spätere optionale Mitglieder zuließ.
  • Die Reihenfolge blieb ausdrücklich unverbindlich. Ein Drucker durfte Mitglieder anders zurückgeben; Bedeutung musste deshalb an eindeutigen Namen und Collection-Grenzen hängen.

Ein Client sendet drei Mitglieder. Der Drucker gibt dieselben drei zurück, nur in anderer Folge. Wer die zweite Position mit einer festen Identität verwechselt, sieht beschädigte Daten. Wer RFC 3382 folgt, prüft Name, Syntax, Wert und umgebende Collection. Die Darstellung hat sich bewegt, die Mitgliedschaft nicht.

Der im September 2002 auf dem Standards Track veröffentlichte RFC schloss eine strukturelle Lücke des Internet Printing Protocol. IPP konnte viele einfache und wiederholte Werte ausdrücken, besaß aber keine allgemeine Form, verschiedenartige Attribute als eine Einheit zu gruppieren. Der Vergleich mit einem PostScript Dictionary oder einer Java Map meinte Zuordnung durch Namen, nicht die Übernahme eines vollständigen Programmiersprachen-Objekts.

Eine Collection enthielt ein oder mehrere Member Attributes. Jedes behielt Namen und Syntax, etwa Ganzzahl, Schlüsselwort oder Wertebereich. Ein Mitglied konnte selbst eine Collection oder eine Menge von Collections sein. Der Behälter glättete die Typen nicht, sondern zog eine Grenze um zusammengehörige Werte.

Diese Grenze versprach keine Abfolge. Mitglieder durften in beliebiger Reihenfolge auftreten; ein Drucker durfte sie anders speichern und zurückgeben als angefordert. Die zweite Stelle bedeutete daher nicht zuverlässig Höhe, die letzte nicht zuverlässig Farbe. Position gehörte zu einer konkreten Serialisierung, Identität zum Namen in seinem Geltungsbereich.

Ein Dokument, das ein echtes Collection-Attribut definierte, musste Name, Ein- oder Mehrwertigkeit, Kontext und Ermittlung unterstützter Mitglieder angeben. Für jedes Mitglied waren Anforderungsgrad, Syntax, Semantik, Einschränkungen, unterstützte Werte und Standardwerte zu beschreiben. RFC 3382 stellte die Grammatik bereit, nicht die fertigen Bedeutungen aller künftigen Collections.

Innerhalb einer Definition mussten Namen eindeutig sein. Derselbe Name durfte in einer anderen Collection oder im größeren IPP-Namensraum vorkommen, weil die Collection die Reichweite festlegte. So blieb Wiederverwendung möglich, ohne die Auflösung innerhalb eines Wertes zweideutig zu machen.

Zwei Mitglieder gleichen Namens machten einen Collection-Wert fehlerhaft. Clients durften ihn nicht senden, Drucker nicht zurückgeben. Ein empfangender Drucker durfte die Anfrage ablehnen oder sie annehmen und abhängig von der Implementierung nur eines der Duplikate verwenden. Der RFC versprach weder „erstes gewinnt“ noch „letztes gewinnt“. Reihenfolge konnte gebrochene Eindeutigkeit nicht heilen.

Verschachtelung erhöhte die Ausdruckskraft. Für die Collection insgesamt galt keine einheitliche Längengrenze, wohl aber für jedes Mitglied dessen eigene Syntaxgrenze. Das Ergebnis war kein formloses Dokument: Blätter blieben IPP-Werte, und die zulässige Struktur musste definiert sein.

Optionale Mitglieder ermöglichten Weiterentwicklung. Eine ältere Implementierung musste ein neues Mitglied nicht verstehen, sollte aber das Nichtunterstützte im richtigen Zusammenhang sichtbar machen. Der Unsupported Attributes Group konnte ein problematisches Mitglied innerhalb einer Collection übergeben werden. Eine flache Fehlermeldung hätte den Geltungsbereich verloren.

Auf dem Draht rahmten begin-collection, member-name und end-collection die Struktur. Das Design berücksichtigte ältere IPP-Parser, damit sie interne Mitgliedsnamen nicht mit normalen Attributen der obersten Ebene verwechselten. Kompatibilität verlieh ihnen keine neue Semantik; sie begrenzte die Folgen des Nichtwissens.

media-col und job-sheet-col waren erläuternde Beispiele. Sie zeigten erforderliche und optionale Mitglieder, Ermittlung und Verschachtelung, standardisierten aber nicht selbst eingesetzte Attribute. Dafür brauchte es weiterhin ein definierendes Dokument.

RFC 3380 behandelte atomare Änderungen von Job-Attributen, RFC 3381 kontextabhängige Fortschrittszähler. RFC 3382 stellte eine andere Frage: Wie reisen typisierte Werte als Einheit, ohne dass ihre physische Reihenfolge Bedeutung erhält?

Die Erweiterung aktualisierte RFC 2910 und RFC 2911. RFC 2565 und RFC 2566 bildeten die IPP/1.0-Grundlage, RFC 2567 und RFC 2568 hielten Anforderungen und Entwurf fest. RFC 8010 und RFC 8011 konsolidierten später Kodierung und Modell. Diese Chronologie beweist weder Implementierung noch Druckergebnis.

Die Trennung bleibt wichtig, weil Systeme Darstellung leicht zu Identität machen. Ein Parser erzeugt eine Liste, eine Oberfläche übernimmt sie, und bald trägt das dritte Element eine nie spezifizierte Bedeutung. Normalisierung, ein neues optionales Mitglied oder Wiederaufbau aus einer Map lässt die Annahme scheitern.

Lu Hengs Linse der minimalen Anfangsspezifikation erklärt die Zurückhaltung: einen wiederverwendbaren Behälter und Pflichten künftiger Definitionen standardisieren, ohne jede Zukunftsentscheidung vorwegzunehmen. Seine Realitätsebenen trennen kodierte Ordnung, Mitgliedsidentität, Unterstützung, Annahme und physische Wirkung.

RFC 3382 bewahrte damit Beziehungen, während sich Repräsentation verändern durfte. Die Collection hielt Mitglieder zusammen. Eindeutige Namen und Grenzen hielten sie verständlich. Reihenfolge blieb ein zufälliges Merkmal einer Kodierung.

Quellen