Résumé

  • Un identifiant Content-Format de CoAP désigne un Content Type précis et, le cas échéant, un Content Coding ; le nombre n’a pas de sens autonome.
  • RFC 9876 resserre la procédure « premier arrivé, premier servi » et soumet la plupart des plages à une liste de contrôles confiée à un expert désigné.
  • Les enregistrements temporaires disposent désormais d’un cycle de vie explicite ; 64998 et 64999 sont réservés à la documentation, tandis que 65000-65535 restent expérimentaux et non opérationnels.
  • L’objectif est d’empêcher des paramètres invalides, des codages inconnus ou des doublons logiques de devenir des faits de protocole compacts mais trompeurs.

Dans CoAP, un identifiant Content-Format représente l’association d’un type de média et, le cas échéant, d’un codage de contenu. Le registre porte donc les informations nécessaires pour interpréter cet entier. Si la combinaison enregistrée est invalide, dupliquée ou ambiguë, l’identifiant ne renvoie plus à un sens protocolaire unique.

RFC 9876 remplace les procédures d’enregistrement de la section 12.3 de RFC 7252. Le problème n’était pas administratif. Les anciennes règles n’exigeaient pas explicitement de vérifier la validité sémantique de l’association entre Content-Type et Content Coding, alors que cette vérification peut dépendre de plusieurs registres et spécifications. IANA peut constater qu’une demande est complète ; déterminer si elle décrit un format valide, distinct et interprétable relève d’une expertise technique différente.

La nouvelle table d’allocation rend visibles la rareté des numéros et le niveau de contrôle. La plage 0-255, qui tient sur un octet, exige une expertise. La plage 256-9999 associe examen IETF ou approbation IESG et expertise. Les plages 10000-19999 et 33000-64997 exigent elles aussi une expertise. Seule 20000-32999 conserve une voie « premier arrivé, premier servi », sous des conditions strictes : type de média enregistré ou approuvé, aucun paramètre, aucun Content Coding et aucune utilisation antérieure de ce type de média dans le registre CoAP. Hors de ce cadre, la demande doit rejoindre une plage expertisée.

La liste de contrôle de l’expert porte sur le sens. Elle vérifie que la paire Content-Type et Content Coding n’existe pas déjà, que le type de média possède un fondement officiel, que les noms et valeurs de paramètres sont autorisés, que la chaîne respecte le format préféré et que tout Content Coding figure dans le registre HTTP correspondant. Cette méthode détecte aussi les doublons cachés : deux chaînes différentes peuvent décrire la même entrée logique lorsqu’une valeur par défaut ou le codage « identity » est écrit explicitement.

RFC 9876 organise également le provisoire. Des enregistrements temporaires sont possibles entre 0 et 64997, notamment pour une allocation anticipée ou un type de média provisoire. Ils deviennent permanents lorsque la procédure requise aboutit et que le type de média obtient son statut définitif. Si le processus admissible échoue ou si le type provisoire est abandonné, IANA peut supprimer l’entrée et rendre l’identifiant à l’état « Unassigned ». Le texte conserve toutefois l’exception propre aux plages élevées dont la procédure ne dépend pas de l’achèvement d’un processus de normalisation.

Les autres frontières cessent d’être implicites. Une colonne « Media Type » relie l’entrée compacte à l’enregistrement de base. Les numéros 64998 et 64999 servent aux exemples documentaires, pas à l’exploitation. La plage 65000-65535 est expérimentale et ne doit pas être employée dans des déploiements opérationnels. Le registre distingue ainsi le sens durable, la coordination temporaire, l’exemple et l’expérience.

Sources