16. Extending HTTP (Extension d'HTTP)

HTTP définit un certain nombre de points d'extension génériques qui peuvent être utilisés pour introduire des capacités dans le protocole sans introduire une nouvelle version, y compris les méthodes, les codes d'état, les noms de champs et d'autres points d'extensibilité au sein des champs définis, tels que les schémas d'authentification et les directives de cache (voir les extensions Cache-Control dans la section 5.2.3 de [CACHING]). Parce que la sémantique d'HTTP n'est pas versionnée, ces points d'extension sont persistants; la version du protocole en cours d'utilisation n'affecte pas leur sémantique.

Les extensions indépendantes de la version sont découragées de dépendre ou d'interagir avec la version spécifique du protocole en cours d'utilisation. Lorsque cela est inévitable, une attention particulière doit être accordée à la manière dont l'extension peut interopérer entre les versions.

De plus, des versions spécifiques d'HTTP peuvent avoir leurs propres points d'extensibilité, tels que les codages de transfert dans HTTP/1.1 (section 6.1 de [HTTP/1.1]) et les SETTINGS HTTP/2 ou les types de trames ([HTTP/2]). Ces points d'extension sont spécifiques à la version du protocole dans laquelle ils se produisent.

Les extensions spécifiques à une version ne peuvent pas remplacer ou modifier la sémantique d'un mécanisme ou d'un point d'extension indépendant de la version (comme une méthode ou un champ d'en-tête) sans être explicitement autorisées par cet élément de protocole. Par exemple, la méthode CONNECT (section 9.3.6) le permet.

Ces directives garantissent que le protocole fonctionne correctement et de manière prévisible, même lorsque des parties du chemin implémentent différentes versions d'HTTP.

16.1. Method Extensibility (Extensibilité des méthodes)

16.1.1. Method Registry (Registre des méthodes)

Le "Hypertext Transfer Protocol (HTTP) Method Registry", maintenu par l'IANA à https://www.iana.org/assignments/http-methods, enregistre les noms de méthodes.

Les enregistrements de méthodes HTTP DOIVENT inclure les champs suivants:

• Method Name (Nom de la méthode) (voir section 9)
• Safe ("yes" ou "no", voir section 9.2.1)
• Idempotent ("yes" ou "no", voir section 9.2.2)
• Pointer to specification text (Pointeur vers le texte de spécification)

Les valeurs à ajouter à cet espace de noms nécessitent une revue IETF (voir [RFC8126], section 4.8).

16.1.2. Considerations for New Methods (Considérations pour les nouvelles méthodes)

Les méthodes standardisées sont génériques; c'est-à-dire qu'elles sont potentiellement applicables à n'importe quelle ressource, et non à un type de média, un type de ressource ou une application particulière. En tant que tel, il est préférable que les nouvelles méthodes soient enregistrées dans un document qui n'est pas spécifique à une seule application ou format de données, car les technologies orthogonales méritent une spécification orthogonale.

Étant donné que l'analyse des messages (section 6) doit être indépendante de la sémantique de la méthode (à l'exception des réponses à HEAD), les définitions de nouvelles méthodes ne peuvent pas modifier l'algorithme d'analyse ou interdire la présence de contenu sur le message de requête ou de réponse. Les définitions de nouvelles méthodes peuvent spécifier qu'un contenu de longueur nulle uniquement est autorisé en exigeant un champ d'en-tête Content-Length avec une valeur de "0".

De même, les nouvelles méthodes ne peuvent pas utiliser les formes spéciales host:port et astérisque de cible de requête qui sont autorisées pour CONNECT et OPTIONS, respectivement (section 7.1). Un URI complet sous forme absolue est nécessaire pour l'URI cible, ce qui signifie que soit la cible de requête doit être envoyée sous forme absolue, soit l'URI cible sera reconstruit à partir du contexte de requête de la même manière que pour les autres méthodes.

Une nouvelle définition de méthode doit indiquer si elle est sûre (section 9.2.1), idempotente (section 9.2.2), cacheable (section 9.2.3), quelle sémantique doit être associée au contenu de la requête (le cas échéant), et quels raffinements la méthode apporte à la sémantique du champ d'en-tête ou du code d'état. Si la nouvelle méthode est cacheable, sa définition devrait décrire comment, et dans quelles conditions, un cache peut stocker une réponse et l'utiliser pour satisfaire une requête ultérieure. La nouvelle méthode devrait décrire si elle peut être rendue conditionnelle (section 13.1) et, si oui, comment un serveur répond lorsque la condition est fausse. De même, si la nouvelle méthode peut avoir une certaine utilité pour la sémantique de réponse partielle (section 14.2), elle devrait également le documenter.

Note: Évitez de définir des noms de méthode qui commencent par "M-", car ce préfixe pourrait être mal interprété comme ayant la sémantique qui lui est attribuée par [RFC2774].

16.2. Status Code Extensibility (Extensibilité des codes d'état)

16.2.1. Status Code Registry (Registre des codes d'état)

Le "Hypertext Transfer Protocol (HTTP) Status Code Registry", maintenu par l'IANA à https://www.iana.org/assignments/http-status-codes, enregistre les numéros de codes d'état.

Un enregistrement DOIT inclure les champs suivants:

• Status Code (Code d'état) (3 chiffres)
• Short Description (Description courte)
• Pointer to specification text (Pointeur vers le texte de spécification)

Les valeurs à ajouter à l'espace de noms des codes d'état HTTP nécessitent une revue IETF (voir [RFC8126], section 4.8).

16.2.2. Considerations for New Status Codes (Considérations pour les nouveaux codes d'état)

Lorsqu'il est nécessaire d'exprimer une sémantique pour une réponse qui n'est pas définie par les codes d'état actuels, un nouveau code d'état peut être enregistré. Les codes d'état sont génériques; ils sont potentiellement applicables à n'importe quelle ressource, et non à un type de média, un type de ressource ou une application HTTP particulière. En tant que tel, il est préférable que les nouveaux codes d'état soient enregistrés dans un document qui n'est pas spécifique à une seule application.

Les nouveaux codes d'état doivent appartenir à l'une des catégories définies dans la section 15. Pour permettre aux analyseurs existants de traiter le message de réponse, les nouveaux codes d'état ne peuvent pas interdire le contenu, bien qu'ils puissent exiger un contenu de longueur nulle.

Les propositions de nouveaux codes d'état qui ne sont pas encore largement déployés devraient éviter d'allouer un numéro spécifique pour le code jusqu'à ce qu'il y ait un consensus clair qu'il sera enregistré; au lieu de cela, les premiers projets peuvent utiliser une notation telle que "4NN", ou "3N0" .. "3N9", pour indiquer la classe du ou des codes d'état proposés sans consommer un numéro prématurément.

La définition d'un nouveau code d'état devrait expliquer les conditions de requête qui provoqueraient une réponse contenant ce code d'état (par exemple, des combinaisons de champs d'en-tête de requête et/ou de méthode(s)) ainsi que toute dépendance aux champs d'en-tête de réponse (par exemple, quels champs sont requis, quels champs peuvent modifier la sémantique, et quelle sémantique de champ est davantage affinée lorsqu'elle est utilisée avec le nouveau code d'état).

Par défaut, un code d'état s'applique uniquement à la requête correspondant à la réponse dans laquelle il se produit. Si un code d'état s'applique à une portée d'applicabilité plus large -- par exemple, toutes les requêtes à la ressource en question ou toutes les requêtes à un serveur -- cela DOIT être explicitement spécifié. Ce faisant, il convient de noter que tous les clients n'appliqueront pas de manière cohérente une portée plus large car ils pourraient ne pas comprendre le nouveau code d'état.

La définition d'un nouveau code d'état final devrait spécifier s'il est heuristiquement cacheable ou non. Notez que toute réponse avec un code d'état final peut être mise en cache si elle contient des informations de fraîcheur explicites. Un code d'état défini comme heuristiquement cacheable est autorisé à être mis en cache sans informations de fraîcheur explicites. De même, la définition d'un code d'état peut imposer des contraintes sur le comportement du cache si la directive de cache must-understand est utilisée. Voir [CACHING] pour plus d'informations.

Enfin, la définition d'un nouveau code d'état devrait indiquer si le contenu a une association implicite avec une ressource identifiée (section 6.4.2).

16.3. Field Extensibility (Extensibilité des champs)

Le point d'extensibilité le plus largement utilisé d'HTTP est la définition de nouveaux champs d'en-tête et de trailer.

De nouveaux champs peuvent être définis de telle sorte que, lorsqu'ils sont compris par un destinataire, ils remplacent ou améliorent l'interprétation des champs précédemment définis, définissent des conditions préalables à l'évaluation de la requête, ou affinent la signification des réponses.

Cependant, la définition d'un champ ne garantit pas son déploiement ou sa reconnaissance par les destinataires. La plupart des champs sont conçus avec l'attente qu'un destinataire peut ignorer en toute sécurité (mais transférer en aval) tout champ non reconnu. Dans d'autres cas, la capacité de l'expéditeur à comprendre un champ donné peut être indiquée par sa communication préalable, peut-être dans la version du protocole ou les champs qu'il a envoyés dans les messages précédents, ou son utilisation d'un type de média spécifique. De même, l'inspection directe du support pourrait être possible par le biais d'une requête OPTIONS ou en interagissant avec un URI bien connu défini [RFC8615] si une telle inspection est définie avec le champ en cours d'introduction.

16.3.1. Field Name Registry (Registre des noms de champs)

Le "Hypertext Transfer Protocol (HTTP) Field Name Registry" définit l'espace de noms pour les noms de champs HTTP.

Toute partie peut demander l'enregistrement d'un champ HTTP. Voir la section 16.3.2 pour les considérations à prendre en compte lors de la création d'un nouveau champ HTTP.

Le "Hypertext Transfer Protocol (HTTP) Field Name Registry" se trouve à https://www.iana.org/assignments/http-fields/. Les demandes d'enregistrement peuvent être faites en suivant les instructions qui s'y trouvent ou en envoyant un e-mail à la liste de diffusion "[email protected]".

Les noms de champs sont enregistrés sur les conseils d'un expert désigné (nommé par l'IESG ou son délégué). Les champs avec le statut 'permanent' nécessitent une spécification (Specification Required) ([RFC8126], section 4.6).

Les demandes d'enregistrement consistent en les informations suivantes:

Field name (Nom du champ): Le nom de champ demandé. Il DOIT se conformer à la syntaxe field-name définie dans la section 5.1, et il DEVRAIT être limité aux lettres, chiffres et caractères de trait d'union ('-'), le premier caractère étant une lettre.

Status (Statut): "permanent", "provisional", "deprecated", ou "obsoleted".

Specification document(s) (Document(s) de spécification): Une référence au document qui spécifie le champ, de préférence incluant un URI qui peut être utilisé pour récupérer une copie du document. Une indication des sections pertinentes peut également être incluse mais n'est pas requise.

Et optionnellement:

Comments (Commentaires): Informations supplémentaires, telles que des informations sur les entrées réservées.

L'expert (ou les experts) peut définir des champs supplémentaires à collecter dans le registre, en consultation avec la communauté.

Les noms définis par des standards ont un statut "permanent". D'autres noms peuvent également être enregistrés comme permanents si l'expert (ou les experts) constate(nt) qu'ils sont utilisés et, en consultation avec la communauté, l'expert (ou les experts) les considère(nt) appropriés. Les autres noms DEVRAIENT être enregistrés comme "provisional".

Les entrées provisoires peuvent être supprimées par l'expert (ou les experts) si, en consultation avec la communauté, l'expert (ou les experts) constate(nt) qu'elles ne sont pas utilisées. L'expert (ou les experts) peut changer le statut d'une entrée provisoire en permanent à tout moment.

Notez que les noms peuvent être enregistrés par des tiers (y compris l'expert ou les experts), si l'expert (ou les experts) détermine qu'un nom non enregistré est largement déployé et n'est pas susceptible d'être enregistré en temps opportun.

16.3.2. Considerations for New Fields (Considérations pour les nouveaux champs)

Les champs d'en-tête et de trailer HTTP sont un point d'extension largement utilisé pour le protocole. Bien qu'ils puissent être utilisés de manière ad hoc, les champs destinés à une utilisation plus large doivent être soigneusement documentés pour garantir l'interopérabilité.

En particulier, les auteurs de spécifications définissant de nouveaux champs sont invités à considérer et, le cas échéant, à documenter les aspects suivants:

• Dans quelles conditions le champ peut être utilisé; par exemple, uniquement dans les réponses ou les requêtes, dans tous les messages, uniquement sur les réponses à une méthode de requête particulière, etc.

• Si la sémantique du champ est davantage affinée par son contexte, comme son utilisation avec certaines méthodes de requête ou codes d'état.

• La portée d'applicabilité des informations transmises. Par défaut, les champs s'appliquent uniquement au message auquel ils sont associés, mais certains champs de réponse sont conçus pour s'appliquer à toutes les représentations d'une ressource, à la ressource elle-même ou à une portée encore plus large. Les spécifications qui élargissent la portée d'un champ de réponse devront examiner attentivement des questions telles que la négociation de contenu, la période d'applicabilité et (dans certains cas) les déploiements de serveurs multi-locataires.

• Dans quelles conditions les intermédiaires sont autorisés à insérer, supprimer ou modifier la valeur du champ.

• Si le champ est autorisé dans les trailers; par défaut, il ne le sera pas (voir section 6.5.1).

• S'il est approprié ou même requis de lister le nom du champ dans le champ d'en-tête Connection (c'est-à-dire, si le champ est hop-by-hop; voir section 7.6.1).

• Si le champ introduit des considérations de sécurité supplémentaires, telles que la divulgation de données liées à la vie privée.

Les champs d'en-tête de requête qui souhaitent permettre un comportement différent de celui par défaut ont des considérations supplémentaires à documenter:

• S'il est approprié de lister le nom du champ dans le champ d'en-tête de réponse Vary (par exemple, lorsque l'algorithme de sélection de contenu du serveur d'origine utilise le champ d'en-tête de requête; voir section 12.5.5).

• Si le champ est destiné à être stocké par un serveur lors de la réception dans une requête PUT (voir section 9.3.4).

• Si le champ devrait être supprimé lors de la redirection automatique d'une requête en raison de préoccupations de sécurité (voir section 15.4).

16.3.2.1. Considerations for New Field Names (Considérations pour les nouveaux noms de champs)

Les auteurs de spécifications définissant de nouveaux champs sont invités à choisir un nom de champ court mais descriptif. Les noms courts évitent la transmission de données inutiles; les noms descriptifs évitent la confusion et "l'occupation" de noms qui pourraient avoir des utilisations plus larges.

À cette fin, les champs à utilisation limitée (tels qu'un en-tête confiné à une seule application ou cas d'utilisation) sont encouragés à utiliser un nom qui inclut cette utilisation (ou une abréviation) comme préfixe; par exemple, si l'application Foo a besoin d'un champ Description, elle pourrait utiliser "Foo-Desc"; "Description" est trop générique, et "Foo-Description" est inutilement long.

Bien que la syntaxe field-name soit définie pour permettre n'importe quel caractère de jeton, en pratique, certaines implémentations imposent des limites aux caractères qu'elles acceptent dans les noms de champs. Pour être interopérable, les nouveaux noms de champs DEVRAIENT se limiter aux caractères alphanumériques, "-" et ".", et DEVRAIENT commencer par une lettre. Par exemple, le caractère de soulignement ("_") peut être problématique lorsqu'il est transmis via des interfaces de passerelle non-HTTP (voir section 17.10).

Les noms de champs ne devraient pas être préfixés par "X-"; voir [BCP178] pour plus d'informations.

D'autres préfixes sont parfois utilisés dans les noms de champs HTTP; par exemple, "Accept-" est utilisé dans de nombreux en-têtes de négociation de contenu, et "Content-" est utilisé comme expliqué dans la section 6.4. Ces préfixes ne sont qu'une aide pour reconnaître le but d'un champ et ne déclenchent pas de traitement automatique.

16.3.2.2. Considerations for New Field Values (Considérations pour les nouvelles valeurs de champs)

Une tâche majeure dans la définition d'un nouveau champ HTTP est la spécification de la syntaxe de la valeur du champ: ce que les expéditeurs doivent générer, et comment les destinataires doivent inférer la sémantique de ce qui est reçu.

Les auteurs sont encouragés (mais pas obligés) à utiliser soit les règles ABNF de cette spécification, soit celles de [RFC8941] pour définir la syntaxe des nouvelles valeurs de champs.

Les auteurs sont invités à examiner attentivement comment la combinaison de plusieurs lignes de champs les affectera (voir section 5.3). Parce que les expéditeurs pourraient envoyer par erreur plusieurs valeurs, et que les intermédiaires et les bibliothèques HTTP peuvent effectuer une combinaison automatiquement, cela s'applique à toutes les valeurs de champs -- même lorsqu'une seule valeur est prévue.

Par conséquent, les auteurs sont invités à délimiter ou encoder les valeurs qui contiennent des virgules (par exemple, avec la règle quoted-string de la section 5.6.4, le type de données String de [RFC8941], ou un encodage spécifique au champ). Cela garantit que les virgules dans les données de champ ne sont pas confondues avec les virgules qui délimitent une valeur de liste.

Par exemple, la valeur du champ Content-Type n'autorise les virgules qu'à l'intérieur de chaînes entre guillemets, ce qui peut être analysé de manière fiable même lorsque plusieurs valeurs sont présentes. La valeur du champ Location fournit un contre-exemple qui ne devrait pas être émulé: parce que les URI peuvent inclure des virgules, il n'est pas possible de distinguer de manière fiable entre une seule valeur qui inclut une virgule et deux valeurs.

Les auteurs de champs avec des valeurs singleton (voir section 5.5) sont en outre invités à documenter comment un message qui contient plusieurs membres doit être traité (une valeur par défaut raisonnable serait d'ignorer le champ, mais ce n'est peut-être pas toujours le bon choix).

16.4. Authentication Scheme Extensibility (Extensibilité des schémas d'authentification)

16.4.1. Authentication Scheme Registry (Registre des schémas d'authentification)

Le "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" définit l'espace de noms pour les schémas d'authentification dans les défis et les credentials. Il est maintenu à https://www.iana.org/assignments/http-authschemes.

Les enregistrements DOIVENT inclure les champs suivants:

• Authentication Scheme Name (Nom du schéma d'authentification)
• Pointer to specification text (Pointeur vers le texte de spécification)
• Notes (Notes) (optionnel)

Les valeurs à ajouter à cet espace de noms nécessitent une revue IETF (voir [RFC8126], section 4.8).

16.4.2. Considerations for New Authentication Schemes (Considérations pour les nouveaux schémas d'authentification)

Il existe certains aspects du cadre d'authentification HTTP qui imposent des contraintes sur la façon dont les nouveaux schémas d'authentification peuvent fonctionner:

• L'authentification HTTP est présumée être sans état: toutes les informations nécessaires pour authentifier une requête DOIVENT être fournies dans la requête, plutôt que de dépendre du serveur qui se souvient des requêtes antérieures. L'authentification basée sur, ou liée à, la connexion sous-jacente est en dehors du champ d'application de cette spécification et intrinsèquement défectueuse à moins que des mesures ne soient prises pour garantir que la connexion ne peut être utilisée par aucune partie autre que l'utilisateur authentifié (voir section 3.3).

• Le paramètre d'authentification "realm" est réservé pour définir les espaces de protection comme décrit dans la section 11.5. Les nouveaux schémas NE DOIVENT PAS l'utiliser d'une manière incompatible avec cette définition.

• La notation "token68" a été introduite pour la compatibilité avec les schémas d'authentification existants et ne peut être utilisée qu'une seule fois par défi ou credential. Ainsi, les nouveaux schémas devraient plutôt utiliser la syntaxe auth-param, car sinon les extensions futures seront impossibles.

• L'analyse des défis et des credentials est définie par cette spécification et ne peut pas être modifiée par de nouveaux schémas d'authentification. Lorsque la syntaxe auth-param est utilisée, tous les paramètres devraient prendre en charge à la fois la syntaxe de jeton et de chaîne entre guillemets, et les contraintes syntaxiques devraient être définies sur la valeur du champ après l'analyse (c'est-à-dire, le traitement de la chaîne entre guillemets). Cela est nécessaire pour que les destinataires puissent utiliser un analyseur générique qui s'applique à tous les schémas d'authentification.

  Note: Le fait que la syntaxe de valeur pour le paramètre "realm" soit limitée à une chaîne entre guillemets était un mauvais choix de conception à ne pas répéter pour les nouveaux paramètres.

• La définition de nouveaux schémas devrait définir le traitement des paramètres d'extension inconnus. En général, une règle "must-ignore" est préférable à une règle "must-understand", car sinon il sera difficile d'introduire de nouveaux paramètres en présence de destinataires hérités. En outre, il est bon de décrire la politique de définition de nouveaux paramètres (par exemple, "mettre à jour la spécification" ou "utiliser ce registre").

• Les schémas d'authentification doivent documenter s'ils sont utilisables dans l'authentification du serveur d'origine (c'est-à-dire, en utilisant WWW-Authenticate) et/ou l'authentification proxy (c'est-à-dire, en utilisant Proxy-Authenticate).

• Les credentials transportés dans un champ d'en-tête Authorization sont spécifiques à l'agent utilisateur et, par conséquent, ont le même effet sur les caches HTTP que la directive de réponse de cache "private" ([CACHING], section 5.2.2.7) dans la portée de la requête dans laquelle ils apparaissent.

  Par conséquent, les nouveaux schémas d'authentification qui choisissent de ne pas transporter de credentials dans le champ d'en-tête Authorization (par exemple, en utilisant un champ d'en-tête nouvellement défini) devront explicitement interdire la mise en cache, en imposant l'utilisation de directives de réponse de cache (par exemple, "private").

• Les schémas utilisant Authentication-Info, Proxy-Authentication-Info ou tout autre champ d'en-tête de réponse lié à l'authentification doivent considérer et documenter les considérations de sécurité associées (voir section 17.16.4).

16.5. Range Unit Extensibility (Extensibilité des unités de plage)

16.5.1. Range Unit Registry (Registre des unités de plage)

Le "HTTP Range Unit Registry" définit l'espace de noms pour les noms d'unités de plage et fait référence à leurs spécifications correspondantes. Il est maintenu à https://www.iana.org/assignments/http-parameters.

L'enregistrement d'une unité de plage HTTP DOIT inclure les champs suivants:

• Name (Nom)
• Description
• Pointer to specification text (Pointeur vers le texte de spécification)

Les valeurs à ajouter à cet espace de noms nécessitent une revue IETF (voir [RFC8126], section 4.8).

16.5.2. Considerations for New Range Units (Considérations pour les nouvelles unités de plage)

D'autres unités de plage, telles que les limites spécifiques au format comme les pages, les sections, les enregistrements, les lignes ou le temps, sont potentiellement utilisables dans HTTP à des fins spécifiques à l'application, mais ne sont pas couramment utilisées en pratique. Les implémenteurs d'unités de plage alternatives devraient considérer comment elles fonctionneraient avec les codages de contenu et les intermédiaires à usage général.

16.6. Content Coding Extensibility (Extensibilité du codage de contenu)

16.6.1. Content Coding Registry (Registre du codage de contenu)

Le "HTTP Content Coding Registry", maintenu par l'IANA à https://www.iana.org/assignments/http-parameters/, enregistre les noms de content-coding.

Les enregistrements de codage de contenu DOIVENT inclure les champs suivants:

• Name (Nom)
• Description
• Pointer to specification text (Pointeur vers le texte de spécification)

Les noms des codages de contenu NE DOIVENT PAS chevaucher les noms des codages de transfert (selon le "HTTP Transfer Coding Registry" situé à https://www.iana.org/assignments/http-parameters/) à moins que la transformation d'encodage ne soit identique (comme c'est le cas pour les codages de compression définis dans la section 8.4.1).

Les valeurs à ajouter à cet espace de noms nécessitent une revue IETF (voir section 4.8 de [RFC8126]) et DOIVENT se conformer à l'objectif du codage de contenu défini dans la section 8.4.1.

16.6.2. Considerations for New Content Codings (Considérations pour les nouveaux codages de contenu)

Les nouveaux codages de contenu devraient être auto-descriptifs dans la mesure du possible, avec des paramètres optionnels découvrables dans le format de codage lui-même, plutôt que de s'appuyer sur des métadonnées externes qui pourraient être perdues pendant le transit.

16.7. Upgrade Token Registry (Registre des jetons de mise à niveau)

Le "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" définit l'espace de noms pour les jetons protocol-name utilisés pour identifier les protocoles dans le champ d'en-tête Upgrade. Le registre est maintenu à https://www.iana.org/assignments/http-upgrade-tokens.

Chaque nom de protocole enregistré est associé à des informations de contact et à un ensemble optionnel de spécifications qui détaillent comment la connexion sera traitée après sa mise à niveau.

Les enregistrements se font sur une base "Premier arrivé, premier servi" (voir section 4.4 de [RFC8126]) et sont soumis aux règles suivantes:

1. Un jeton protocol-name, une fois enregistré, reste enregistré pour toujours.

2. Un jeton protocol-name est insensible à la casse et enregistré avec la casse préférée à générer par les expéditeurs.

3. L'enregistrement DOIT nommer une partie responsable pour l'enregistrement.

4. L'enregistrement DOIT nommer un point de contact.

5. L'enregistrement PEUT nommer un ensemble de spécifications associées à ce jeton. Ces spécifications n'ont pas besoin d'être accessibles au public.

6. L'enregistrement DEVRAIT nommer un ensemble de jetons "protocol-version" attendus associés à ce jeton au moment de l'enregistrement.

7. La partie responsable PEUT modifier l'enregistrement à tout moment. L'IANA conservera un enregistrement de toutes ces modifications et les mettra à disposition sur demande.

8. L'IESG PEUT réattribuer la responsabilité d'un jeton de protocole. Cela ne sera normalement utilisé que dans le cas où une partie responsable ne peut être contactée.