Resumen

  • Los identificadores usados en operaciones de canal BEEP terminaban con el canal, pero un identificador incrustado en datos dirigidos a un servicio APEX podía durar más que la aplicación solicitante.
  • Que una segunda aplicación recibiera la respuesta bajo el mismo punto final no demostraba que heredara la solicitud; la identidad de ruta, la generación conectada y la propiedad del trabajo eran pruebas distintas.

La sección 6.1.1 no necesita una lectura adversarial. Cuenta de forma abierta que una aplicación puede conectarse como punto final, mandar datos con un identificador de transacción a un servicio y desconectarse. Más tarde, otra aplicación se conecta como el mismo punto final y emite sus propios datos. La respuesta a la petición antigua puede llegar entonces a la nueva aplicación con el identificador elegido por su antecesora.

El servicio no perdió necesariamente la petición y la malla no equivocó el destino. El problema es temporal: el nombre sobrevive al proceso que lo ocupaba. La coincidencia del identificador demuestra qué intercambio anterior motivó la respuesta, pero no demuestra que el receptor actual sea el dueño de aquel intercambio ni que conserve la intención de ejecutarlo.

La frontera que imponía BEEP

APEX utilizaba BEEP como sustrato. Para operaciones entre un punto final y un relé, o entre relés, el identificador solo tenía significado durante la vida del canal BEEP. Al cerrarse la conexión desaparecía el canal y terminaba la conexión del punto final a la malla. Un attach anterior no podía convertirse por sí solo en una credencial para la siguiente sesión.

Los servicios APEX introducían un alcance diferente porque el identificador podía viajar dentro de los datos. El trabajo del servicio y la respuesta podían sobrevivir a la sesión que originó la petición. Por eso RFC 3340 calificó esos identificadores como potencialmente duraderos y recomendó valores que parecieran impredecibles.

La imprevisibilidad reduce colisiones y dificulta adivinar una clave. No autentica al solicitante. Tampoco expresa cancelación, sucesión, aceptación del trabajo pendiente ni autorización actual. Un sistema que solo conserva punto final e identificador podrá reconstruir la conversación, pero no la titularidad.

La aceptación anterior al recorrido

El orden de procesamiento del relé ofrece una segunda lección. Primero se verifica que el cliente BEEP pueda enviar en nombre del origen indicado y se atienden las opciones aplicables a los datos. Después el relé devuelve ok. Solo entonces procesa opciones del originador y cada destinatario.

Si el destinatario pertenece a otro dominio administrativo, se considera procesado cuando se abre una sesión con el relé remoto, se transmiten los datos y ese relé devuelve ok. Si es local, la política de acceso debe permitir la comunicación, el punto final debe estar conectado y su aplicación debe devolver ok tras el procesamiento específico. Cada recibo cierra una etapa. Ninguno prueba por sí solo que el servicio contestó, que un usuario vio el resultado o que la operación empresarial terminó.

La opción statusRequest añadía informes posteriores de los relés aplicables mediante el servicio de reporte. Con targetHop en all podía trazarse el paso por la malla. Eran nuevas observaciones, no una reinterpretación del primer acuse. Además podían revelar topología interna; RFC 3342 señalaba que un administrador quizá quisiera desactivar esa capacidad salvo en los límites de entrada y salida.

Autenticar no es preservar al actor

APEX descubría relés mediante DNS SRV. Su propio texto vinculó la integridad del relay con DNS y con la forma en que las aplicaciones lo usaban, y mencionó la autenticación del oyente BEEP como garantía adicional. Las políticas podían permitir que un par autenticado actuara como determinado punto final. Para autenticación de extremo a extremo, el contenido debía firmarse.

Esas garantías son compatibles con un cambio de aplicación. Prueban un relé, un par, el permiso para usar un nombre o la integridad de unos bytes. No prueban que la instancia conectada ahora sea la que generó la solicitud. Una respuesta firmada puede ser auténtica y, aun así, carecer de un propietario autorizado en la generación presente.

El registro útil separa nombre lógico, par autenticado, canal, generación de conexión, identidad de proceso, identificador y método de generación, huella de la petición, recibo persistente del servicio, acuses de relé, informes de estado, desconexión, siguiente conexión, huella de la respuesta, generación receptora, decisión de consumir o aislar, estado de idempotencia y resultado observado. Las claves enlazan esos recibos; no deben sustituirlos.

Un estándar que pasó a ser historia

RFC 3340 apareció en julio de 2002 en la vía de estándares. Formaba una familia con el servicio de acceso, el conjunto de opciones y el servicio de presencia de RFC 3341, RFC 3342 y RFC 3343. El historial del IETF registra que los cuatro documentos fueron reclasificados como Historic el 29 de julio de 2012. Según el conocimiento del IETF, no se había desplegado ninguna implementación y la función de APEX la ofrecía XMPP, ampliamente desplegado y especificado en RFC 6120 y RFC 6121.

Esa explicación no identifica la causa de cada decisión de implementación. No dice que la larga vida del identificador condenara a APEX ni documenta un fallo operativo. Distinguir el resultado de adopción del mérito técnico evita convertir una fuente precisa en una fábula. La escena de las dos aplicaciones conserva valor justamente porque el reemplazo de consumidores y las respuestas asíncronas siguen existiendo.

La respuesta tardía no debe rechazarse por definición. Puede ser válida, íntegra y todavía útil. Antes de convertirla en acción hace falta, sin embargo, una prueba que una al solicitante antiguo con el receptor actual. El identificador dice «esto responde a aquello»; no dice «tú debes hacerlo ahora».

Fuentes