Résumé

  • Updates relie l’extension pour le thé du RFC 7168 au RFC 2324 ; le statut la qualifie de soumission indépendante et informative, hors du Standards Track.
  • Ce lien documentaire ne prouve ni consensus, ni norme Internet, ni mise en œuvre dans un appareil.

Trois indications à distinguer

La première page du RFC 7168 affiche Updates: 2324, un titre annonçant une extension HTCPCP pour le thé, puis un bloc de statut. Le champ relie le texte à un document antérieur. Le statut précise que le RFC 7168 est une Independent Submission de catégorie Informational, qu’il n’appartient pas au Standards Track et que le RFC Editor ne se prononce pas sur sa valeur pour l’implémentation ou le déploiement.

Ces données ne se contredisent pas. Updates décrit une relation entre documents. Independent Submission désigne le flux de publication. Informational et son texte type donnent la position du document. Le numéro RFC confirme sa publication dans la série, mais n’indique pas seul le parcours d’examen ni une autorité normative.

Le corps imite le langage d’une spécification : il définit des requêtes BREW, le type de média message/teapot, des URI de thé et des réponses. Cette forme ne remplace pas le statut imprimé au début.

Ce que l’extension décrit

Le RFC 2324 fournissait en 1998 le vocabulaire HTCPCP pour le café. Le RFC 7168 l’adapte au thé. Un appareil peut afficher des variétés dans Alternates afin que le client choisisse une URI précise. Avec message/teapot, une première requête vers / présente les choix sans démarrer l’infusion. Avec message/coffeepot, le comportement de base peut s’appliquer et préparer du café. Le texte décrit aussi une requête d’arrêt à la force souhaitée.

L’enjeu de conception est de découvrir les options avant de déclencher une action. Mais le RFC ne documente ni appareil réel, ni essai d’interopérabilité, ni service en réseau. Il atteste ce qui a été spécifié, pas ce qui a fonctionné.

Le RFC 2324 disait déjà qu’il ne spécifiait aucune norme Internet. Le champ Updates du RFC 7168 ne change pas ce statut et ne transforme pas l’extension en norme. Il signale une filiation documentaire, pas une adoption.

Une série, plusieurs flux

Le RFC 5741 explique pourquoi les en-têtes rendent visibles l’origine et le statut des documents. La série RFC accueille plusieurs flux. La formule Independent Submission indique que le RFC Editor a choisi de publier le document à sa discrétion et ne se prononce pas sur sa valeur pour l’implémentation ou le déploiement. Le RFC 7168 reprend cette formule.

Il faut séparer trois questions : le numéro confirme la publication ; le flux et la catégorie donnent le parcours et le statut ; Updates précise quel document est prolongé. RFC 2324 vers RFC 7168 décrit une continuité de contenu, sans établir consensus ou usage.

Les deux textes portent la date du 1er avril, en 1998 et 2014, et leur humour est manifeste. Les métadonnées aident à ne pas confondre une contribution ludique publiée dans la série avec une norme attendue des opérateurs.

La Note 65 de Heng Lu, Running-Code Primacy, fournit un prisme éditorial : la prose d’une spécification ne prouve pas ce qui fonctionne. Des affirmations sur des appareils à thé connectés demandent des preuves indépendantes.

Sources