Résumé

  • La révision 14 propose des projections CoAP Observe fondées sur des seuils, pas, bandes, fronts et périodes ; elle ne transforme pas l’absence de notification en preuve de stabilité physique.
  • Une conclusion fiable exige des reçus distincts pour le support effectif, l’échantillonnage, l’évaluation, le déclenchement, l’envoi, le passage des proxies, l’accusé de réception et l’action finale.

Le seuil avait été franchi une seule fois

Une machine chauffe. Le client demande c.gt=80. À la première traversée du seuil, le serveur envoie une notification. La température monte ensuite jusqu’à 95, mais aucun autre message ne vient. Le tableau de bord peut présenter cette minute comme calme ; la sémantique proposée raconte autre chose. Sans bande ou autre condition, c.gt signale la traversée par rapport à la dernière valeur rapportée. Il n’est pas un flux d’alarmes répétées tant que la valeur demeure au-dessus.

Publié le 14 septembre 2026, draft-ietf-core-conditional-attributes-14 expire le 18 mars 2027. Le Datatracker le décrit comme un Internet-Draft actif du groupe CoRE, destiné au Standards Track, mais encore marqué « Revised I-D Needed » après une question de dernier appel. Ce n’est ni un RFC, ni une homologation, ni la preuve qu’un produit déterminé applique ces règles.

Le projet complète CoAP Observe par des paramètres placés dans la requête URI. Le serveur maintient alors un état projeté distinct de l’état demandé sans condition. Cette projection réduit les transferts inutiles. Elle modifie aussi la question de preuve : le client ne voit plus tous les états que le serveur aurait pu représenter, mais le résultat d’une sélection.

Les conditions ne décrivent pas la même histoire

c.gt et c.lt observent des traversées de limite. c.st compare l’échantillon à la dernière valeur rapportée. c.band transforme les deux limites en zone de notification intérieure ou extérieure selon leur ordre. c.edge ne retient qu’un sens de transition booléenne.

La notion de « dernière valeur rapportée » est décisive. Si plusieurs états surviennent pendant c.pmin, le serveur peut garder le dernier échantillon avant le prochain envoi. Deux notifications successives peuvent donc différer de bien plus que le pas demandé. Plusieurs conditions satisfaites au même instant ne créent qu’une notification, sans hiérarchie de priorité, puis l’état et l’heure de référence sont mis à jour.

Le nombre de paquets n’est ainsi ni le nombre de mesures, ni le nombre de franchissements, ni le nombre d’événements physiques. La projection est un objet de protocole avec sa propre mémoire.

Un succès peut contenir une condition ignorée

Le marqueur if="core.conditional" annonce une capacité générale et reste facultatif. Il ne révèle pas quels paramètres sont pris en charge. Une ressource peut l’annoncer sans supporter chaque condition ; elle peut aussi supporter les conditions sans publier le marqueur.

Pour un paramètre syntaxiquement valide mais inconnu, le serveur doit poursuivre l’observation comme si ce paramètre n’avait aucun effet. Il ne doit pas rejeter la requête pour cette seule raison. Une réponse 2.05 Content munie d’une option Observe prouve donc une inscription, pas nécessairement la totalité du filtre demandé.

Une valeur invalide suit une autre branche : mauvais type, période non positive ou ordre temporel impossible appellent 4.00 Bad Request. Et un serveur qui refuse une inscription aux périodes dangereusement courtes peut traiter le GET normalement sans option Observe. L’option absente est alors le reçu de non-inscription.

Évaluer, notifier et livrer

c.pmin impose une distance minimale entre notifications. Il ne pilote pas forcément les mesures. Une condition peut être vraie alors qu’aucun paquet ne peut encore partir. c.pmax borne l’intervalle souhaité entre notifications, même sans changement, mais le texte refuse d’en faire un contrat temps réel. Lorsque minimum et maximum sont égaux, l’exécution demeure au mieux possible.

c.epmin et c.epmax agissent sur l’évaluation des conditions. Ils ne rendent pas le capteur continu. Un pic bref peut naître et disparaître entre deux évaluations. Un serveur conforme à sa cadence peut donc ne jamais posséder l’échantillon qui aurait déclenché l’alerte.

Une exploitation sérieuse conserve au moins l’heure du phénomène quand elle existe, l’heure d’échantillonnage, l’heure d’évaluation, l’heure où la condition devient notifiable, l’heure d’émission et celle de réception. Les réduire à l’horodatage d’un message masque la cause du silence.

Le proxy possède une part du résultat

Observe conserve les propriétés REST de cache et de proxy. La révision 14 avertit qu’un intermédiaire peut empêcher le client de recevoir des mises à jour périodiques lorsque la représentation reste identique, notamment avec c.pmax. Fixer Max-Age au plus à c.pmax atténue ce risque ; cela ne crée pas un reçu de bout en bout.

Avec c.con=true, la notification doit être confirmable. L’accusé de réception ferme une incertitude sur cet échange CoAP. Il ne démontre ni l’exhaustivité des échantillons, ni le traitement par l’application, ni l’activation d’une vanne, d’un ventilateur ou d’une procédure humaine.

Token, numéro Observe, transport fiable et OSCORE ont chacun un périmètre utile. Aucun ne certifie la continuité du monde physique.

Même l’annulation est liée à la projection

Pour annuler explicitement, le client doit renvoyer l’URI conditionnelle originale. Deux seuils sur la même ressource définissent deux projections. Une interface qui supprime un widget sans reproduire l’URI peut laisser vivre l’observateur qu’elle croit avoir détruit.

Le reçu d’annulation devrait donc lier point d’accès, Token, URI complète, option Observe et réponse. Sans ce lien, les coûts d’énergie et les anciennes alarmes demeurent possibles derrière une interface vide.

La chaîne minimale de preuve

Il faut d’abord savoir quelle ressource supportait quoi, puis prouver l’inscription de la projection exacte. Viennent ensuite le sous-ensemble de paramètres réellement appliqué, la cadence et la résolution des mesures, le calcul du seuil ou de la bande, les contraintes d’envoi, la traversée du proxy, la réception par le client, enfin l’action et son effet.

Le silence devient informatif seulement si chacune de ces attentes possède une borne. Sinon, il peut signifier stabilité, absence d’échantillon, condition ignorée, évaluation trop rare, message regroupé, cache, perte, observation expirée ou application inactive.

Les sources gelées ne permettent pas de nommer un déploiement, un accident, un taux de pertes ou une conformité industrielle. Le document sur l’amplification cité par le projet est lui-même un Internet-Draft IRTF expiré. Il éclaire une menace ; il ne prouve aucune attaque.

Dans la lecture proposée par Lu Heng, la projection est un registre local de ce que le serveur a choisi d’observer et d’émettre. Elle coordonne. Elle ne reçoit pas, par sa simple existence, l’autorité du système physique ni celle de l’application qui doit agir.

Sources