Resumo

  • A proposta acrescenta ao LoST uma sequência de ChangeSets, permitindo localizar registros afetados, preparar substitutos e validá-los para um horário futuro com asOf.
  • A resposta futura registra o conhecimento disponível quando o servidor responde; ela é NO-CACHE, pode mudar e não substitui a consulta LoST feita no momento em que o serviço é realmente necessário.
  • Aviso, posição na sequência, validação antecipada, preparação, ativação, mapping da chamada, transporte da localização, roteamento ao PSAP e resultado são recibos separados.

A casa não mudou de lugar; o valor administrativo mudou de vigência

Quando uma área é incorporada a um município à meia-noite, o prédio continua no mesmo ponto. Ainda assim, um elemento cívico como A3 pode ter um valor correto às 23h59 e outro às 00h00. A base do Location Information Server precisa retirar o registro anterior e ativar o novo sem deixar o endpoint de emergência preso entre duas descrições.

O rascunho atual cria uma rotina para esse caso. RFC 5222 já permite validar uma localização cívica e mapear localização mais serviço para um URI. RFC 5139 define a estrutura cívica. A extensão propõe PlannedChangePoll, GetChangeSet e Versions.

O ChangeSet traz ID, horário efetivo e localizações parciais. O cliente compara esses elementos com seus registros, separa os candidatos e prepara substituições. Com asOf, consulta como o servidor entende que a localização será validada no horário futuro. Com revalidateAfter, recebe uma recomendação sobre quando revisar um resultado atual.

É uma ferramenta de preparação. O erro começaria se a organização a tratasse como execução automática.

O futuro vem marcado como NO-CACHE

O servidor não declara uma verdade imutável. Ele responde com o que conhece no instante da consulta sobre o que deverá valer até o asOf. Um plano novo ou uma mudança não planejada pode surgir. Duas consultas para o mesmo horário futuro podem divergir. Por isso o mapping deve usar expires="NO-CACHE", e o cliente não pode presumir que ele continuará válido.

Ao contatar o serviço, o cliente ainda deve usar LoST de modo contemporâneo. Essa exigência impede que uma projeção administrativa substitua a observação operacional.

Nem NO-EXPIRATION significa validade eterna. A expressão informa apenas que o servidor não conhece uma mudança planejada relevante e não sugere uma data de revalidação. A proposta mantém revalidação periódica porque o mundo também muda sem aviso.

RFC 6443 coloca o mapping dentro de uma cadeia maior: obtenção da localização, consulta LoST, transporte da localização e da rota, proxies, funções de roteamento e recebimento pelo PSAP. RFC 6881 recomenda atualizar localização e mapping no momento da chamada, mas também prevê o uso de valor em cache quando a atualização demora demais. A validação feita dias antes não mostra qual estado foi usado nem prova a chegada da chamada.

O cursor pertence a uma relação operacional específica

O cliente guarda o último changeSetId e pede os seguintes. A forma textual do ID pode não ordenar nada; o servidor conserva a ordem. Se o cliente perder o cursor, solicita tudo o que o servidor ainda mantém, mas o servidor não é obrigado a guardar mudanças antigas indefinidamente.

A revisão de segurança pergunta se os IDs são limitados a um servidor, como tratar colisões, se o cliente precisa de uma fila por autoridade e o que fazer quando autoridades discordam sobre o estado da mesma data. Também aponta que a descrição OpenAPI parece não oferecer o parâmetro de ID necessário aos polls posteriores.

Isso delimita a alegação possível. O cursor indica onde um cliente está na sequência retida por um servidor. Não atesta consenso entre autoridades, ausência de eventos perdidos, aplicação correta na base local ou ativação no horário marcado.

A revisão de operações encontra outra divisão de autoridade. Relax NG continua sendo a definição autoritativa de RFC 5222, enquanto o XML Schema oferecido pelo rascunho é mais acessível, porém não autoritativo. Uma implementação não pode converter a aprovação de um artefato conveniente em conformidade com o artefato normativo sem prova de equivalência.

A troca segura deixa uma cadeia verificável

O recibo do aviso registra servidor, ID, horário efetivo, localização parcial e registros locais correspondentes. O recibo da sequência guarda escopo do servidor, cursor anterior, IDs retornados, janela de retenção e lacunas. O recibo de validação futura guarda hora da consulta, asOf, entrada exata, resposta e NO-CACHE.

A preparação local documenta geração das novas linhas, conflitos, aprovação e agendamento. No horário efetivo, outro registro precisa mostrar que as linhas antigas saíram, as novas entraram, os erros foram isolados e o rollback continuou disponível.

Quando há uma chamada, a prova nasce de novo no presente: localização obtida, mapping contemporâneo, URI do PSAP, objeto ou referência transportada, caminho pelos proxies e ESRP, recebimento, estabelecimento e resposta. Cada sistema responde pelo estado que possui. Continuidade conecta os recibos; não concede a um componente autoridade para declarar o resultado do próximo.

Essa divisão evita a confusão entre camada simbólica e camada executável. Um plano aprovado pode orientar trabalho. Somente o estado observado mostra que a infraestrutura realmente fez o que o plano descreveu.

A proposta segue em avaliação

No corte da pesquisa, a agenda do IESG colocava a revisão 18 no telechat de 24 de setembro. Datatracker mostrava IESG Evaluation, três DISCUSS, posições adicionais ainda necessárias e questões de registro XML na revisão da IANA. As revisões de segurança e operações apontavam problemas. O texto não é RFC aprovado, relato de implantação nem resultado de interoperabilidade.

Este artigo não prevê a votação. A fronteira de evidência independe dela: um protocolo de planejamento só permanece confiável quando seus operadores continuam capazes de provar a execução, observar o estado atual e contestar um resultado incorreto.

Fontes

Registros primários: Internet-Draft atual, agenda do IESG, revisão de segurança, revisão de operações, RFC 5222, RFC 5139, RFC 6443 e RFC 6881.