Aller au contenu principal

RFC 8288 - Web Linking (Liaison Web)

  • Statut: Proposed Standard
  • Publié: October 2017
  • Stream: IETF
  • Remplace: RFC5988
  • Errata: Pas d'errata

Résumé (Abstract)​

Cette spécification définit un modèle pour les relations entre les ressources sur le Web (« liens », links) et le type de ces relations (« types de relation de lien », link relation types).

Elle définit également la sérialisation de tels liens dans les en-têtes HTTP avec le champ d'en-tête Link.

Table des matières (Contents)​

1. Introduction​

Cette spécification définit un modèle pour les relations entre ressources sur le Web (« liens », links) ainsi que les types de ces relations (« types de relation de lien », link relation types).

HTML [W3C.REC-html5-20141028] et Atom [RFC4287] ont tous deux une notion de lien bien définie ; la section 2 généralise cela en un cadre couvrant les liens dans ces formats et (potentiellement) ailleurs.

De plus, la section 3 définit un champ d'en-tête HTTP permettant de véhiculer de tels liens.

1.1. Notational Conventions (Conventions de notation)​

Les mots-clés « MUST » (DOIT), « MUST NOT » (NE DOIT PAS), « REQUIRED » (REQUIS), « SHALL » (DEVRA), « SHALL NOT » (NE DEVRA PAS), « SHOULD » (DEVRAIT), « SHOULD NOT » (NE DEVRAIT PAS), « RECOMMENDED » (RECOMMANDÉ), « NOT RECOMMENDED » (NON RECOMMANDÉ), « MAY » (PEUT) et « OPTIONAL » (OPTIONNEL) dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174], si et seulement s'ils apparaissent en majuscules, comme indiqué ici.

Ce document utilise la notation ABNF (Augmented Backus-Naur Form, forme de Backus-Naur augmentée) [RFC5234] de [RFC7230], y compris la règle #, et inclut explicitement les règles suivantes : quoted-string, token, SP (espace), BWS (mauvais espace blanc), OWS (espace blanc optionnel), RWS (espace blanc requis), LOALPHA, DIGIT.

Les règles suivantes sont également incluses :

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

1.2. Conformance and Error Handling (Conformité et gestion des erreurs)​

Les exigences relatives à la conformité et à la gestion des erreurs soulignées dans la section 2.5 de [RFC7230] s'appliquent à ce document.

Dans cette spécification, un lien est une connexion typée entre deux ressources, composée des éléments suivants :

  • un contexte de lien (link context)
  • un type de relation de lien (link relation type) (section 2.1)
  • une cible de lien (link target)
  • des attributs de cible optionnels (target attributes) (section 2.2)

Un lien peut être considéré comme l'affirmation suivante : « le contexte de lien possède une ressource de type relation de lien à la cible de lien, laquelle possède les attributs de cible ».

Par exemple, « https://www.example.com/ » possède une ressource « canonical » à « https://example.com », laquelle a un « type » de « text/html ».

Le contexte de lien et la cible de lien sont tous deux des IRI (Internationalized Resource Identifiers, identifiants de ressources internationalisés) [RFC3987]. Cependant, dans le cas courant, le contexte de lien sera également un URI [RFC3986], car de nombreux protocoles (comme HTTP) ne prennent pas en charge le déréférencement des IRI. De même, la cible de lien est parfois convertie en URI dans les sérialisations qui ne prennent pas en charge les IRI (par exemple, le champ d'en-tête Link défini à la section 3) (voir la section 3.1 de [RFC3987]).

Cette spécification n'impose aucune restriction sur la cardinalité des liens ; il peut y avoir plusieurs liens vers une cible particulière et depuis une cible particulière, ainsi que plusieurs liens du même type ou de types différents entre un contexte et une cible donnés. De même, l'ordre relatif des liens dans une sérialisation particulière ou entre sérialisations (par exemple, entre le champ d'en-tête Link et les liens dans le contenu) n'est pas spécifié ni significatif dans cette spécification ; les applications souhaitant considérer l'ordre comme significatif peuvent le faire.

Les liens sont véhiculés dans des sérialisations de liens ; ce sont des « octets sur le fil » qui peuvent prendre diverses formes. Par exemple, Atom [RFC4287] et HTML [W3C.REC-html5-20141028] définissent tous deux des façons de sérialiser des liens dans leurs formats respectifs, et la section 3 définit comment sérialiser des liens dans des champs d'en-tête HTTP.

Cette spécification ne définit pas de syntaxe commune pour les liens à travers différentes sérialisations, et n'impose pas de contexte particulier pour un lien donné ; on s'attend à ce que la sérialisation du lien spécifie ces deux aspects.

Enfin, les liens sont utilisés par des applications de liens. En général, une application définira les types de relation de lien qu'elle utilise, ainsi que les sérialisations dans lesquelles ils peuvent apparaître. Par exemple, l'application « navigation Web » recherche le type de relation de lien « stylesheet » dans la sérialisation de liens HTML (et optionnellement dans le champ d'en-tête Link), tandis que l'application « AtomPub » utilise les relations de lien « edit » et « edit-media » dans la sérialisation Atom.

Dans le cas le plus simple, un type de relation de lien identifie la sémantique du lien. Par exemple, un lien avec le type de relation « copyright » indique que le contexte de lien actuel possède une ressource de copyright à la cible du lien.

Les types de relation de lien peuvent également être utilisés pour indiquer que la ressource cible possède des attributs particuliers ou présente un comportement particulier ; par exemple, un lien « service » implique que la cible du lien peut être utilisée comme partie d'un protocole défini (dans ce cas, une description de service).

Les types de relation ne doivent pas être confondus avec les types de médias [RFC2046] ; ils n'identifient pas le format de la représentation obtenue lors du déréférencement du lien. Ils décrivent uniquement comment le contexte actuel est lié à une autre ressource.

Les types de relation NE DEVRAIENT PAS (SHOULD NOT) inférer de sémantique supplémentaire basée sur la présence ou l'absence d'un autre type de relation de lien ou sur la cardinalité de ses propres occurrences. Une exception est la combinaison des types de relation enregistrés « alternate » et « stylesheet », qui a une signification particulière en HTML pour des raisons historiques.

Il existe deux types de relations : enregistrées et étendues.

2.1.1. Registered Relation Types (Types de relation enregistrés)​

Les types de relation bien définis peuvent être enregistrés comme jetons pour faciliter et/ou encourager leur réutilisation par d'autres applications, en utilisant la procédure de la section 2.1.1.1.

Les noms de types de relation enregistrés DOIVENT (MUST) être conformes à la règle reg-rel-type (voir section 3.3), et DOIVENT (MUST) être comparés caractère par caractère de manière insensible à la casse. Ils DEVRAIENT (SHOULD) être appropriés à la spécificité du type de relation ; c'est-à-dire que si la sémantique est très spécifique à une application particulière, le nom devrait le refléter, afin que des noms plus génériques soient disponibles pour des usages moins spécifiques.

Les types de relation enregistrés NE DOIVENT PAS (MUST NOT) contraindre le type de médias du contexte de lien, et NE DOIVENT PAS (MUST NOT) contraindre les types de médias de représentation disponibles pour la cible du lien. Cependant, ils peuvent spécifier le comportement et les attributs de la ressource cible (par exemple, les méthodes HTTP autorisées, ainsi que les types de médias de requête et de réponse devant être pris en charge).

2.1.2. Extension Relation Types (Types de relation étendus)​

Les applications qui ne souhaitent pas enregistrer un type de relation peuvent utiliser des types de relation étendus, qui sont des URI [RFC3986] identifiant de manière unique le type de relation. Bien que l'URI puisse pointer vers une ressource contenant une définition de la sémantique du type de relation, les clients NE DEVRAIENT PAS (SHOULD NOT) accéder automatiquement à cette ressource pour éviter de surcharger ses serveurs.

L'URI utilisé pour un type de relation étendu DEVRAIT (SHOULD) être sous le contrôle de la personne ou de l'entité qui le définit, ou lui être délégué.

Lors de la comparaison de types de relation étendus, ils DOIVENT (MUST) être comparés caractère par caractère de manière insensible à la casse (après conversion en URI si sérialisés dans un format différent). Par conséquent, les URI entièrement en minuscules DEVRAIENT (SHOULD) être utilisés pour les relations étendues.

Notez que bien que les types de relation étendus doivent être des URI, la sérialisation d'un lien peut spécifier qu'ils sont représentés sous une autre forme, à condition qu'ils puissent être convertis en URI.

2.2. Target Attributes (Attributs de cible)​

Les attributs de cible sont une liste de paires clé/valeur décrivant le lien ou sa cible ; par exemple, des indications sur le type de médias.

Ils peuvent être définis par des types de relation de lien individuels et des sérialisations de liens.

Cette spécification ne tente pas de coordonner les noms des attributs de cible, leur cardinalité ou leur utilisation. Les personnes créant et maintenant des sérialisations DEVRAIENT (SHOULD) coordonner leurs attributs de cible pour éviter les conflits sémantiques ou syntaxiques, et PEUVENT (MAY) définir leurs propres registres d'attributs de cible.

Les noms des attributs de cible DEVRAIENT (SHOULD) être conformes à la règle token, mais NE DEVRAIENT PAS (SHOULD NOT) être limités à l'ASCII ; ils DEVRAIENT (SHOULD) être comparés de manière insensible à la casse.

Le champ d'en-tête d'entité Link fournit un moyen de sérialiser un ou plusieurs liens dans des en-têtes HTTP. Il est sémantiquement équivalent à l'élément <link> de HTML.

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

Chaque link-value véhicule un lien. La cible du lien est indiquée par la URI-Reference entre chevrons (< et >).

Par défaut, le contexte d'un lien est l'URI de requête effective (Effective Request URI) représentant le message dans lequel il apparaît, telle que définie à la section 5.5 de [RFC7230].

Lorsqu'il est présent, le contexte est déterminé par l'IRI cible. Notez que tout IRI DOIT être converti en URI conformément à la section 2 pour être représenté dans le champ d'en-tête Link.

3.3. Relation Type (Type de relation)​

Le type de relation de lien est identifié par la valeur du paramètre « rel », dont la valeur DOIT (MUST) contenir l'un des éléments suivants :

  • un nom de type de relation enregistré (voir section 2.1.1), ou
  • un type de relation étendu (voir section 2.1.2)

Les noms de types de relation enregistrés et les types de relation étendus peuvent être utilisés dans la même valeur de paramètre « rel », séparés par un ou plusieurs espaces.

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

Notez que les types de relation étendus sont encodés en tant qu'URI ; cela signifie que tout caractère réservé doit être encodé en pourcentage conformément à la section 2 de [RFC3986].

3.4. Target Attributes (Attributs de cible)​

Les attributs de cible d'un lien sont représentés sous forme de link-param dans la link-value.

3.4.1. Serialisation-Defined Attributes (Attributs définis par la sérialisation)​

Le paramètre « rel » DOIT (MUST) être présent, mais NE DOIT PAS (MUST NOT) apparaître plusieurs fois ; s'il est absent ou apparaît plusieurs fois, la link-value entière est invalide.

De même, le paramètre « anchor » (s'il est présent) DOIT (MUST) n'apparaître qu'une seule fois ; s'il apparaît plusieurs fois, la link-value entière est invalide.

Les autres attributs de cible courants comprennent :

  • hreflang : indique la langue de la ressource cible. La valeur DOIT (MUST) être conforme à [RFC5646].
  • media : indique le média d'affichage prévu pour la ressource cible. La valeur DOIT (MUST) être conforme à [W3C.REC-css3-mediaqueries-20120619].
  • title : identifiant lisible par l'homme pour étiqueter la ressource cible.
  • title* : version internationalisée du paramètre « title » utilisant l'encodage défini dans [RFC8187].
  • type : fournit une indication sur le type de médias de la ressource cible.

3.4.2. Extension Attributes (Attributs étendus)​

Les autres valeurs de link-param sont des attributs de cible étendus, pouvant être définis et utilisés par des types de relation de lien ou des applications de liens.

La présence ou l'absence d'attributs de cible étendus NE DEVRAIT PAS (SHOULD NOT) invalider la link-value, mais PEUT (MAY) affecter son utilisation dans des applications particulières.

Par exemple :

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

indique que le « chapitre précédent » se trouve à http://example.com/TheBook/chapter2.

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

indique que la ressource racine (« / ») est liée au type de relation étendu personnalisé « http://example.net/foo ».

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

indique que la ressource de copyright pour la ressource identifiée par « foo » se trouve à /terms.

Plusieurs liens peuvent être véhiculés dans un seul champ d'en-tête Link :

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

Ici, les deux liens utilisent le paramètre title internationalisé.

Il est également possible d'utiliser plusieurs champs d'en-tête Link :

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

4. IANA Considerations (Considérations IANA)​

Cette spécification met à jour la définition du champ d'en-tête « Link » dans le registre « Message Headers ».

Nom du champ d'en-tête : Link

Protocole applicable : http

Statut : standard

Auteur/Contrôleur des modifications : IETF

Document de spécification : cette spécification (section 3)

Cette spécification établit le registre « Link Relation Types », disponible à l'adresse https://www.iana.org/assignments/link-relations/.

Les demandes d'enregistrement doivent inclure :

  • Nom de la relation : le nom du type de relation
  • Description : une brève description en anglais de la sémantique du type
  • Référence : la référence au document spécifiant le type de relation de lien

Cette spécification établit le registre « Link Relation Application Data ».

Appendices (Annexes)​

HTML [W3C.REC-html5-20141028] définit l'élément <link> pour véhiculer des liens. Par exemple :

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

La correspondance entre les liens HTML et le modèle de lien défini dans cette spécification est la suivante :

  • Le contexte de lien est l'URI du document contenant l'élément de lien
  • Le type de relation de lien est identifié par la valeur de l'attribut « rel »
  • La cible de lien est identifiée par la valeur de l'attribut « href »
  • Les attributs de cible sont représentés par d'autres attributs (tels que « type », « media », etc.)

Atom [RFC4287] définit un élément de lien pouvant apparaître dans les flux et les entrées. Par exemple :

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

La correspondance entre les liens Atom et le modèle de lien défini dans cette spécification est la suivante :

  • Le contexte de lien est l'URI du flux ou de l'entrée contenant l'élément de lien
  • Le type de relation de lien est identifié par la valeur de l'attribut « rel »
  • La cible de lien est identifiée par la valeur de l'attribut « href »
  • Les attributs de cible sont représentés par d'autres attributs (tels que « type », « hreflang », etc.)

Cette annexe définit les algorithmes d'analyse des champs d'en-tête Link. Ces algorithmes sont normatifs.

Étant donné un ensemble de champs d'en-tête HTTP headers :

  1. Soit links une liste vide
  2. Pour chaque champ field dans headers dont le nom de champ est « Link » (insensible à la casse) :
    • Soit field_value la valeur du champ field
    • Soit field_links le résultat de l'analyse de field_value (en utilisant l'algorithme de la section B.2)
    • Ajouter chaque lien de field_links à links
  3. Retourner links

(Détails de l'algorithme omis — voir le document original)

B.3. Parsing Parameters (Analyse des paramètres)​

(Détails de l'algorithme omis — voir le document original)

B.4. Parsing a Quoted String (Analyse d'une chaîne entre guillemets)​

(Détails de l'algorithme omis — voir le document original)

Appendix C. Changes from RFC 5988 (Modifications par rapport à la RFC 5988)​

Les principales modifications de cette spécification par rapport à la RFC 5988 comprennent :

  • Clarification des définitions du contexte de lien et de la cible de lien
  • Mise à jour des procédures d'enregistrement pour utiliser la RFC 8126
  • Ajout des algorithmes d'analyse (annexe B)
  • Clarification de l'utilisation des types de relation étendus
  • Mise à jour des références à d'autres spécifications
  • Amélioration des exemples et du texte explicatif