Resumen

  • El vencimiento de reportAfter generaba un informe transitorio, pero RFC 3342 ordenaba enviar de todos modos los datos al siguiente relé.
  • noLaterThan sí podía cortar la entrega y returnTrip limitaba el retorno del informe final; alarma, enforcement, recibo y resultado eran pruebas diferentes.

APEX ofrecía en su núcleo un datagrama de aplicación inmediato y de mejor esfuerzo. Sin opciones, la indisponibilidad de un relé podía acabar en descarte silencioso. RFC 3342 añadió mecanismos para esperar, informar y limitar, pero no concedió a cada temporizador la misma autoridad.

La diferencia resulta incómoda para cualquier sistema que quiera pintar una sola luz verde o roja. Una alarma suele alimentar reintentos, compensaciones y cierres automáticos. Sin embargo, el informe de demora de este RFC podía ser exacto y coexistir con un mensaje que seguía vivo.

El aviso consumía su umbral

dataTiming se procesaba salto a salto. Por eso el origen debía indicar targetHop="all" y mustUnderstand="true". Antes de enviar al siguiente relé, cada nodo restaba de reportAfter el tiempo que había gastado localmente en resolver el siguiente paso, enlazarlo y quedar listo para transmitir.

Al llegar a cero, el nodo fijaba el valor en cero, invocaba el servicio de informes y, pese a ello, enviaba los datos. En el salto final también emitía un informe si no obtenía el ok del endpoint dentro del intervalo. El statusResponse conservaba el identificador de la opción y usaba para el destinatario original un código 350 de éxito transitorio.

Nada en ese recibo decía «descartado». La afirmación era más estrecha: la entrega había tardado más que el umbral de aviso en ese punto. Si el mensaje llegaba después, no refutaba la demora. Si no llegaba, el aviso por sí solo tampoco explicaba el desenlace.

El límite duro podía negar el siguiente salto

noLaterThan tenía consecuencias operativas. El relé reducía su saldo por el procesamiento local. Si quedaba en cero o menos antes de reenviar, se producía un error y los datos no cruzaban al siguiente relé. Cuando reportErrors estaba activo, se generaba además un informe de error temporal.

En el endpoint, el mismo presupuesto restante limitaba la espera del ok. El vencimiento era un error. Así, reportAfter representaba «avisa y continúa», mientras noLaterThan representaba «no continúes más allá». Colocar ambos eventos en la misma casilla de fallo borra la decisión que distingue observación de control.

El límite duro tampoco certificaba una causa universal. Podían consumirlo el cálculo local, una conexión lenta, un relé no disponible, un endpoint no conectado o la congestión. Lo probado era que el intento no completó cierta etapa dentro del saldo, no que una aplicación concreta hubiera fallado ni que el usuario hubiera sufrido un resultado determinado.

La prueba tenía su propio viaje

Tras transmitir con éxito al destinatario, un returnTrip distinto de cero hacía que el servicio produjera un informe de último salto. Ese informe volvía como otra operación de datos APEX. Llevaba su propio dataTiming, cuyo noLaterThan era igual al returnTrip del mensaje original.

Por tanto, la carga y la noticia sobre la carga tenían destinos y presupuestos separados. La carga podía llegar, el relé podía crear el informe y ese informe podía perderse al regreso. Cuando vencía su plazo, el origen podía presumir que el informe se había perdido; no podía convertir esa ausencia en prueba retrospectiva de que la carga no llegó.

Una bitácora útil guardaría la aceptación inicial, el saldo de aviso, la generación del informe transitorio, el avance posterior, el saldo duro, el punto de corte o acuse, la creación del informe final, su presupuesto de vuelta, su recepción y el efecto observado en la aplicación. El historial no debe ser sustituido por una etiqueta final.

Otras opciones, otras fronteras

hold4Endpoint permitía guardar los datos mientras el endpoint destinatario no estuviera conectado. Sin un límite superior, la cola podía durar indefinidamente. El RFC advertía de la posibilidad de denegación de servicio y proponía límites administrativos, por ejemplo exigir un noLaterThan breve. Tener algo en cola no era haberlo entregado ni prometer que se entregaría.

dataHopping limitaba el número de relés con un mecanismo semejante al TTL de IP. Contaba topología, no tiempo. Un mensaje podía agotar el plazo con pocos saltos o agotar los saltos dentro del plazo. Cada contador respondía a una pregunta distinta.

attachOverride permitía sustituir una aplicación ya conectada al mismo endpoint. La propiedad de datos tardíos pertenece a la frontera descrita por RFC 3340 y a otra pieza de esta serie. Aquí basta con recordar que ningún informe temporal prueba por sí solo quién conserva autoridad para actuar.

Un documento Historic con una distinción vigente

RFC 3342 se publicó en julio de 2002 en la vía de estándares. Hoy figura como Historic y la búsqueda de erratas no muestra coincidencias. El historial del IETF del 29 de julio de 2012 dice, con la reserva de que era lo conocido por el IETF, que no se habían desplegado implementaciones de los RFC 3340–3343 y que sus funciones eran suministradas por XMPP, ampliamente desplegado según RFC 6120 y RFC 6121.

Ese registro no demuestra que el diseño de temporización causara la falta de despliegue. No documenta una avería, una vulnerabilidad ni una medición. El RFC también avisaba de que dataTiming podía exponer topología privada y permitía limitarlo a las entradas y salidas del dominio administrativo. Ver más no equivalía a mandar más.

La enseñanza permanece: antes de automatizar una reacción hay que preguntar qué observó el temporizador, qué acción autorizó y cómo volvió la evidencia de esa acción. Una alarma fiable no es un desenlace, y un recibo final no absorbe todo lo que ocurre después.

Fuentes