Summary

  • El borrador CoRE pubsub, revisión 22, actualizado el 2 de noviembre de 2026, propone un intermediario CoAP para clientes que pasan tiempo sin conectarse. Los editores publican con PUT; los suscriptores observan el recurso de datos o consultan su última representación. Sigue en evaluación del IESG.
  • La sección 3.3 define cómo obtener únicamente el dato más reciente. Recuperar versiones anteriores y decidir cuántas conserva el intermediario quedan para trabajos futuros.
  • Una respuesta exitosa no basta para afirmar que existe una suscripción: debe incluir la opción Observe. La aceptación de una publicación tampoco prueba su recepción o uso por cada suscriptor.

Pensemos en una instalación con un sensor térmico. La temperatura supera el umbral durante una hora y luego vuelve a su rango normal. La consola de mantenimiento estuvo apagada durante ese intervalo. Al regresar, pide el dato reciente al intermediario y muestra un valor normal. Esa pantalla muestra fielmente el último dato recibido por el intermediario. No puede reconstruir con su sola lectura el episodio que pasó mientras nadie la miraba. Es un ejemplo para probar el contrato descrito por el borrador; sus autores no registran un incidente de esa planta.

El texto del grupo CoRE divide el trabajo en recursos. El intermediario aloja colecciones de temas, un recurso de configuración para cada tema y otro recurso para sus datos. Quien publica envía PUT al segundo. Quien se suscribe envía GET con Observe: 0, usando la observación definida por el RFC 7641. Así puede recibir cambios de estado aunque el editor y el suscriptor no mantengan la misma conexión todo el tiempo. La dirección del recurso de datos se obtiene de la propiedad topic-data; no tiene por qué parecerse a la dirección del tema.

Tres formas de no tener una lectura

Cuando se crea un tema, ya existe un recurso de datos, pero no tiene representación. El borrador usa 2.06 No Content para esa situación. Un recurso inexistente suele responder 4.04 Not Found. Un tema con datos devuelve la representación publicada más reciente, normalmente con 2.05 Content. Si una consola convierte los tres resultados en “sin alerta”, pierde información antes de que empiece la investigación.

El límite histórico está escrito sin rodeos: este mecanismo solo ofrece acceso a la última representación. Una especificación futura podría dar acceso a las anteriores y regular cuántas guarda el intermediario. Quien necesita probar que una alarma subió y bajó durante una desconexión debe contratar otra memoria: un registro duradero de publicaciones, identificadores, tiempos y entregas. La lectura actual no es un extracto de ese registro.

También hay que separar respuesta de suscripción. Si el GET con Observe: 0 devuelve dato y opción Observe, el cliente quedó registrado. Si el tema existe pero aún está vacío, 2.06 No Content con Observe confirma el registro y la primera publicación puede llegar luego como aviso. Si falta Observe, la suscripción fracasó, aunque el código sea 2.05 o 2.06. Al alcanzar max-subscribers, el intermediario omite la opción. Una integración que solo examina el código de éxito puede creer que vigila un tema al que nunca quedó abonada.

El ciclo del tema abre otra grieta. Su eliminación borra tanto el recurso administrativo como el de datos y despide a los observadores con un 4.04 final. Una fecha de expiración opcional puede causar la misma desaparición. Al investigar un intervalo vacío hay que preguntar si el suscriptor estaba desconectado, si se rechazó su inscripción, si el tema no tenía contenido o si dejó de existir. Son hechos diferentes.

El acuse del intermediario no llega hasta la sala de control

La publicación por PUT suele recibir 2.04 Changed, dentro del modelo CoAP del RFC 7252. Significa que el intermediario aceptó el cambio; no certifica la entrega a cada suscriptor ni una decisión de la aplicación. Si las publicaciones llegan demasiado rápido, el borrador permite 4.29 Too Many Requests; Max-Age marca cuánto debe esperar el editor antes de reintentar. Un historial operativo tiene que incluir los rechazos, no solo los valores que consiguieron entrar.

El borrador exige proteger la comunicación entre cada cliente y el intermediario. Para el contenido publicado pide además protección de extremo a extremo con autenticación del origen, de forma que el suscriptor pueda verificar al editor. Un canal seguro hasta el intermediario no autentica automáticamente la medición del sensor frente a quien la recibe. Tampoco una medición auténtica prueba que un técnico vio el aviso o actuó.

El diseño resuelve un problema real de equipos que duermen o pierden conexión: recuperar el estado reciente sin mantener despiertos a todos. Pero no promete conservar cada cambio, y el documento no aporta un despliegue medido que complete esa promesa por otra vía. La prueba que cambiaría una decisión de operación es una secuencia verificable de publicaciones aceptadas y recepciones durante la hora perdida. Sin ella, la cifra normal es una respuesta correcta a una pregunta demasiado pequeña.

Borrador CoRE pubsub · RFC 7641 · RFC 7252