Resumen

  • El borrador de ECRIT añade a LoST un sondeo ordenado de cambios previstos, una validación asOf para una fecha indicada y el consejo revalidateAfter. El cliente puede preparar registros antes de la fecha efectiva.
  • Una consulta futura no inmoviliza el conocimiento. El texto permite que dos consultas con el mismo asOf den respuestas diferentes si se hacen en momentos distintos y prohíbe asumir que el resultado seguirá vigente.
  • Conviene conservar un recibo de preparación y otro de corte. La propuesta pertenece al análisis editorial de Daniel Kade; no es un requisito del borrador ni una afirmación de despliegue.

El edificio no se mueve, la dirección sí

La anexión de parte de un distrito ofrece un ejemplo revelador. Al llegar la fecha legal, un elemento de la dirección cívica puede pasar de estar vacío o contener otro valor a llevar el nombre del municipio. El lugar físico es continuo; la representación administrativa tiene un antes y un después.

El borrador Validation of Locations Around a Planned Change toma ese caso y añade el cambio de nombre o numeración de calles. La revisión 18 es un Internet-Draft activo del grupo ECRIT. Sigue siendo trabajo en curso: no es un RFC, no demuestra adopción y no documenta un incidente real.

RFC 5222 define LoST. Un cliente aporta una ubicación y un identificador de servicio; el servidor devuelve URI y datos asociados. La misma operación puede solicitar la validación de los componentes de una dirección cívica. RFC 5139 describe el formato revisado de esos componentes.

Un cliente que conserva una gran base de ubicaciones necesita saber cuándo sus registros pueden perder validez. Revalidarlo todo en un ciclo arbitrario consume recursos y puede no coincidir con el instante del cambio. El borrador ofrece un aviso dirigido y la posibilidad de comprobar por adelantado el registro de reemplazo.

La ventaja es preparación. El límite es evidencia. Preguntar hoy cómo se validaría una ubicación el mes próximo no transporta al servidor al mes próximo. La respuesta sigue perteneciendo al momento de la consulta.

Tres tiempos y tres preguntas

El primer tiempo es el de la secuencia publicada. Una interfaz REST/JSON permite descubrir versiones, sondear cambios y recuperar un ChangeSet. Este objeto contiene un identificador ordenado, una fecha efectiva y ubicaciones parciales. El cliente guarda el último identificador para pedir los posteriores.

El segundo tiempo aparece en asOf. El cliente añade una fecha y hora a findService; el servidor responde según lo que conoce en ese momento sobre lo que estará vigente para la fecha solicitada. Cuando la fecha no es la del instante de consulta, la respuesta repite asOf y las correspondencias deben marcarse NO-CACHE.

El tercer tiempo es la próxima revisión. revalidateAfter puede indicar cuándo convendría volver a validar. NO-EXPIRATION no significa que el registro sea eterno. Significa que el servidor no conoce ahora un cambio programado que altere el resultado y no sugiere una fecha concreta.

Cada mecanismo responde algo distinto: novedades posteriores a una posición, proyección para una fecha y recomendación de nueva consulta. Ninguno atestigua que la autoridad cívica ejecutó el acto, que el cliente instaló el cambio, que el mapa de servicio permaneció igual o que una comunicación llegó a destino.

Una interfaz interna puede ocultar estas diferencias bajo un único estado de “validado”. Sería una mala simplificación. Atribuiría al servidor poder sobre una base local que no observa y convertiría un consejo temporal en una orden.

Una ubicación parcial delimita candidatos

El servidor no necesita enumerar todas las direcciones completas. Puede publicar una ubicación parcial formada por pares de nombre, espacio de nombres y valor. El cliente los compara con sus registros. Si coinciden todos los pares aportados, el registro puede verse afectado; los elementos omitidos no cuentan.

Así se puede señalar una división administrativa sin detallar cada calle o indicar una calle sin listar cada número. El selector reduce el universo de revisión. No resuelve la revisión.

La palabra “puede” exige una contabilidad propia. El cliente debería retener el ChangeSet, la instantánea local, la lógica de coincidencia, los candidatos, las exclusiones y las excepciones. Si solo guarda un total, no podrá explicar por qué una segunda ejecución eligió otra población.

Esta división expresa una gobernanza delgada. La capa común transmite identificadores, tiempos y elementos comparables; los operadores deciden cómo aplicar ese conocimiento. La propuesta de especificación inicial mínima de Lu Heng ayuda a leer el diseño: lo compartido debe ser suficiente para la interoperabilidad, sin capturar todas las decisiones futuras de quienes ejecutan el código.

Corregir una previsión no invalida su historia

El apartado sobre asOf establece que una misma consulta futura puede cambiar con el tiempo. El servidor puede aprender un cambio planificado o imprevisto después de la primera respuesta. Por ello no garantiza una consulta futura de la misma ubicación.

La regla evita una falsa certeza. Una anexión puede aplazarse; una lista de calles puede corregirse; un conjunto de datos puede incorporar otra modificación. Si el primer resultado se vuelve irrevocable, el sistema protege su coherencia administrativa a costa de representar mal el mundo.

La marca NO-CACHE hace operativa esa cautela. El borrador también mantiene la consulta contemporánea: para contactar un servicio, el cliente debe usar LoST cuando surge la necesidad. Preparar una ubicación válida para una fecha no sustituye encontrar el servicio actual en ese momento.

El mandato de ECRIT incluye mecanismos que usan ubicación e información de encaminamiento para conectar con el centro de respuesta pertinente. Además, exige soluciones que no dependan de una sola autoridad central y que admitan delegaciones independientes. El artículo no puede saltar desde una validación de dirección hasta la afirmación de que una llamada funcionará. Tampoco puede saltar desde un servidor hasta todos los clientes.

La disciplina de realidad, no defensa de una causa de Lu Heng pide conservar la frase completa: “el servidor respondió esto, a esta hora, sobre esta fecha futura”. Quitar cualquiera de esos límites convierte un dato útil en propaganda de certeza.

La secuencia también necesita una línea de base

El sondeo está pensado para repetirse cada pocos minutos. El cliente aporta el último identificador y recibe los ChangeSets posteriores. Si no recibe ninguno, sabe que su identificador es el último que el servidor conoce en ese momento.

Pero un cliente nuevo o uno que perdió su posición pregunta sin identificador. El servidor devuelve todos los conjuntos que todavía retiene. El borrador admite que la retención puede ser limitada y ofrece ejemplos de tres o doce meses según la frecuencia de cambios.

Si la interrupción supera esa ventana, la secuencia conservada puede estar perfectamente ordenada y, sin embargo, ser incompleta para el cliente. La respuesta correcta es declarar una discontinuidad, construir una nueva línea de base y abrir otra época de seguimiento. No se debe presentar el primer identificador disponible como el inicio real de la historia.

Una respuesta vacía tampoco demuestra que el cliente procesó lo anterior. Solo establece la relación entre el identificador enviado y la lista actual del servidor. El principio del Policy Mirror es pertinente: respetar el registro no exige convertirlo en un trono. Su autoridad termina donde termina su observación.

Dos recibos unidos por una clave

El recibo de preparación debe conservar el servidor, la versión de la interfaz, el instante del sondeo, la posición anterior, los nuevos identificadores y la fecha efectiva. Debe sumar el selector parcial, la instantánea de la base, el algoritmo de coincidencia, los registros candidatos y las excepciones. La consulta LoST necesita ubicación, servicio, asOf, respuesta, revalidateAfter, estado de caché y revisión del documento.

El recibo del cambio real empieza después. Debe registrar la hora aceptada por el operador, la retirada de registros antiguos, la activación de los nuevos, una validación contemporánea, las diferencias con el plan, los casos pendientes, el retroceso y la autoridad que cerró la operación.

La forma propuesta no pertenece al borrador. Es una práctica editorial para impedir que una proyección suplante una observación. Puede haber una vista protegida con detalle por registro y una vista pública con cantidades, franjas horarias y excepciones. Una huella criptográfica puede unirlas, pero no dice si el cambio era correcto.

Cuando el resultado actual difiere del preparado, ambos deben sobrevivir. El primero muestra qué decisión era razonable con la información disponible. El segundo muestra qué estado encontró el cliente. Borrar el primero elimina contexto; mantener solo el primero elimina realidad.

La frecuencia es una decisión de riesgo

El borrador presenta el intervalo como equilibrio entre actualidad, carga, estabilidad de datos y política. Menciona seis meses o más en zonas estables y entre 20 y 30 días en zonas de crecimiento rápido. Son ejemplos, no obligaciones universales.

El servidor conoce su capacidad y sus fuentes. El cliente conoce el coste de datos obsoletos y la importancia de cada registro. revalidateAfter permite aconsejar sin asumir el riesgo local. La desviación puede ser legítima, pero debe conservar responsable, motivo y fecha de revisión.

La seguridad también impone un límite: sondeos demasiado frecuentes pueden afectar otros procesos LoST. La frescura consume la misma infraestructura cuya disponibilidad pretende proteger. La gobernanza útil no escoge una cifra mágica; registra el consejo, la decisión y las señales que obligarán a revisarla.

Un vocabulario preciso para la prueba

El recibo previo puede demostrar que un cliente recibió cierto ChangeSet, eligió ciertos candidatos y obtuvo una respuesta futura. El posterior puede demostrar qué filas activó y qué devolvió la validación contemporánea.

No demuestran por sí solos la legalidad del límite cívico, la igualdad entre todos los servidores, la permanencia de un mapa ni el éxito extremo a extremo de una comunicación. Cada afirmación requiere el testigo situado en esa capa.

La autoridad cambia el límite. El servidor representa datos. El cliente cambia su base. LoST resuelve un servicio en el presente. Otro sistema realiza la comunicación. Separar estos verbos no debilita la rendición de cuentas; hace posible atribuirla.

Fuentes