Resumen
- La revisión 14 define filtros y controles temporales para proyectar solo parte de los estados observados; la falta de mensajes no certifica que el recurso permaneciera dentro de límites.
- La evidencia debe separar soporte efectivo, muestreo, evaluación, disparo, calendario de notificación, entrega a través de proxies, acuse y resultado de la aplicación.
El latido idéntico que no cruzó la caché
Un cliente pidió c.pmax para recibir una representación al menos cada cierto intervalo, incluso cuando el valor permaneciera igual. El servidor generó actualizaciones. El proxy, al ver la misma representación, no entregó todas. Para el servidor hubo actividad; para el cliente hubo silencio.
La revisión 14 reconoce expresamente esta interferencia y recomienda que Max-Age no supere c.pmax. Es una mitigación útil, no una garantía de extremo a extremo. Un registro de envío en el servidor y un hueco en el cliente pueden ser simultáneamente correctos.
draft-ietf-core-conditional-attributes-14 se publicó el 14 de septiembre de 2026 y vence el 18 de marzo de 2027. Es un Internet-Draft activo del grupo CoRE, con intención de Standards Track, todavía marcado como necesitado de revisión tras una cuestión de último llamado. No es un RFC ni un informe de despliegue.
Su propuesta permite que una solicitud Observe incluya condiciones como umbrales, pasos, bandas, flancos y periodos. El servidor mantiene una proyección del estado separada de la representación sin condiciones. Eso reduce tráfico, pero también hace que cada ausencia dependa de las reglas de proyección.
Cruzar no es permanecer
c.gt y c.lt notifican cruces con respecto al último valor comunicado. Tras cruzar c.gt, un valor puede seguir subiendo sin nuevos avisos producidos por esa condición. Cuando vuelve al otro lado puede habilitar un cruce futuro. Por eso un único aviso no describe cuánto duró la excursión ni hasta dónde llegó.
c.st mide el cambio frente al último estado comunicado. Si c.pmin impide enviar durante un intervalo, el servidor puede conservar el último muestreo y descartar la trayectoria intermedia. La diferencia visible entre dos mensajes puede superar el paso solicitado.
c.band modifica el significado de los límites y puede seleccionar valores dentro o fuera de la banda según su orden. c.edge selecciona un sentido de transición booleana. Si varias condiciones se cumplen juntas, no hay niveles de prioridad: se emite una sola notificación y se actualizan el valor y el tiempo de referencia.
Por tanto, una notificación no equivale a un evento físico, y cero notificaciones no equivale a cero cambios.
El servidor puede ignorar una condición válida
El atributo if="core.conditional" anuncia una interfaz general, pero no lista los parámetros individuales. Además es opcional. Un recurso puede anunciarlo y no implementar una condición concreta, o implementar condiciones sin anunciarlo.
Si recibe un parámetro válido que no soporta, el servidor debe tratarlo como carente de efecto y continuar con el resto de la solicitud. No debe rechazar la observación solo por esa falta de soporte. Así, 2.05 Content más la opción Observe demuestran que existe una relación, no que todos los filtros estén activos.
Los valores inválidos sí se rechazan con 4.00 Bad Request: tipo incorrecto, periodo no positivo o máximo incompatible con mínimo. Y si un periodo extremadamente corto supone riesgo de amplificación, el servidor puede responder al GET sin registrar al observador; la ausencia de la opción Observe revela esa decisión.
El reloj que mide no es el que envía
c.epmin expresa que el cliente no desea evaluaciones más frecuentes. c.epmax limita cuánto puede esperar el servidor hasta la siguiente evaluación. Entre ambas se define una cadencia discreta: un pico puede aparecer y desaparecer sin convertirse en muestra.
c.pmin limita los envíos. Puede retrasar una condición ya observada y favorecer la consolidación de estados. c.pmax solicita una separación máxima entre notificaciones, pero el borrador niega que un mínimo igual al máximo cree un contrato de tiempo real. Es un objetivo de mejor esfuerzo.
De ahí salen tres cronologías distintas: el recurso cambia, el servidor evalúa y el servidor envía. La red agrega una cuarta, y la aplicación una quinta. Para investigar un silencio hacen falta todos esos tiempos.
Un ACK termina una conversación, no una consecuencia
Con c.con=true, las notificaciones deben viajar como mensajes confirmables. El acuse mejora la evidencia de entrega del intercambio CoAP. No demuestra que el sensor midiera continuamente, que el proxy no ocultara otra actualización, que el programa consumiera el dato ni que un actuador produjera el efecto deseado.
El Token correlaciona solicitudes y respuestas; el número Observe ayuda a ordenar estados; OSCORE protege mensajes en su contexto. Son controles concretos. Usarlos como sustituto de la realidad física les atribuiría una autoridad que no poseen.
Una cancelación tiene nombre completo
Para cancelar explícitamente, el cliente debe reenviar la URI original con todos sus parámetros condicionales. Dos umbrales sobre el mismo recurso son observaciones diferentes. Borrar una tarjeta de interfaz o enviar una URI aproximada no prueba que el servidor haya liberado la proyección correcta.
El recibo de cierre necesita endpoint, Token, URI completa, señal de cancelación y respuesta. Sin él, una relación olvidada puede seguir consumiendo batería y produciendo eventos invisibles al operador.
Ocho preguntas antes de declarar “sin alarma”
¿Qué capacidad anunció ese recurso? ¿Qué proyección exacta quedó registrada? ¿Qué parámetros soportó realmente? ¿Cuándo y con qué resolución se muestreó? ¿Qué cálculo disparó la obligación de avisar? ¿Qué periodos retrasaron o fusionaron el envío? ¿Atravesó el mensaje el proxy y llegó al cliente correcto? ¿La aplicación actuó y se observó el resultado?
Una respuesta negativa o desconocida en cualquiera de estas preguntas mantiene abierto el significado del silencio. Puede ser estabilidad, un cruce entre muestras, un filtro ignorado, una evaluación tardía, una notificación retenida, una caché, una pérdida o una aplicación detenida.
La documentación congelada no prueba productos, adopción, incidentes, tasas de pérdida ni seguridad física. El texto sobre amplificación citado por el borrador es, además, un Internet-Draft IRTF expirado. Sirve para delimitar una amenaza, no para afirmar que ocurrió.
Con la distinción de Lu Heng entre registro y autoridad, la proyección es un registro útil de decisiones locales. La autoridad sobre la conclusión operacional sigue en los sistemas capaces de observar el estado y ejecutar la respuesta.
Fuentes
- Datatracker — revisión 14
- Datatracker — historial
- Archivo IETF — texto de la revisión 14
- RFC 7252 — CoAP
- RFC 7641 — Observe
- RFC 6690 — CoRE Link Format
- RFC 8323 — CoAP sobre transportes fiables
- RFC 8613 — OSCORE
- RFC 9175 — procesamiento de Tokens CoAP
- Datatracker — borrador expirado sobre amplificación CoAP
- Lu Heng — On Authority, Belief, and the Internet’s Addressing System
- Lu Heng — Running-Code Primacy
- Lu Heng — The Stability Fallacy
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
