Zum Hauptinhalt springen

RFC 8288 - Web Linking (Web-Verlinkung)

  • Status: Proposed Standard
  • Veröffentlicht: October 2017
  • Stream: IETF
  • Ersetzt: RFC5988
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Diese Spezifikation definiert ein Modell für die Beziehungen zwischen Ressourcen im Web ("Links", links) und den Typ dieser Beziehungen ("Link-Relationstypen", link relation types).

Sie definiert auch die Serialisierung solcher Links in HTTP-Headern mit dem Link-Header-Feld.

Inhaltsverzeichnis (Contents)​

1. Introduction (Einführung)​

Diese Spezifikation definiert ein Modell für Beziehungen zwischen Ressourcen im Web („Links") sowie die Typen dieser Beziehungen („Link-Relationstypen", link relation types).

Sowohl HTML [W3C.REC-html5-20141028] als auch Atom [RFC4287] haben klar definierte Link-Konzepte; Abschnitt 2 verallgemeinert diese zu einem Framework, das Links in diesen Formaten und (möglicherweise) anderswo abdeckt.

Darüber hinaus definiert Abschnitt 3 ein HTTP-Headerfeld zur Übermittlung solcher Links.

1.1. Notational Conventions (Notationskonventionen)​

Die Schlüsselwörter „MUST", „MUST NOT", „REQUIRED", „SHALL", „SHALL NOT", „SHOULD", „SHOULD NOT", „RECOMMENDED", „NOT RECOMMENDED", „MAY" und „OPTIONAL" in diesem Dokument sind gemäß BCP 14 [RFC2119] [RFC8174] zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Dieses Dokument verwendet die Augmented Backus-Naur Form (ABNF) [RFC5234]-Notation aus [RFC7230], einschließlich der #-Regel, und schließt explizit folgende Regeln ein: quoted-string, token, SP (Leerzeichen), BWS (schlechtes Leerzeichen), OWS (optionales Leerzeichen), RWS (erforderliches Leerzeichen), LOALPHA, DIGIT.

Außerdem sind folgende Regeln eingeschlossen:

  • URI und URI-Reference aus [RFC3986]
  • type-name und subtype-name aus [RFC6838]
  • media-query-list aus [W3C.REC-css3-mediaqueries-20120619]
  • Language-Tag aus [RFC5646]

1.2. Conformance and Error Handling (Konformität und Fehlerbehandlung)​

Die in Abschnitt 2.5 von [RFC7230] hervorgehobenen Anforderungen an Konformität und Fehlerbehandlung gelten für dieses Dokument.

In dieser Spezifikation ist ein Link eine typisierte Verbindung zwischen zwei Ressourcen, bestehend aus:

  • einem Link-Kontext (link context)
  • einem Link-Relationstyp (link relation type) (Abschnitt 2.1)
  • einem Link-Ziel (link target)
  • optionalen Zielattributen (target attributes) (Abschnitt 2.2)

Ein Link kann als Aussage der folgenden Form betrachtet werden: „Der Link-Kontext hat eine Ressource vom Link-Relationstyp am Link-Ziel, die die Zielattribute aufweist."

Zum Beispiel: „https://www.example.com/" hat eine „canonical"-Ressource unter „https://example.com", die den „type" „text/html" hat.

Sowohl Link-Kontext als auch Link-Ziel sind Internationalized Resource Identifiers (IRIs) [RFC3987]. Im häufigen Fall wird der Link-Kontext jedoch auch ein URI [RFC3986] sein, da viele Protokolle (wie HTTP) das Dereferenzieren von IRIs nicht unterstützen. Ebenso werden Link-Ziele manchmal in Serialisierungen, die keine IRIs unterstützen (z. B. das in Abschnitt 3 definierte Link-Headerfeld), in URIs umgewandelt (siehe [RFC3987] Abschnitt 3.1).

Diese Spezifikation legt keine Einschränkungen für die Kardinalität von Links fest; es kann mehrere Links zu einem bestimmten Ziel und von einem bestimmten Ziel geben, sowie mehrere Links desselben oder unterschiedlicher Typen zwischen einem gegebenen Kontext und Ziel. Ebenso ist die relative Reihenfolge von Links in einer bestimmten Serialisierung oder zwischen Serialisierungen (z. B. Link-Headerfeld und Links im Inhalt) in dieser Spezifikation nicht festgelegt oder bedeutsam; Anwendungen, die die Reihenfolge berücksichtigen möchten, können dies tun.

Links werden in Link-Serialisierungen übermittelt; sie sind „Bytes auf der Leitung" und können in verschiedenen Formen erscheinen. Zum Beispiel definieren sowohl Atom [RFC4287] als auch HTML [W3C.REC-html5-20141028] Möglichkeiten, Links in ihre jeweiligen Formate zu serialisieren, und Abschnitt 3 definiert, wie Links in HTTP-Headerfeldern serialisiert werden.

Diese Spezifikation definiert keine gemeinsame Syntax für Links über verschiedene Serialisierungen hinweg und schreibt keinen bestimmten Kontext für einen gegebenen Link vor; es wird erwartet, dass die Serialisierung von Links beide Aspekte spezifiziert.

Schließlich werden Links von Link-Anwendungen verwendet. Typischerweise definiert eine Anwendung die von ihr verwendeten Link-Relationstypen sowie die Serialisierungen, in denen sie erscheinen können. Zum Beispiel sucht die Anwendung „Web-Browsing" nach dem „stylesheet"-Link-Relationstyp in HTML-Link-Serialisierungen (und optional im Link-Headerfeld), während die Anwendung „AtomPub" die Link-Relationen „edit" und „edit-media" in Atom-Serialisierungen verwendet.

Im einfachsten Fall identifiziert ein Link-Relationstyp die Semantik eines Links. Zum Beispiel zeigt ein Link mit dem Relationstyp „copyright" an, dass der aktuelle Link-Kontext eine Copyright-Ressource am Link-Ziel hat.

Link-Relationstypen können auch verwendet werden, um anzuzeigen, dass die Zielressource bestimmte Eigenschaften hat oder ein bestimmtes Verhalten zeigt; zum Beispiel impliziert ein „service"-Link, dass das Link-Ziel als Teil eines definierten Protokolls verwendet werden kann (in diesem Fall eine Dienstbeschreibung).

Relationstypen SOLLTEN NICHT mit Medientypen [RFC2046] verwechselt werden; sie identifizieren nicht das Format der Darstellung, die beim Dereferenzieren des Links entsteht. Stattdessen beschreiben sie nur, wie der aktuelle Kontext mit einer anderen Ressource in Beziehung steht.

Relationstypen SOLLTEN NICHT auf der Grundlage des Vorhandenseins oder Nichtvorhandenseins eines anderen Link-Relationstyps oder der Kardinalität seines eigenen Auftretens zusätzliche Semantik ableiten. Eine Ausnahme bildet die Kombination der registrierten Relationstypen „alternate" und „stylesheet", die aus historischen Gründen in HTML eine besondere Bedeutung hat.

Es gibt zwei Arten von Relationstypen: registrierte und erweiterte.

2.1.1. Registered Relation Types (Registrierte Relationstypen)​

Klar definierte Relationstypen können als Token registriert werden, um ihre Wiederverwendung durch andere Anwendungen zu erleichtern und/oder zu fördern, unter Verwendung des Verfahrens in Abschnitt 2.1.1.1.

Registrierte Relationstyp-Namen MÜSSEN der reg-rel-type-Regel entsprechen (siehe Abschnitt 3.3) und MÜSSEN zeichenweise ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden. Sie SOLLTEN für die Spezifität des Relationstyps geeignet sein; das heißt, wenn die Semantik für eine bestimmte Anwendung sehr spezifisch ist, SOLLTE der Name dies widerspiegeln, damit allgemeinere Namen für weniger spezifische Verwendungen verfügbar sind.

Registrierte Relationstypen DÜRFEN NICHT den Medientyp des Link-Kontexts einschränken und DÜRFEN NICHT die verfügbaren Darstellungsmedientypen des Link-Ziels einschränken. Sie können jedoch das Verhalten und die Eigenschaften der Zielressource spezifizieren (z. B. erlaubte HTTP-Methoden sowie erforderliche Anfrage- und Antwortmedientypen).

2.1.2. Extension Relation Types (Erweiterungs-Relationstypen)​

Anwendungen, die keinen Relationstyp registrieren möchten, können Erweiterungs-Relationstypen verwenden, die URIs [RFC3986] sind, die den Relationstyp eindeutig identifizieren. Obwohl der URI auf eine Ressource verweisen kann, die eine Definition der Semantik des Relationstyps enthält, SOLLTEN Clients diese Ressource nicht automatisch abrufen, um ihre Server nicht zu belasten.

Der für einen Erweiterungs-Relationstyp verwendete URI SOLLTE unter der Kontrolle der Person oder Partei stehen, die ihn definiert, oder an diese delegiert sein.

Beim Vergleich von Erweiterungs-Relationstypen MÜSSEN diese als Zeichenketten (nach Umwandlung in URIs, wenn sie in einem anderen Format serialisiert sind) zeichenweise ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden. Daher SOLLTEN vollständig kleingeschriebene URIs für Erweiterungsrelationen verwendet werden.

Beachten Sie, dass Erweiterungs-Relationstypen zwar URIs sein müssen, die Serialisierung von Links sie jedoch in einer anderen Form darstellen kann, solange sie in URIs umgewandelt werden können.

2.2. Target Attributes (Zielattribute)​

Zielattribute sind eine Liste von Schlüssel/Wert-Paaren, die den Link oder sein Ziel beschreiben; zum Beispiel Medientyp-Hinweise.

Sie können von einzelnen Link-Relationstypen und Link-Serialisierungen definiert werden.

Diese Spezifikation versucht nicht, die Namen von Zielattributen, ihre Kardinalität oder Verwendung zu koordinieren. Personen, die Serialisierungen erstellen und pflegen, SOLLTEN ihre Zielattribute koordinieren, um semantische oder syntaktische Konflikte zu vermeiden, und KÖNNEN ihre eigenen Zielattribut-Registrierungen definieren.

Namen von Zielattributen SOLLTEN der token-Regel entsprechen, SOLLTEN ABER NICHT auf ASCII beschränkt sein; sie SOLLTEN ohne Berücksichtigung der Groß-/Kleinschreibung verglichen werden.

Das Link-Entity-Headerfeld bietet eine Möglichkeit, einen oder mehrere Links in HTTP-Headern zu serialisieren. Es ist semantisch äquivalent zum HTML-Element <link>.

Link       = #link-value
link-value = "<" URI-Reference ">" *( OWS ";" OWS link-param )
link-param = token BWS [ "=" BWS ( token / quoted-string ) ]

Jeder link-value übermittelt einen Link. Das Link-Ziel wird durch die URI-Reference in spitzen Klammern (< und >) dargestellt.

Standardmäßig ist der Kontext eines Links der effektive Anfrage-URI (Effective Request URI) der Nachricht, in der er erscheint, wie in Abschnitt 5.5 von [RFC7230] definiert.

Wenn vorhanden, wird der Kontext durch die Ziel-IRI bestimmt. Beachten Sie, dass jede IRI gemäß Abschnitt 2 in einen URI umgewandelt werden muss, um im Link-Headerfeld dargestellt zu werden.

3.3. Relation Type (Relationstyp)​

Der Link-Relationstyp wird durch den Wert des „rel"-Parameters identifiziert, dessen Wert MUSS eines der folgenden enthalten:

  • einen registrierten Relationstyp-Namen (siehe Abschnitt 2.1.1), oder
  • einen Erweiterungs-Relationstyp (siehe Abschnitt 2.1.2)

Registrierte Relationstyp-Namen und Erweiterungs-Relationstypen können im selben „rel"-Parameterwert verwendet werden, getrennt durch ein oder mehrere Leerzeichen.

relation-type  = reg-rel-type / ext-rel-type
reg-rel-type   = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
ext-rel-type   = URI

Beachten Sie, dass Erweiterungs-Relationstypen als URIs kodiert sind; das bedeutet, dass alle reservierten Zeichen gemäß Abschnitt 2 von [RFC3986] prozentual kodiert werden müssen.

3.4. Target Attributes (Zielattribute)​

Die Zielattribute eines Links werden im link-value als link-param dargestellt.

3.4.1. Serialisation-Defined Attributes (Serialisierungsdefinierte Attribute)​

Der „rel"-Parameter MUSS vorhanden sein, DARF ABER NICHT mehrfach erscheinen; wenn er fehlt oder mehrfach erscheint, ist der gesamte link-value ungültig.

Ebenso MUSS der „anchor"-Parameter (falls vorhanden) nur einmal erscheinen; wenn er mehrfach erscheint, ist der gesamte link-value ungültig.

Weitere häufige Zielattribute sind:

  • hreflang: Gibt die Sprache der Zielressource an. Der Wert MUSS [RFC5646] entsprechen.
  • media: Gibt das beabsichtigte Anzeigemedium der Zielressource an. Der Wert MUSS [W3C.REC-css3-mediaqueries-20120619] entsprechen.
  • title: Ein menschenlesbarer Bezeichner zur Kennzeichnung der Zielressource.
  • title*: Internationalisierte Version des „title"-Parameters mit der in [RFC8187] definierten Kodierung.
  • type: Gibt einen Hinweis auf den Medientyp der Zielressource.

3.4.2. Extension Attributes (Erweiterungsattribute)​

Andere link-param-Werte sind Erweiterungs-Zielattribute, die von Link-Relationstypen oder Link-Anwendungen definiert und verwendet werden können.

Das Vorhandensein oder Fehlen von Erweiterungs-Zielattributen SOLLTE den link-value nicht ungültig machen, KANN aber seine Verwendung in bestimmten Anwendungen beeinflussen.

Zum Beispiel:

Link: <http://example.com/TheBook/chapter2>; rel="previous";
      title="previous chapter"

Gibt an, dass das „vorherige Kapitel" unter http://example.com/TheBook/chapter2 zu finden ist.

Link: </>; rel="http://example.net/foo"

Gibt an, dass die Stammressource ("/") mit dem benutzerdefinierten Erweiterungs-Relationstyp „http://example.net/foo" in Beziehung steht.

Link: </terms>; rel="copyright"; anchor="#foo"

Gibt an, dass die Copyright-Ressource für die Ressource mit dem Bezeichner „foo" unter /terms zu finden ist.

Mehrere Links können in einem einzigen Link-Headerfeld übermittelt werden:

Link: </TheBook/chapter2>; rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
      </TheBook/chapter4>; rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel

Hier verwenden beide Links den internationalisierten title-Parameter.

Es können auch mehrere Link-Headerfelder verwendet werden:

Link: </TheBook/chapter2>; rel="previous"
Link: </TheBook/chapter4>; rel="next"

4. IANA Considerations (IANA-Überlegungen)​

Diese Spezifikation aktualisiert die Definition des „Link"-Headerfelds im „Message Headers"-Register.

Headerfeld-Name: Link

Anwendbares Protokoll: http

Status: Standard

Autor/Änderungsverantwortlicher: IETF

Spezifikationsdokument: Diese Spezifikation (Abschnitt 3)

Diese Spezifikation richtet das „Link Relation Types"-Register unter https://www.iana.org/assignments/link-relations/ ein.

Registrierungsanfragen SOLLTEN folgendes enthalten:

  • Relationsname: Der Name des Relationstyps
  • Beschreibung: Eine kurze englische Beschreibung der Typsemantik
  • Referenz: Verweis auf das Dokument, das den Link-Relationstyp spezifiziert

Diese Spezifikation richtet das „Link Relation Application Data"-Register ein.

Anhänge (Appendices)​

HTML [W3C.REC-html5-20141028] definiert das <link>-Element zur Übermittlung von Links. Zum Beispiel:

<link rel="stylesheet" href="/style.css" type="text/css">

Die Entsprechung zwischen HTML-Links und dem in dieser Spezifikation definierten Link-Modell ist wie folgt:

  • Der Link-Kontext ist der URI des Dokuments, das das Link-Element enthält
  • Der Link-Relationstyp wird durch den Wert des „rel"-Attributs identifiziert
  • Das Link-Ziel wird durch den Wert des „href"-Attributs identifiziert
  • Zielattribute werden durch andere Attribute (wie „type", „media" usw.) dargestellt

Atom [RFC4287] definiert ein Link-Element, das in Feeds und Einträgen erscheinen kann. Zum Beispiel:

<link rel="alternate" type="text/html" 
      href="http://example.org/"/>

Die Entsprechung zwischen Atom-Links und dem in dieser Spezifikation definierten Link-Modell ist wie folgt:

  • Der Link-Kontext ist der URI des Feeds oder Eintrags, der das Link-Element enthält
  • Der Link-Relationstyp wird durch den Wert des „rel"-Attributs identifiziert
  • Das Link-Ziel wird durch den Wert des „href"-Attributs identifiziert
  • Zielattribute werden durch andere Attribute (wie „type", „hreflang" usw.) dargestellt

Dieser Anhang definiert Algorithmen zum Parsen von Link-Headerfeldern. Diese Algorithmen sind normativ.

Gegeben eine Menge von HTTP-Headerfeldern headers:

  1. Sei links eine leere Liste
  2. Für jedes Feld field in headers, dessen Feldname „Link" ist (ohne Berücksichtigung der Groß-/Kleinschreibung):
    • Sei field_value der Feldwert von field
    • Sei field_links das Ergebnis des Parsens von field_value (unter Verwendung des Algorithmus in Abschnitt B.2)
    • Jeden Link in field_links zu links hinzufügen
  3. links zurückgeben

(Algorithmusdetails ausgelassen – siehe Originaltext)

B.3. Parsing Parameters (Parsen von Parametern)​

(Algorithmusdetails ausgelassen – siehe Originaltext)

B.4. Parsing a Quoted String (Parsen einer Zeichenkette in Anführungszeichen)​

(Algorithmusdetails ausgelassen – siehe Originaltext)

Anhang C. Changes from RFC 5988 (Änderungen gegenüber RFC 5988)​

Die wichtigsten Änderungen dieser Spezifikation gegenüber RFC 5988 umfassen:

  • Klarstellung der Definitionen von Link-Kontext und Link-Ziel
  • Aktualisierung der Registrierungsverfahren zur Verwendung von RFC 8126
  • Hinzufügen von Parsing-Algorithmen (Anhang B)
  • Klarstellung der Verwendung von Erweiterungs-Relationstypen
  • Aktualisierung der Verweise auf andere Spezifikationen
  • Verbesserung von Beispielen und erläuterndem Text