Resumen

  • findServiceResponse vincula una ubicación declarada y un URN de servicio con uno o varios URI, y puede añadir procedencia, versión, caducidad, frontera y ruta de resolución. Es un recibo de cartografía, no de una llamada contestada.
  • RFC 5222 obliga a conservar matices que un indicador binario suele borrar: datos cívicos sin comprobar, mapas expirados, movimiento fuera de la zona, sustituciones, destinos por defecto y redirecciones.
  • La cadena auditable termina mucho después de LoST: adquisición de ubicación, selección y validación, mapa vigente, contacto devuelto, establecimiento de sesión, aceptación por el receptor y resultado del servicio.

Cuando «enrutado» significó demasiadas cosas

Pensemos en una secuencia de prueba creada para una auditoría. A las 08:14:02, un dispositivo envía una dirección cívica y solicita urn:service:sos.police. Pide validación y prefiere recibir una referencia a la frontera de servicio. A las 08:14:03 llega una respuesta con URI SIP, locationUsed, un camino de resolutores y una cartografía identificada por source, sourceId, lastUpdated y expires.

El panel marca «enrutado». Esa palabra podría querer decir que el XML fue analizado, que el mapa tenía un destino o que una llamada alcanzó a un centro. Solo las dos primeras afirmaciones tienen evidencia. A las 08:14:20 no existe respuesta del protocolo de señalización ni aceptación del receptor. El ejemplo no describe un incidente real; sirve para mostrar cómo un sustantivo ambiguo puede atribuir a un mapa una actuación posterior.

RFC 5222 define Location-to-Service Translation. La operación central traduce información cívica o geodésica y un URN de servicio a URI de contacto. El límite es deliberado: la cartografía dice dónde intentar el contacto, no que el intento sucedió ni que produjo auxilio.

El servidor puede elegir una ubicación; no puede fabricar su historia

Una petición admite varios elementos location. El servidor escoge uno compatible y devuelve su identificador mediante locationUsed. Con ello se conserva una relación causal básica: se sabe qué entrada determinó el resultado.

Sin embargo, la procedencia de la entrada queda fuera de ese campo. locationUsed no indica quién observó la posición, cuánto tiempo ha pasado, qué incertidumbre tenía ni si el dispositivo se movió. RFC 4119, RFC 5139 y RFC 5491 construyen el lenguaje de los objetos de ubicación y sus reglas de uso. RFC 5985, RFC 5986 y RFC 6155 cubren entrega, descubrimiento del servidor de ubicación e identidad del dispositivo.

Esas capas no son duplicación administrativa. Separan el dato de posición de la decisión que se toma con él. Un mapa puede utilizar correctamente una entrada equivocada; en ese caso, el mapa funciona y el resultado operativo puede seguir siendo incorrecto.

La validación cívica tampoco debe exagerarse. validateLocation=true puede producir listas valid, invalid y unchecked. «Válido» significa reconocido y utilizado para calcular el mapa. «No comprobado» significa que el servidor no lo verificó ni lo usó. Si hay contradicciones, una política local decide qué campo domina. Validar tokens para cartografía no demuestra presencia física.

La versión del mapa no es la edad de la realidad

RFC 5222 exige que cada mapping lleve source, sourceId y lastUpdated. La fuente autorizada crea esos atributos y una caché los conserva. La combinación permite distinguir una cartografía concreta y sustituirla por otra más reciente de la misma fuente e identificador.

Este recibo tiene un valor exacto: identifica una versión. No prueba que la ubicación del usuario se observara en ese momento, que la organización de emergencia siga igual o que el URI continúe aceptando sesiones. Una fecha puede ser verdadera y aun así responder a la pregunta equivocada.

expires expresa la vigencia declarada del mapa. Además de una hora absoluta, admite NO-CACHE y NO-EXPIRATION. Lo incómodo es lo más útil: un servidor puede devolver información expirada como respuesta ordinaria, y el cliente debe inspeccionar la fecha y decidir según su política.

También debe reconsultar cuando sale de la frontera de servicio. Por eso la validez combina tiempo y espacio. La caché no se vuelve segura por tener un TTL que aún no terminó si el terminal cruzó la zona. Y NO-EXPIRATION no convierte un URI, una institución o una red en elementos inmutables.

Una referencia de frontera es una deuda de verificación

La frontera puede venir por valor o mediante serviceBoundaryReference. En el segundo caso, la respuesta contiene una fuente y una clave. El cliente solicita después getServiceBoundary directamente al servidor autorizado; esa consulta no se resuelve recursivamente.

El diseño permite ahorrar datos y actualizar la geometría con independencia del resto de la cartografía. También crea un punto que debe observarse. Si la aplicación nunca descarga la frontera, no puede justificar una decisión de reutilización basada en ella. Si la descarga pero pierde la clave o la versión asociada, conserva una forma sin cadena de custodia.

RFC 5582 describe la arquitectura general de mapeo. La idea operativa es prudente: una frontera autoriza reutilización bajo condiciones conocidas; no concede soberanía perpetua al mapa. El cliente sigue siendo responsable de detectar movimiento y cambio.

Recursión, redirección y confianza acotada

Un resolutor puede completar la consulta de forma recursiva, hablando con otros servidores, o devolver una redirección para que el cliente continúe de forma iterativa. El elemento path registra participantes via. Este rastro ayuda a encontrar bucles, retrasos y el origen de un aviso.

No es una firma global de la jerarquía. No demuestra por sí solo que la resolución DNS fue auténtica, que las identidades TLS se comprobaron, que cada servidor tenía el último conjunto sincronizado o que el destino final era alcanzable.

RFC 5223 trata el descubrimiento de servidores LoST con DHCP. RFC 8917 crea una etiqueta de descubrimiento específica para validación. RFC 5069 enumera amenazas para el marcado y el mapeo de llamadas de emergencia. Las funciones se conectan, pero no son intercambiables.

RFC 5222 exige implementar TLS y recomienda usarlo, incluido el control de identidad del servidor. Ese control protege la consulta y la respuesta frente a modificaciones y reduce el riesgo de envenenar cachés. Una conexión TLS correcta sigue transportando la ubicación que recibió y el mapa que el servidor poseía; no añade conocimiento del mundo exterior.

El transporte puede estar sano y el resultado degradado

Todas las respuestas LoST se transportan con códigos HTTP 2xx, normalmente 200, incluso las que contienen advertencias o errores LoST. Esto obliga a separar disponibilidad HTTP de semántica LoST. Un monitor que cuenta 200 sin analizar el XML no sabe si obtuvo una cartografía exacta, una redirección, un error o un destino de último recurso.

locationValidationUnavailable permite entregar un mapa mientras avisa que la validación solicitada no estuvo disponible. serviceSubstitution informa de que se reemplazó el servicio solicitado. defaultMappingReturned indica que no pudo resolverse la ubicación y se proporcionó un URI por defecto, quizá de un centro cercano.

El destino por defecto puede salvar una situación. Precisamente por eso el aviso debe sobrevivir. Borrarlo convierte una respuesta de contingencia en evidencia falsa de precisión territorial.

La página de erratas congelada añade otra lección: dos erratas verificadas, una reportada y dos retenidas para una futura actualización acompañan al documento. El código operativo debe poder declarar qué interpretación implementa; la etiqueta Standards Track no sustituye esa comprobación.

Firmar la distribución no demuestra la entrega

RFC 6739 separa la sincronización entre servidores de la consulta de cliente. Usa source/sourceId/lastUpdated para comparar mapas, prohíbe modificar los recibidos y exige firmas de las fuentes autorizadas para impedir que un participante se apropie de zonas ajenas.

La firma crea evidencia sobre el origen y la integridad de una cartografía distribuida. Aún quedan preguntas: ¿la recibió el resolutor a tiempo?, ¿la instaló?, ¿la seleccionó para esta consulta?, ¿el cliente la reutilizó dentro de su zona?, ¿el URI respondió? Convertir una firma de backend en un recibo de atención mezcla sujetos y momentos distintos.

RFC 5031 identifica la clase de servicio mediante URN. RFC 5012 fija requisitos para resolver el contexto de emergencia. RFC 6881 extiende la mirada a dispositivos y redes que soportan la llamada. Juntos muestran que el URI es un punto de partida para la señalización, no el último eslabón.

Doce recibos para una sola frase honesta

Una auditoría debe conservar: origen y hora de la ubicación; ID y perfil elegidos; tokens cívicos validados; URN solicitado; descubrimiento e identidad del resolutor; camino y redirecciones; source/sourceId/lastUpdated; expiración y decisión de caché; frontera; URI y avisos; intento y establecimiento de sesión; aceptación y resultado.

La frase final puede entonces ser exacta: «La cartografía vigente para la ubicación observada devolvió este URI, se intentó una sesión y el receptor la aceptó». Si faltan los últimos recibos, la frase debe terminar antes. La disciplina no reduce el valor de LoST; lo protege de una promesa que jamás hizo.

Sources

  1. RFC 5222
  2. RFC 5222 en Datatracker
  3. Estado de RFC 5222
  4. Historial de RFC 5222
  5. Erratas de RFC 5222
  6. RFC 5139
  7. RFC 4119
  8. RFC 5491
  9. RFC 5012
  10. RFC 5031
  11. RFC 5223
  12. RFC 6739
  13. RFC 6881
  14. RFC 5582
  15. RFC 5069
  16. RFC 8917
  17. RFC 5985
  18. RFC 5986
  19. RFC 6155
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption