Résumé

  • Mark Nottingham a proposé « HTTP/3 » pour rendre visible la mise en correspondance des sémantiques HTTP sur QUIC, distincte du rôle de transport de QUIC.
  • Sa proposition associait le nom à une répartition des responsabilités : après publication, la maintenance de HTTP/3 et de QPACK devait passer au groupe de travail HTTP. Les chartes de l’IETF documentent ensuite cette répartition.
  • Cette frontière clarifie qui décide et maintient quoi. Elle ne garantit ni la compatibilité du code ni le déploiement, et elle ne transforme pas une intervention de Nottingham en décision personnelle.

À la fin de 2018, le mot « QUIC » désignait deux choses que les interlocuteurs ne distinguaient pas toujours : un protocole de transport et la manière de faire fonctionner HTTP au-dessus de ce transport. La confusion pouvait conduire les lecteurs à prendre la couche de transport et la version HTTP comme un seul livrable. Ce n’était pas qu’un problème de communication : la question était aussi de savoir quel groupe devait décider de l’avenir de chaque partie.

Le 28 octobre, Mark Nottingham a écrit à la liste du groupe QUIC. Il a suggéré d’appeler le document HTTP « HTTP/3 » et d’employer h3 comme identifiant ALPN final. À ses yeux, ce nom indiquait que le document décrivait une nouvelle mise en correspondance des sémantiques HTTP avec un protocole sur le fil, comme HTTP/2, et non une composante du transport QUIC. Son message expose directement ce raisonnement.

Il ne s’est pas arrêté au titre. Une fois la spécification publiée, proposait-il, la maintenance de HTTP/3 ainsi que de QPACK devrait être confiée au groupe HTTP. La différence est importante. Un groupe peut élaborer une spécification parce qu’elle dépend de son travail sur le transport; cela ne signifie pas qu’il doive garder la responsabilité de toutes les décisions futures concernant le protocole applicatif. Le nom et la maintenance étaient deux questions liées, mais distinctes.

La discussion a séparé l’appui du pouvoir de décision

À l’IETF 103, le groupe QUIC a débattu de la dénomination. Les minutes consignent plusieurs lectures possibles : HTTP/3 pouvait sembler succéder à HTTP/2, tandis que d’autres craignaient qu’un nouveau nom suggère une rupture. Nottingham a rappelé que HTTP/2 n’avait ni déprécié ni remplacé HTTP/1.1. Selon lui, la distinction décisive portait sur les sémantiques d’un côté et le protocole sur le fil de l’autre.

Les minutes ne décrivent pas un scrutin formel. Elles notent un « hum » informel d’environ 70 contre 30 en faveur du changement de nom, puis un appui presque unanime pour laisser HTTPbis trancher. Ce second résultat éclaire mieux la frontière. Le document avait été élaboré dans le travail QUIC, mais le groupe HTTP devait décider du nom d’un protocole HTTP. Nottingham a explicitement soutenu que la dénomination de HTTP devait rester dans la communauté HTTP.

Son message d’octobre portait une note « Chair hat ». Il demandait une discussion courte à Bangkok et voulait éviter une interminable recherche de noms. Les développeurs et les utilisateurs avaient besoin d’un terme clair, expliquait-il, mais le groupe avait aussi du travail technique à terminer. Cette position décrit une fonction de présidence : cadrer le sujet et limiter le temps qu’il consomme. Elle ne donne pas à un président le droit de remplacer le consensus.

Le nom devient précis lorsque les couches restent distinctes

La spécification publiée confirme cette lecture. RFC 9114 définit HTTP/3 comme une mise en correspondance des sémantiques HTTP sur QUIC. RFC 9110 décrit ces sémantiques; RFC 9000 définit le transport QUIC. HTTP/3 s’appuie sur la livraison fiable et ordonnée de chaque flux QUIC et sur les propriétés de sécurité de QUIC, tout en conservant la signification applicative des messages HTTP. Le nom identifie la mise en correspondance, sans fusionner les couches.

Le jeton ALPN h3 n’est pas un autre nom public pour la même chose. C’est un identifiant utilisé sur le fil pendant la négociation de protocole. Le nom « HTTP/3 » permet de classer la spécification et le travail; h3 sert à la négociation technique. Nottingham écrivait que le nouveau nom ne serait formalisé ni utilisé sur le fil avant la publication. La communauté gardait ainsi une possibilité de revenir sur la proposition avant que l’identifiant ne conditionne la compatibilité.

Le transfert de maintenance a lui aussi été inscrit dans des documents de gouvernance. La charte HTTPbis de 2018 prévoyait que, lorsque le groupe QUIC aurait publié HTTP/3, HTTPbis maintiendrait le protocole et développerait ses extensions au besoin, dont QPACK. La charte HTTP actuelle range HTTP/3 et QPACK parmi les spécifications centrales de HTTP. Celle du groupe QUIC indique que QUIC a créé la mise en correspondance et QPACK, mais que ces spécifications sont désormais maintenues dans HTTP.

La frontière n’est pas une cloison étanche. Le groupe QUIC répertorie encore un travail sur les événements qlog de HTTP/3, à l’intersection de l’observabilité du transport et de l’application. La distinction est plus utile si elle porte sur la responsabilité principale : maintenir la mise en correspondance HTTP et traiter les questions dont les mécanismes relèvent de QUIC. Les systèmes en fonctionnement obligent les deux communautés à continuer de se parler.

La publication ne remplace pas l’opérateur

Le nom HTTP/3 n’active pas le protocole chez un client, ne garantit pas que le serveur l’acceptera et ne prouve pas qu’un chemin réseau le transportera sans incident. La publication d’une RFC et l’enregistrement d’un identifiant ALPN fournissent une référence commune. Les implémentations doivent encore négocier, interopérer, prévoir des replis et décider de leur déploiement. Un nom réduit les erreurs de catégorie; il ne mesure ni l’adoption ni les performances.

La proposition a donc une portée limitée mais utile. Une spécification commune peut préciser la signification des messages HTTP et leur mise en correspondance sur QUIC. La spécification de transport peut définir la livraison, le contrôle de congestion et la sécurité du transport. Les chartes peuvent désigner qui maintient chaque texte. Les opérateurs et les implémenteurs doivent ensuite décider s’ils utilisent ces spécifications et de quelle manière. Chaque document répond à une question différente.

La contribution de Nottingham n’est pas d’avoir, seul, baptisé HTTP/3 ou transféré sa maintenance. Il a relié un nom public à une responsabilité future, puis soutenu que le groupe HTTP devait décider de ce nom. Les minutes et les chartes montrent comment le processus a traité ces questions. Pour un travail de normalisation, la question utile est alors la suivante : les lecteurs peuvent-ils voir ce qui est partagé, ce qui change, qui maintient chaque partie et ce que les implémentations doivent encore démontrer ?

Sources