Zusammenfassung

  • Mit RFC 3059 konnte ein SLPv2 User Agent durch eine absichtlich leere Erweiterung verlangen, dass jede URL im Service Reply ihre vollständige registrierte Attributliste mitführt.
  • 0x0002 war optional und bei Nichtverstehen zu ignorieren. Fehlte die Erweiterung, musste der Client pro URL einen Attribute Request senden; bestätigt leere Attribute waren damit nicht gemeint. Auch ein nicht lieferbarer Authentisierungsblock für einen verlangten SLP SPI konnte die Erweiterung unterdrücken.

Eine leere Hülle stellte die Frage

Ein Dienstfund und dessen Beschreibung waren in SLPv2 getrennte Ergebnisse. Ein Service Request brachte URLs zurück. Attribute erhielt der User Agent danach über Attribute Requests für eine URL oder einen Diensttyp. Mehr Treffer konnten deshalb mehr Rundläufe bedeuten.

RFC 3059 erschien im Februar 2001 als Proposed Standard und verband beide Informationsklassen. Im Service Request fügte der User Agent eine Attribute List Extension ein. Service URL Length und Attribute List Length standen dabei auf null; die Felder selbst fehlten. Diese Leere war ausführbare Syntax: Sie verlangte Attribute in der Antwort.

Die Nullen beschrieben nicht den Dienst. Wer sie als „keine URL“ oder „keine Attribute“ las, machte aus einer Frage eine Antwort, bevor der angesprochene Agent Daten geliefert hatte.

Die URL verband Kandidat und Beschreibung

Ein unterstützender SA oder DA gab für jeden URL Entry im Service Reply eine Attribute List Extension zurück. Sie enthielt die zugehörige Service URL und die gesamte Attributliste. Die Reihenfolge sollte der der URL Entries entsprechen, doch die URL stand zusätzlich ausdrücklich in jeder Erweiterung.

Damit war die URL der belastbare Join-Schlüssel. Reihenfolge blieb ein Prüfhinweis, aber keine Ersatzidentität. Zwei Arrays allein nach Position zusammenzufügen, hieße eine Protokollangabe zugunsten lokaler Bequemlichkeit zu verwerfen.

„Gesamte Attributliste“ blieb auf die registrierte Beschreibung in der Sprache des Service Request begrenzt. Sie war kein Sensor für alle Eigenschaften eines laufenden Dienstes. Eine Registrierung konnte noch gültig wirken, während der Endpunkt nicht mehr antwortete; eine nicht registrierte Fähigkeit blieb unsichtbar. Die Erweiterung transportierte Werbung effizienter, nicht Ausführungssicherheit.

Die optionale Nummer bestimmte den Kompatibilitätspfad

IANA registrierte 0x0002. RFC 2608 ordnete 0x0000 bis 0x3FFF standardisierten Erweiterungen zu, deren Implementierung optional war und die bei Unkenntnis ignoriert wurden. Ältere Gegenstellen konnten deshalb einen gewöhnlichen Service Reply liefern.

Der User Agent trug die Folgekosten. Bekam er keine Attribute List Extension, sollte er fehlende Unterstützung annehmen und für jede empfangene URL einen Attribute Request senden. Abwesenheit war ein unvollständiger Zustand samt Reparaturweg, kein bestätigter Nullwert.

Andere Erweiterungen folgten anderen Regeln. Select und Sort in RFC 3421 lagen im verpflichtenden Bereich und kannten OPTION_NOT_UNDERSTOOD. RFC 3224 und RFC 3082 beschrieben wiederum Herstellerdaten und Benachrichtigungen. Diese Unterschiede zeigen, warum das Wort „Erweiterung“ allein keine Fehlersemantik festlegt.

Der SPI konnte dieselbe Lücke erzeugen

Ein Service Request durfte einen SLP Security Parameter Index enthalten. Dann musste jede zurückgesandte Attributerweiterung einen passenden Authentisierungsblock tragen. Konnte der SA oder DA diesen Block nicht unterstützen oder erzeugen, durfte er die Erweiterung nicht zurückgeben.

Die sichtbare Lücke konnte daher auf nicht implementiertes 0x0002 oder auf einen unerfüllbaren Authentisierungskontext zurückgehen. RFC 3059 gab dem Client einen sicheren nächsten Schritt, aber keine Grundlage, die genaue Ursache aus Schweigen abzuleiten.

Auch der Authentisierungsblock war ein begrenzter Beleg. Nach RFC 2608 bestätigte er unter SPI-Schlüsselmaterial und Ablaufzeit, dass die abgedeckten Daten unverändert von einem autorisierten Agenten kamen. Er bewies weder aktuelle Erreichbarkeit noch Benutzerberechtigung noch den Erfolg einer späteren Anwendung.

Weniger Nachrichten machten die Beschreibung nicht mächtiger

Vier gefundene URLs konnten auf einen Service Request und vier Attribute Requests hinauslaufen. Bei beiderseitiger Unterstützung kam die registrierte Beschreibung in einer Antwort. Latenz und Nachrichtenzahl änderten sich, nicht die Zuständigkeit der Daten.

Wird diese Grenze verwischt, zeigt eine Oberfläche „keine Fähigkeiten“, weil Anreicherung ausblieb; ein Inventar speichert null, weil der Fallback fehlte; ein Selektor verwirft einen Kandidaten, weil „hier nicht mitgeführt“ zu „existiert nicht“ wurde. RFC 3059 verlangte das Gegenteil: fehlenden Beleg markieren und pro URL nachfragen.

Quellen