Zusammenfassung

  • RFC 6690 machte aus dem Web-Linking-Modell von RFC 5988 eine knappe Repräsentation mit dem Medientyp application/link-format. Der Pfad /.well-known/core wurde im Rahmen der Well-Known-URIs als Einstieg in die Ressourcensuche registriert.
  • Ein Link kann Ressourcentyp rt, Schnittstelle if, Inhaltsformat ct und geschätzte Höchstgröße sz enthalten. Der Client darf eine gefilterte Liste anfordern; der Server muss Filter nicht implementieren.
  • Die Liste bezeichnet das Ziel der nächsten Anfrage. Messwert oder Ergebnis liefert die Zielressource in einer eigenen Antwort. CoAP nahm die Ressourcensuche später in sein Übertragungsmodell für eingeschränkte Knoten auf.

Kein Mensch sitzt am Empfang

Wer vor einem Bildschirm sitzt, folgt sichtbaren Links. Eine kleine Steuerung im Heizungsraum hat weder Bildschirm noch Angestellte, die ihr einen Temperatur- oder Lichtsensor suchen. RFC 6690 beschreibt Acht-Bit-Mikrocontroller und Netze mit geringem Energieverbrauch. Speicher und Datenverkehr sind dort knapp. Eine fest eingebaute Adressliste wird falsch, sobald ein Sensor ersetzt oder eine Ressource verschoben wird. Die Steuerung klopft dann weiter an der alten Tür.

Die Spezifikation setzt einen bekannten Anfangspunkt: /.well-known/core. Ein Server, der sie umsetzt, bietet diese Ressource auf dem Standardport des jeweiligen Protokolls an. GET erhält einen Körper im CoRE Link Format; ohne bekanntgemachte Links darf der Körper leer sein. Die Beispielzeile </sensors/temp>;rt="temperature-c";if="sensor" fasst Pfad, Typ und Schnittstelle in wenige Zeichen. Findet der Client den Link eines Lichtsensors, kann er eine zweite Anfrage an dessen URI richten.

Die erste Anfrage holt eine Karte. Die zweite erreicht die Ressource. Ein Sensor auf der Karte kann inzwischen schlafen, seinen Zustand geändert haben oder eine Zugangsprüfung verlangen. Der gemeinsame Empfang spart die Suche nach einem Einstieg, ohne den einzelnen Ressourcen ihre eigene Antwort abzunehmen.

Der Link wurde zum Antwortkörper

RFC 5988 beschreibt eine typisierte Beziehung zwischen Kontext und Ziel. RFC 6690 übernimmt die Form des HTTP-Feldes Link, legt sie aber als selbständige Ressourcendarstellung mit dem Medientyp application/link-format auf den Draht. Eine Ziel-URI steht in spitzen Klammern, danach folgen Attribute; Kommas trennen die Einträge. Kleine Geräte können das ohne einen umfangreichen XML-Baum lesen. Der Client fordert die Karte als Ressource an, anstatt sie aus dem Header einer anderen Antwort herauszufischen.

Die Attribute beantworten verschiedene Fragen. rt benennt einen durch die Anwendung festgelegten semantischen Ressourcentyp, etwa eine Temperaturmessung. if beschreibt die Schnittstelle für die Interaktion; dieselbe Schnittstelle kann mehrere Ressourcentypen bedienen. ct nennt ein Inhaltsformat. sz schätzt die maximale Größe der Darstellung, die GET zurückgeben würde. Eine Steuerung mit wenig Speicher kann damit den Empfang planen. rt ist kein Anzeigename für Menschen; dafür gibt es title. Die Attribute helfen bei der Wahl einer Adresse, die aktuelle Messung muss am Ziel eingeholt werden.

Ohne ausdrückliches rel gilt die Beziehung hosts: Der Kontextserver beherbergt das Ziel. Ein gesetztes rel oder anchor kann eine andere Beziehung ausdrücken, auch zu einer Ressource auf einem fremden Server. Wer aus der Liste nur URIs abschreibt und den Kontext wegwirft, macht aus einer externen Beschreibung leicht eine vermeintlich lokale Ressource. Die knappe Syntax trägt also eine wichtige Aussage darüber, wer wofür spricht.

Der Empfang darf klein bleiben

/.well-known/core muss nicht alle Sensoren auf einmal aufzählen. Die Anwendung entscheidet, welche Links erscheinen und wie sie geordnet sind. Sie kann nur die Sammlung /sensors nennen und die einzelnen Messgeräte hinter deren eigener Link-Darstellung aufführen. So muss der kleine Server nicht bei jeder ersten Frage das gesamte Gebäudeinventar übertragen.

Ein Client kann gezielter fragen: GET /.well-known/core?rt=light-lux sucht Links mit diesem Ressourcentyp. RFC 6690 beschreibt die Filtermöglichkeit, verpflichtet den Server aber nicht zu ihrer Umsetzung. Eine leere Antwort verlangt deshalb eine Prüfung: Hat der Server den Filter verstanden, welche Links veröffentlicht er und sieht dieser Client dieselbe Liste wie andere? rt und if gehören zum Wortschatz der Anwendung, nicht zu einem weltweiten Verzeichnis aller Sensormodelle.

Manche Sensoren schlafen; manche Verbindungen verkraften keine Direktabfrage jedes Endpunkts durch jeden Client. RFC 6690 skizziert daher ein Ressourcenverzeichnis, das Links anderer Server hält. Ein leistungsfähigerer Knoten kann die Kopien durchsuchbar machen. Die vollständige Verzeichnisfunktion liegt außerhalb der Spezifikation. Der Ursprungsserver veröffentlicht eine Beschreibung, das Verzeichnis verwahrt sie, der Client wählt ein Ziel und die Ressource antwortet. Ein alter Verzeichniseintrag kann noch auf eine nicht mehr passende Adresse zeigen.

Die Karte hat einen Verwalter

Der Empfang entstand aus mehreren begrenzten Vereinbarungen. RFC 5785 gab den bekannten URI-Pfad vor, RFC 5988 die Linkbeziehungen und RFC 6690 eine kompakte Darstellung für kleine Server. RFC 7252 nahm 2014 die Ressourcensuche in CoAP auf. Das ist ein lokaler Startpunkt auf jedem Server und kein zentrales Register sämtlicher Sensoren.

Der Server bestimmt seine Liste. Er kann sie schützen und verschiedenen Clients verschiedene Links zeigen. Wer eine URI bereits kennt oder errät, wird durch das bloße Verbergen des Links nicht aufgehalten; die Zielressource muss die spätere Anfrage selbst prüfen. Soll die Herkunft der Karte verlässlich sein, muss der Client ihre Quelle authentifizieren. Empfang, Verzeichnis und Sensor sind unterschiedliche Verantwortungsorte.

Die vier offiziellen Texte belegen Format, registrierten Pfad und vorgesehenen Ablauf. Ob ein bestimmtes Gebäude ihn nutzte, würde erst aus datierter Gerätefirmware, einer aufgezeichneten /.well-known/core-Antwort und der folgenden Sensoranfrage hervorgehen. Die Steuerung vom Anfang hat eine Adresse bekommen. Den Helligkeitswert liefert das Gerät hinter der Tür.