Zusammenfassung

  • RFC 3510 gab IPP-Diensten und Jobs absolute ipp:-Adressen, erklärte aber ausdrücklich, dass keine Abbildung von einer Job-URL zurück zur URL des erzeugenden Printer spezifiziert war.
  • Ein zusätzliches Pfadsegment war eine Empfehlung für Interoperabilität, kein Nachweis für Endpunktidentität, dauerhafte Gültigkeit, Annahme des Auftrags oder Papierausgabe.

Eine URL wie ipp://example.com/printer/123 legt eine einfache Deutung nahe. Die 123 wäre der Job, alles davor sein Printer. Entfernt man das letzte Segment, scheint der Erzeuger festzustehen. RFC 3510 gehört zu den Dokumenten, die eine solche plausible Lesart ausdrücklich von einer Protokollregel trennen.

Der Standard erschien im April 2003 im Standards Track und präzisierte den IPP-URL-Abschnitt von RFC 2910. Er definierte den Anwendungsbereich des Schemas ipp:, Port 631 als Vorgabe, den Medientyp application/ipp, Zeichenkodierung, Syntax und Vergleich. Neue URL-Parameter fügte er nicht hinzu.

Eine ipp:-URL lokalisiert einen IPP-Druckdienst oder eine von ihm verwaltete Netzwerkressource wie einen Job. Sie darf nur absolut sein. Sie verbindet das abstrakte Modell aus RFC 2911 mit HTTP als Transport gemäß RFC 2910; für einen anderen Transport wäre ein anderes Schema nötig. Das Präfix steht somit nicht allgemein für Drucken, sondern für eine konkrete Bindung.

Fehlt der Port, gilt 631. Beim Vergleich ist ein ausgelassener Port mit :631 gleichwertig. Ohne Pfad wird / zur Request-URI. Anfragen und Antworten verwenden application/ipp. Diese Festlegungen beseitigen unnötige Unterschiede zwischen Schreibweisen und schaffen einen gemeinsamen Ausgangspunkt.

Der Pfad bildet jedoch keine Hardwaretopologie ab. Auf demselben Host können mehrere logisch unabhängige Printer liegen. Ein Pfad kann ein Gerät bezeichnen, ein anderer einen Lastverteilungs-Spooler, ein dritter eine Gerätegruppe. Zwei Warteschlangen für verschiedene Menschen können auf derselben physischen Maschine als getrennte Printer erscheinen.

Printer ist im IPP-Modell ein Softwareobjekt. Es kann auf einem Spooler, Gateway oder physischen Druckgerät laufen. Eine erreichbare URL zeigt daher weder, welche Hardware schließlich druckt, noch ob weitergeleitet wird oder eine menschliche Queue das Ziel bestimmt. Logische Trennung erzeugt keine physische Transparenz.

Beim Job wird die Lücke unübersehbar. RFC 2911 hatte das genaue Format einer Job URI der Implementierung überlassen. Damit war auch die Beziehung zwischen dem im Print-Job gesendeten printer-uri und dem zurückgegebenen job-uri implementierungsabhängig. RFC 3510 nannte eine frühere Aussage falsch, wonach der Job URI allein den erzeugenden Printer identifizieren könne: Die umgekehrte Transformation war nie festgelegt worden.

Als begrenzte Lösung empfiehlt der Text, eine Job-URL durch genau ein zusätzliches Pfadsegment an der zugehörigen Printer-URL zu bilden. Das SHOULD schafft Vorhersagbarkeit für Implementierungen, die ihm folgen. Es macht daraus aber kein universelles Gesetz für alte oder fremde URLs. Begründete Ausnahmen, ältere Software und Gateways mit übernommenen Namensräumen bleiben möglich.

Darum ist der ursprüngliche Austausch stärker als spätere Pfadchirurgie. Ein Client sollte den verwendeten printer-uri, den empfangenen job-uri, die authentisierte Serveridentität, die Antwort und den Zeitpunkt gemeinsam sichern. Pfade lassen sich kopieren, umschreiben oder wiederverwenden. Die Transaktionsspur zeigt, welcher Dienst den Namen in welchem Zusammenhang ausgegeben hat.

Auch zeitlich ist der Name begrenzt. Eine Job-URL ist laut RFC nur bis zum Abschluss des Jobs und gegebenenfalls für eine von der Implementierung bestimmte Aufbewahrungsfrist sinnvoll. Sie ist kein ewiger Archivschlüssel. Wenn sie später nicht mehr funktioniert, kann der Dienst das Objekt schlicht gelöscht haben.

Die Sicherheitsbetrachtung trennt Syntax und Identität. Eine gefälschte IPP-URL kann vertrauliche Dokumente zu einem bösartigen Dienst lenken; dagegen hilft Serverauthentisierung. Ein echter Dienst kann über eine gültige URL von einem unberechtigten Client angesprochen werden; dagegen helfen Clientauthentisierung und Autorisierung.

Ein IPP-zu-LPD-Gateway unterbricht die Beweiskette noch stärker. RFC 3510 warnt vor einem stillen Verlust der IPP-Sicherheitsmechanismen und sieht keine praktische Abwehr durch den Client. Administratoren sollen solche Konfigurationen vermeiden. Die Authentisierung der nahen IPP-Seite sagt nichts Sicheres über den anschließenden Abschnitt.

Die URL trägt zudem keine Parameter für den erforderlichen Authentisierungs- oder Sicherheitsmechanismus. Discovery- oder Directory-Protokolle können diese Information liefern. Der Arbeitskreis erwog zusätzliche Parameter, verwarf sie jedoch zugunsten der Rückwärtskompatibilität mit bereits ausgelieferten IPP/1.1-Implementierungen.

Eine belastbare Beweiskette führt daher von gültiger Syntax über Auflösung, HTTP-Bindung und application/ipp zur Serveridentität, Clientberechtigung, Annahme der Operation, Erzeugung des Jobs, Ausgabe einer zeitgebundenen Referenz, einem definierten Endzustand, physischer Ausgabe und schließlich Übergabe. Jede Stufe kann wahr sein, während die nächste scheitert.

Ein authentischer Dienst kann ablehnen. Ein angenommener Job kann abgebrochen werden. Software kann „abgeschlossen“ melden, bevor das Gerät Papier ausgibt. Der Ausdruck kann in der falschen Ablage oder bei der falschen Person landen. RFC 3510 ordnet den Locator, nicht diese gesamte Wirklichkeit.

Mit Lu Hengs Trennung von symbolischer und operativer Realität wird der Entwurf besonders klar. Die standardisierte Zeichenfolge schafft eine gemeinsame symbolische Route. Laufender Code bestimmt das Objekt dahinter, die Benennung, die Lebensdauer und das Gateway. Der RFC belegt einen technischen Vertrag, weder Verbreitung noch das Drucken eines bestimmten Dokuments.

Die historische Leistung von RFC 3510 liegt deshalb in seiner Disziplin. Er normierte, was die Adresse leisten sollte, und widersprach einer bequemen Überdehnung. Die Job-URL konnte den Job benennen. Ohne Austausch- und Implementierungsnachweis verriet sie nicht, welcher Printer ihn erzeugt hatte.

Quellen