Resumen

  • El borrador añade a LoST un flujo de ChangeSets para localizar registros potencialmente afectados, preparar sustituciones y validarlas para un instante futuro mediante asOf.
  • La respuesta solo expresa lo que el servidor sabe en el momento de contestar: debe llevar NO-CACHE, puede cambiar y no sustituye una consulta contemporánea cuando se usa el servicio.
  • Aviso, continuidad del cursor, validación anticipada, preparación local, activación, mapeo durante la llamada, transporte de ubicación, ruta al PSAP y desenlace operativo son afirmaciones distintas.

El dato cambia a medianoche; la infraestructura no recibe un oráculo

Una anexión municipal puede entrar en vigor a las 00:00. Antes de esa hora, una dirección sin determinada localidad puede ser válida; después, la misma parcela necesita otro valor administrativo. El punto físico permanece donde estaba. Cambian la descripción autorizada y el momento desde el que debe usarse.

El Internet-Draft vigente intenta coordinar ese corte. RFC 5222 ya define cómo un cliente pide a LoST la validación de una ubicación cívica y obtiene un URI de servicio a partir de ubicación y tipo de servicio. RFC 5139 define los elementos cívicos. La propuesta incorpora PlannedChangePoll, GetChangeSet y Versions.

Cada ChangeSet contiene un identificador, una hora efectiva y localizaciones parciales. El cliente compara esos pares de nombre y valor con su propia base de datos, identifica las filas que podrían cambiar y prepara registros nuevos. Una consulta asOf permite comprobar anticipadamente el registro que se espera activar. revalidateAfter ayuda a decidir cuándo volver a preguntar.

La utilidad es clara: menos revalidación indiscriminada y más tiempo para preparar una transición. El límite también debe quedar claro: conocer el plan no ejecuta el plan.

La propia respuesta futura lleva una advertencia de caducidad

Para asOf, el servidor comunica su conocimiento actual sobre lo que estará vigente. No mantiene necesariamente un historial, puede aprender cambios nuevos y no promete que dos consultas hechas en momentos distintos produzcan el mismo resultado para la misma fecha futura. Por eso cada mapping de ese tipo debe tener expires="NO-CACHE".

El cliente tampoco puede usar esa respuesta como sustituto permanente. Cuando llegue el momento de contactar un servicio, se espera una consulta LoST contemporánea. La previsión sirve para preparar registros y pruebas; el estado actual sirve para tomar una decisión operativa.

NO-EXPIRATION tampoco es una escritura de eternidad. Significa que el servidor no conoce en ese instante un cambio planificado que justifique una fecha de revalidación. Puede aparecer una corrección no planificada, una nueva decisión administrativa o información más reciente. El borrador conserva la revalidación periódica incluso si funciona el canal de avisos.

La arquitectura de RFC 6443 separa con razón la obtención de ubicación, el mapeo LoST, la transmisión de la ubicación, el enrutamiento y la recepción por el PSAP. RFC 6881 añade otra cautela: al efectuar una llamada, el terminal debe intentar actualizar ubicación y mapping, y si el tiempo no alcanza puede usar un valor almacenado. Una validación futura no prueba qué rama tomó el dispositivo ni adónde llegó la señalización.

Un cursor no constituye consenso entre autoridades

El cliente conserva el último changeSetId y pide al servidor los posteriores. El texto del ID puede ser opaco; el orden vive en el estado del servidor. Si el cliente pierde ese punto, solo puede reconstruirlo con los ChangeSets que el servidor aún retenga.

La revisión de seguridad pregunta por la frontera que falta alrededor de ese estado: ¿el ID pertenece a un servidor concreto?, ¿qué significa una colisión entre servidores?, ¿hacen falta colas separadas?, ¿cómo se resuelve una discrepancia sobre la misma fecha? También observa que el OpenAPI no parece ofrecer el parámetro necesario para el ID de las consultas posteriores, pese a que la prosa lo exige.

La conclusión operacional es limitada. El cursor puede acreditar la posición de un cliente dentro de una secuencia que conserva un servidor. No demuestra que todas las autoridades relevantes publicaron el mismo futuro, que la retención cubrió el periodo de desconexión ni que el cliente aplicó correctamente cada cambio.

La revisión de operaciones identifica otra separación: RFC 5222 mantiene Relax NG como esquema autoritativo, mientras el nuevo XML Schema se presenta como alternativa más manejable pero no autoritativa. Pasar la validación cómoda no puede reclamar automáticamente la autoridad de la otra si la equivalencia aún está en discusión.

La transición necesita recibos antes, durante y después

El aviso debe guardar servidor, ID, hora efectiva, localización parcial y registros coincidentes. La continuidad debe guardar ámbito del servidor, cursor anterior, secuencia, ventana de retención y huecos. La prueba anticipada debe guardar hora de consulta, asOf, entrada exacta, respuesta y marca NO-CACHE.

Luego empieza el trabajo local: construcción de las filas nuevas, resolución de conflictos, aprobación y programación. A la hora efectiva hace falta una evidencia distinta de que las filas antiguas se retiraron, las nuevas se activaron y el procedimiento de reversión siguió disponible.

Cuando existe una llamada real, la cadena vuelve a empezar desde el presente. ¿Qué ubicación obtuvo el terminal? ¿Qué mapping devolvió LoST entonces? ¿Qué URI del PSAP se usó? ¿Qué objeto de ubicación viajó? ¿Qué proxies y elementos de enrutamiento lo procesaron? ¿El PSAP recibió y respondió? El resultado no se hereda desde una casilla verde de preparación.

La disciplina es sencilla: cada componente certifica únicamente el estado que controla. El servidor LoST no puede firmar por la base activa del LIS; el LIS no puede firmar por la ruta; la ruta no puede firmar por la respuesta humana. La continuidad técnica une recibos, no fusiona autoridades.

El estándar todavía está en evaluación

Al cierre de la investigación, la agenda del IESG incluía la revisión 18 en la teleconferencia del 24 de septiembre. Datatracker mostraba IESG Evaluation, tres posiciones DISCUSS, votos adicionales pendientes y una revisión de IANA no resuelta sobre el registro XML. Las revisiones de seguridad y operaciones indicaban problemas. No es un RFC aprobado, un informe de despliegue ni una prueba de interoperabilidad.

El artículo no anticipa el resultado. Conserva el criterio que seguirá siendo necesario después de cualquier revisión: distinguir la descripción de un futuro posible de la ejecución verificable y del resultado que finalmente experimenta una persona.

Fuentes

Registros primarios: Internet-Draft actual, agenda del IESG, revisión de seguridad, revisión de operaciones, RFC 5222, RFC 5139, RFC 6443 y RFC 6881.