Resumo

  • A resposta findServiceResponse pode registrar qual localização foi usada, quem originou o mapa, qual é sua versão e validade, a área de serviço, o caminho de resolução e um URI. Isso comprova uma tradução, não uma chamada concluída.
  • O próprio RFC 5222 prevê respostas condicionais: campos cívicos não verificados, mapas vencidos, avisos de substituição, URI padrão e redirecionamentos. HTTP 200 não elimina essas diferenças.
  • A operação precisa preservar recibos em sequência, do dado de localização à tentativa de sessão e ao resultado do atendimento. Nenhuma etapa deve assinar pela etapa seguinte.

O painel ficou verde cedo demais

Considere um ensaio, não um caso ocorrido. Às 08:14:02, um aparelho envia uma localização cívica, solicita urn:service:sos.police e pede validação. Às 08:14:03, o resolvedor retorna um URI SIP, uma referência de fronteira, locationUsed, uma lista path e os atributos source, sourceId, lastUpdated e expires.

Às 08:14:04, o painel chama a operação de “encaminhada”. Às 08:14:20, porém, não existe recibo de estabelecimento SIP, aceitação pelo destino, mídia ou atendimento. A cartografia respondeu; a chamada ainda não tinha produzido um evento.

RFC 5222 define a tradução de localização para serviço. Ele recebe uma localização cívica ou geodésica e um URN de serviço e devolve um ou mais URI com metadados. O protocolo não ganha, por isso, autoridade sobre a plataforma de sinalização nem sobre a organização que presta o serviço.

Saber qual localização foi usada não prova onde alguém estava

Uma consulta pode incluir vários elementos location. O servidor escolhe um perfil que entende e informa, em locationUsed, o identificador efetivamente utilizado. É uma informação de causalidade importante: o resultado deixa de ser uma caixa-preta.

O identificador não traz a história de aquisição. Não diz quem mediu a posição, quando, com qual precisão ou se o dispositivo se deslocou. RFC 4119, RFC 5139 e RFC 5491 tratam do objeto de localização, do endereço cívico e do uso de PIDF-LO. RFC 5985, RFC 5986 e RFC 6155 separam entrega de localização, descoberta do LIS e identidade do dispositivo.

Essa arquitetura impede uma conclusão automática. Um dado pode estar sintaticamente perfeito e temporalmente errado. O LoST pode mapear com exatidão a localização que recebeu sem demonstrar que ela descreve a situação atual.

A validação cívica também é específica. Com validateLocation=true, o servidor pode classificar elementos como valid, invalid e unchecked. Valid quer dizer reconhecido e usado no mapeamento; unchecked quer dizer não testado e não usado. Uma política local pode resolver contradições, e a resposta pode omitir a validação. O teste melhora a chave de busca, mas não certifica presença física.

Proveniência, atualização e expiração respondem perguntas diferentes

O trio source, sourceId e lastUpdated identifica uma instância de mapeamento. A fonte autorizada cria os valores e os caches não devem alterá-los. Um registro com a mesma fonte e identificador, mas com lastUpdated mais recente, pode substituir a versão anterior.

Isso torna a versão auditável. Não torna todos os fatos atuais. lastUpdated se refere à alteração do mapa segundo sua fonte, não à última observação do chamador, à última resolução DNS, à última chamada aceita ou à capacidade atual do serviço.

expires estabelece outra borda. Pode ser uma data absoluta, NO-CACHE ou NO-EXPIRATION. Um servidor pode, em situação excepcional, devolver um mapa vencido numa resposta comum; cabe ao cliente examinar o campo e aplicar sua política.

O movimento acrescenta uma condição espacial. A entrada deixa de ser válida quando o aparelho sai da região, mesmo que o relógio ainda não tenha vencido. Por isso o registro precisa manter o instante da localização, lastUpdated, expires, a posição no reuso e o instante da tentativa de chamada.

NO-EXPIRATION não é uma promessa sobre a eternidade de uma instituição ou de um endpoint. É apenas o valor declarado para a validade daquela cartografia.

Uma referência de área exige uma segunda consulta

A fronteira pode vir incorporada ou como serviceBoundaryReference, formada por source e key. O cliente manifesta preferência, mas o servidor escolhe a forma. Ao receber referência, o cliente usa getServiceBoundary diretamente no servidor autorizado, sem recursão.

Há, portanto, dois fatos distintos: o mapa apontou para certa referência; uma consulta posterior obteve certo contorno. Sem a segunda etapa, o cliente não pode afirmar que comparou a localização com a fronteira. Sem a ligação entre chave, versão e horário, a geometria perde sua cadeia de custódia.

RFC 5582 descreve a arquitetura ampla. A fronteira oferece uma condição local para reaproveitar a resposta; ela não transfere ao servidor o poder de saber se o aparelho mudou de lugar depois.

O caminho LoST não é a rota da chamada

Na resolução recursiva, um servidor consulta outros em nome do cliente. Na iterativa, ele devolve um redirecionamento. path e seus elementos via mostram os participantes da resolução, facilitando detectar loops e localizar a origem de um aviso.

Esse caminho termina antes da sinalização do serviço. Também não comprova sozinho a descoberta DNS, a verificação TLS de cada identidade, a atualidade de todo cache ou a alcançabilidade do URI.

RFC 5223 define descoberta por DHCP. RFC 8917 reserva uma etiqueta para descobrir um serviço de validação. RFC 5069 apresenta ameaças à marcação e ao mapeamento de chamadas de emergência. Descoberta, autenticação de transporte, tradução e validação são controles complementares.

O RFC 5222 exige implementação de TLS, recomenda seu uso e a checagem da identidade do servidor. Assim se reduzem adulteração, personificação e envenenamento de cache. Uma sessão TLS correta protege bytes; não atualiza uma localização antiga nem obriga o destinatário a responder.

Um 200 OK pode carregar aviso, erro ou desvio

Todas as respostas LoST são transportadas em HTTP 2xx, normalmente 200, inclusive avisos e erros. O código HTTP atesta a troca de transporte. Para saber o resultado, é necessário interpretar o XML.

locationValidationUnavailable informa que a validação solicitada não pôde ser feita, embora haja um mapa. serviceSubstitution diz que o serviço pedido foi trocado. defaultMappingReturned diz que a localização não foi resolvida e que um URI padrão, talvez de um PSAP próximo, foi usado.

Uma rota padrão pode ser a melhor contingência. Seu valor depende de permanecer identificada como contingência. Se o aviso desaparecer, o sistema transforma uma resposta de último recurso em uma falsa precisão.

O registro de erratas congelado contém duas verificadas, uma reportada e duas retidas para atualização futura. O rótulo Standards Track não dispensa conhecer a versão normativa que o código realmente implementa.

Sincronizar mapas não executa chamadas

RFC 6739 cuida da troca de cartografias entre nós. Ele compara source/sourceId/lastUpdated, proíbe a alteração de mapas recebidos e exige assinatura da fonte autorizada para conter alegações indevidas de cobertura.

A assinatura melhora a origem e a integridade na distribuição. Não prova que um resolvedor específico já recebeu a edição nova, que a instalou ou escolheu, muito menos que o cliente alcançou o URI. A cadeia de sincronização termina onde começa a cadeia de consulta; a cadeia de chamada começa depois.

RFC 5031 define URNs para classes de serviço. RFC 5012 lista requisitos de resolução de contexto de emergência. RFC 6881 mostra que a chamada depende de práticas adicionais no aparelho e na rede. Nomear, mapear e atender são três verbos.

A frase correta precisa de todos os seus recibos

Guarde a origem e a idade da localização; o ID e o perfil escolhidos; a validação cívica; o URN; descoberta, DNS e TLS; recursão e redirecionamentos; a versão source/sourceId/lastUpdated; validade, cache e movimento; a fronteira; URI e avisos; a tentativa de sessão; aceitação e resultado.

Quando a evidência para no URI, a conclusão também deve parar: “o mapa devolveu este contato”. Acrescentar “e o serviço foi entregue” exige fatos produzidos por outros sistemas.

Sources

  1. RFC 5222
  2. RFC 5222 no Datatracker
  3. Status do RFC 5222
  4. Histórico do RFC 5222
  5. Erratas do 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