Resumo

  • RFC 5139 substitui a forma cívica inicial de PIDF-LO por um XML mais rico, alinhado aos tipos de endereço de RFC 4776.
  • A hierarquia de via, seção, ramal e sub-ramal preserva diferenças locais que uma linha única apaga.
  • Validade de esquema comprova representação, não presença atual de pessoa ou dispositivo.
  • Blocos em idiomas diferentes devem permanecer separados; preferência linguística não resolve contradição factual.
  • O tipo XML token colapsa espaços, criando uma fronteira entre documento bruto e valor consumido.
  • Uma localização composta requer fonte, instante e método comuns.
  • Um cadastro antigo pode ser mais detalhado que uma medição nova; completude não é atualidade.
  • Assinatura confirma a origem da declaração, não a veracidade física do endereço.
  • Prédio, sala ou assento refinam uma região de incerteza, sem provar ocupação.
  • Política de uso controla destinatário, finalidade, precisão, retenção e retransmissão.
  • LoST e SIP produzem recibos de validação e encaminhamento, não de despacho e chegada.
  • A governança deve impedir que “válido” substitua desconhecido, antigo, conflitante, reduzido ou não verificado.

O relógio ausente no cadastro perfeito

RFC 5139 corrige uma limitação concreta de RFC 4119. Endereços cívicos variam muito entre países, e o conjunto inicial não comportava todas as distinções. A revisão incorpora prédio, unidade, sala, assento, comunidade postal e códigos adicionais, além de RD, RDSEC, RDBR e RDSUBBR.

O número da porta pertence ao elemento viário mais específico presente. Qualificadores da via principal não devem migrar implicitamente para um ramal. A6 pode continuar atendendo estruturas administrativas locais, mas deixa de funcionar como campo improvisado de rua.

Essa precisão é semântica, não probatória. Um número errado continua válido no elemento certo. O código de país em duas letras limita a forma, mas não observa o alvo. O registro IANA define o que um CAtype significa; não certifica o conteúdo de uma instância.

O recibo deve reter ordem, perfil nacional, versão do esquema e extensões compreendidas. Um geocodificador precisa expor candidatos, normalizações e versão da base. Uma resposta única pode ser apenas o resultado de uma base incompleta.

Idioma organiza a leitura, não a realidade

Elementos linguísticos aceitam xml:lang; país e tipo de lugar permanecem neutros segundo seus registros. A escrita pode aparecer no subtipo do idioma. Cada civicAddress deve usar uma língua ou combinação coerente, com versões paralelas em blocos distintos no mesmo tuple.

No formato DHCP, o mesmo elemento pode aparecer mais de uma vez em idiomas diferentes. Na forma XML, a conversão cria um bloco por idioma. Preferências do receptor podem escolher valores, mas empate, ausência de preferência e conflito no mesmo idioma admitem escolha arbitrária.

Arbitrário mantém a interoperabilidade; não estabelece verdade. Guardar apenas a forma escolhida destrói o sinal de conflito. Preservar todos os valores, tags, pesos e motivo da seleção permite revisão posterior.

RFC 5646 padroniza a etiqueta de idioma e escrita. A equivalência entre nomes depende de autoridade local ou vínculo verificado, não da aparência semelhante.

A cadeia de transformação começa no parser

Os valores usam XML Schema token; espaços comuns são normalizados e colapsados. O XML recebido, a árvore processada e a string gravada podem divergir. Uma assinatura sobre os bytes não descreve automaticamente o valor comparado pela aplicação.

O esquema também aceita elementos de outros namespaces e atributos livres. Dois consumidores podem validar o mesmo arquivo e entender extensões diferentes. Sistemas críticos devem guardar original, versões do parser e esquema, valores resultantes, extensões desconhecidas, avisos e perdas.

“Válido” sem explicar transformações é um recibo incompleto. O mesmo vale para limpeza posterior, transliteração ou achatamento de campos.

Fonte, método e tempo dão autoridade à localização

RFC 5491 separa alvo, fonte, método de determinação e protocolo de entrega. Um aparelho pode representar uma pessoa, mas essa relação precisa ser declarada. Entrada manual, DHCP, servidor de localização e diretório corporativo têm autoridades e prazos diferentes.

Dados cívicos e geodésicos só formam uma localização composta confiável quando compartilham fonte, tempo e método. Juntar sala antiga de um cadastro com área de rede recém-observada produz uma precisão fictícia.

O registro deve ligar alvo, fonte, método, interface, hora da observação, emissão e expiração. RFC 7378 delimita o papel da autenticação: ela atribui a afirmação a uma fonte, mas uma fonte autêntica pode errar ou descrever outro objeto.

Campo preenchido não autoriza a palavra “atual”. Só uma observação ainda válida pode fazê-lo.

Precisão não elimina incerteza

RFC 7459 trata localização como estimativa. Em endereço cívico, o componente confiável mais específico sugere a área de incerteza. Uma sala reduz a área em relação ao prédio, mas continua sendo área; um assento identificado não comprova presença.

Detalhe ausente pode ser desconhecido, desnecessário ou retirado por privacidade. Incerteza não informada nunca significa incerteza zero. Granularidade, confiança e idade são medidas diferentes.

Geocodificação adiciona escolhas: centróide, entrada, lote, cobertura ou candidatos múltiplos. As coordenadas derivadas devem permanecer ligadas ao endereço, à base, aos candidatos e ao critério de escolha.

RFC 4589 e o registro IANA estabilizam vocabulário; RFC 6848 controla extensões. Nenhum deles confirma a exatidão da instância recebida.

Privacidade pode remover o campo correto

PIDF-LO combina localização e regras de uso. RFC 6280 separa alvo, formulador de regras, servidor e destinatário. RFC 6772 permite reduzir precisão conforme a política. Receber cidade sem sala pode demonstrar proteção correta.

Recompor o campo oculto a partir de outro cadastro contorna a decisão. Autorização precisa cobrir destinatário, finalidade, precisão, retenção, retransmissão e revogação. O país descrito no endereço não indica país de armazenamento ou jurisdição de processamento.

Depois que uma posição detalhada se espalha por chamados, análise e backup, a retirada se torna incerta. Minimizar antes da divulgação é a proteção durável.

Mapear o serviço ainda não é chegar ao local

LoST valida localização e associa serviço mais local a uma URI. SIP transporta ou referencia o objeto. Os recibos devem registrar pedido, alertas, política, limite, URI, validade e entrega.

Mapeamento correto não prova que o alvo está no endereço. Entrega SIP não prova atendimento, interpretação, despacho ou chegada. Cada estágio tem autoridade e falhas próprias.

Testes devem separar endereço completo e antigo, observação recente e ampla, idiomas conflitantes, ramais homônimos, detalhe oculto, múltiplos candidatos, destinatário não autorizado, mapeamento expirado e falha operacional depois de um mapeamento correto.

RFC 5139 melhora a descrição compartilhada. Seu limite é parte da sua qualidade: representar um endereço não é testemunhar presença.

Fontes

  1. RFC 5139, HTML
  2. RFC 5139, texto
  3. Registro RFC Editor
  4. IETF Datatracker
  5. Histórico de RFC 5139
  6. Erratas de RFC 5139
  7. RFC 4119: PIDF-LO
  8. RFC 4776: endereço cívico por DHCP
  9. RFC 5491: uso de PIDF-LO
  10. RFC 7459: incerteza e confiança
  11. RFC 7378: localização confiável
  12. RFC 6280: arquitetura de localização e privacidade
  13. RFC 5222: LoST
  14. RFC 6442: localização em SIP
  15. RFC 6772: política de geolocalização
  16. RFC 6848: extensões cívicas
  17. RFC 5646: tags de idioma
  18. RFC 4589: tipos de lugar
  19. Registro IANA de tipos cívicos
  20. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  21. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  22. Running-Code Primary