Resumen

  • Tras procesar terminate y enviar la respuesta, RFC 3343 prohibía nuevas actualizaciones del servicio, aunque las enviadas antes podían seguir en tránsito y llegar.
  • El código 250 probaba un corte en el origen, no el drenaje de la red; correlación, generación de suscripción, vigencia y decisión del consumidor eran estados distintos.

Cancelar suele representarse como una línea total. Lo posterior parece inválido. El servicio de presencia APEX ofrecía una geometría más realista: el origen controla lo que emite después del corte, no puede recuperar de inmediato lo que ya entregó a los relés.

Una actualización tardía podía ser auténtica y la cancelación también. El orden de llegada no decidía cuál de las dos tenía autoridad sobre el estado presente.

Suscribir, observar y publicar

El servicio residía en el endpoint conocido apex=presence de cada dominio. Las aplicaciones publicaban entradas, se suscribían a la presencia de un endpoint y observaban quién estaba suscrito a ese endpoint.

La suscripción devolvía de inmediato la entrada actual. Con duración positiva, emitía cambios posteriores y terminaba al vencer; con duración cero era una consulta única. watch respondía 250, enumeraba suscriptores actuales mediante notify y seguía informando altas y bajas.

El servicio debía guardar tanto las entradas como las operaciones activas en almacenamiento persistente. Los mensajes iniciados por el servicio conservaban el identificador de la suscripción o vigilancia que los había originado. La correlación sobrevivía a la operación, pero no conservaba automáticamente su vigencia.

Una confirmación no era una barrera de drenaje

Consumidor o servicio podían terminar una operación. Si el identificador no correspondía a una operación en curso de ese origen, se devolvía error 550. Si correspondía, la operación se eliminaba y se respondía 250.

La especificación advertía que después de la terminación aún podían recibirse actualizaciones de presencia o de watcher. El servicio no enviaba ninguna nueva después de procesar terminate y su respuesta; las anteriores podían estar en tránsito.

Por tanto, 250 certificaba el estado del servicio y su conducta futura. No decía que los buffers, conexiones, planificadores o colas del consumidor estuvieran vacíos. Un verdadero drenaje tendría que contabilizar cada mensaje anterior. RFC 3343 no fingía haberlo hecho.

El identificador decía de dónde venía, no qué hacer

La actualización tardía conservaba el transID de la operación terminada. El consumidor podía atribuirla con precisión. Aun así necesitaba una generación o lápida local que indicara que la relación ya había acabado.

Según el uso, podía descartar, archivar, poner en cuarentena o contrastar el mensaje con una instantánea nueva. Lo incorrecto era aplicar el contenido solo porque el identificador coincidía. «Pertenece a esta operación» y «la operación sigue activa» son afirmaciones diferentes.

El riesgo se repetía al abrir una nueva suscripción al mismo sujeto. El RFC terminaba silenciosamente la anterior antes de continuar. La relación visible era la misma, pero la generación había cambiado. Un mensaje antiguo podía confundirse con el inicio del flujo nuevo si el consumidor no preservaba esa frontera.

Una entrada de presencia no probaba conexión

Cada dominio mantenía una entrada para cada endpoint aunque no estuviera conectado a la malla. La entrada incluía lastUpdate, información del publicador y tuplas con URI de destino, availableUntil y capacidades. Su existencia no demostraba que el endpoint estuviera adjunto ni que una entrega concreta funcionara.

La escritura usaba otra frontera. El lastUpdate enviado debía coincidir semánticamente con el almacenado; de lo contrario llegaba el código 555. El éxito 250 probaba la actualización en el servicio, no el momento de recepción en todos los suscriptores.

Así, un mensaje tardío podía estar bien formado, venir de una mutación válida y ser obsoleto para la decisión actual. La evidencia debía conservar las tres propiedades sin comprimirlas.

Registro Historic y privacidad

RFC 3343 se publicó en abril de 2003 como Experimental y hoy figura Historic. El historial IETF del 29 de julio de 2012 dice, hasta donde sabía el IETF, que no había implementaciones desplegadas de RFC 3340–3343 y que XMPP proporcionaba esa funcionalidad ampliamente mediante RFC 6120 y RFC 6121.

La nota no atribuye la falta de despliegue a esta carrera. No documenta un incidente ni mide colas. El texto también señalaba que los husos horarios podían revelar ubicación y permitía convertir la hora y usar -00:00 si esa información era sensible.

La lección es conservar recibos separados para creación, entrega al transporte, terminación, corte de emisión, drenaje, llegada y acción. Si no existe recibo de drenaje, la cancelación no debe inventarlo. El pasado puede seguir acercándose después de que el origen haya cerrado.

Fuentes