Resumo

  • O registro IANA coordena o nome e a referência de um parâmetro; phone-context declara escopo, mas nenhum deles prova acordo de configuração ou alcance.
  • Sintaxe, valor, capacidade, política, sinalização, identidade e resultado permanecem recibos independentes.

Escopo declarado não é escopo compartilhado

Um URI com número local inclui phone-context e passa na validação. O originador interpreta o contexto como um PBX; o receptor o configurou de outra forma. O identificador é estruturado, mas a resolução operacional diverge.

RFC 3966 exige contexto para números locais porque os dígitos não são globalmente únicos. O campo define a área em que devem ser interpretados. Não prova que duas partes escolheram o mesmo descritor corretamente, que o número pertence ao emissor ou que existe rota.

RFC 5341 registra o nome do parâmetro e aponta para essa regra. O registro impede que outro mecanismo reutilize phone-context silenciosamente com semântica incompatível. Ele não distribui configuração.

A linha IANA é um índice

Cada nova entrada informa nome, classe de valores e especificação pública. A semântica completa continua no documento. Constrained pede consulta às restrições; não é um selo de que qualquer valor recebido é válido.

No Value significa flag ou ausência de conjunto predefinido. enumdi e npdi ainda carregam afirmações de processamento. A falta de valor explícito não elimina validação de presença, procedência e contexto.

O registro prova coordenação do vocabulário. Não prova que o software suporta a extensão, que o valor é atual, que o remetente pode afirmá-lo ou que o próximo salto o aceitará.

O identificador não executa a chamada

RFC 3966 diferencia número canônico e sequência de discagem. O URI nomeia um recurso; terminal e rede decidem prefixos e sinalização. Ele também não escolhe voz, fax ou dados.

Portanto, conformidade do texto não é entrega. Depois da validação vêm capacidade, política, seleção de rota, estabelecimento de sinalização, negociação e resultado. Um dashboard que reduz tudo a “tel URI válido” perde o ponto da falha.

Parâmetro obrigatório desconhecido deve bloquear o uso

Um receptor que não entende extensão obrigatória não pode simplesmente ignorá-la e usar o URI. Isso separa o estado IANA da capacidade implantada. Equipamento antigo não aprende uma entrada quando ela aparece no registro.

Logs precisam mostrar parser, versão, reconhecimento, obrigatoriedade, validação e disposição. A linha registrada pode coexistir com rejeição correta. Pode também coexistir com aceitação incorreta por um componente permissivo.

RFC 5341 exige que o serviço base continue funcionando sem parâmetros. Transformar uma extensão em requisito absoluto é decisão de produto ou contrato, não autoridade herdada de IANA.

Portabilidade e trunk ainda precisam de prova operacional

rn, npdi, cic e contextos de RFC 4694 expressam dados de portabilidade. tgrp e trunk-context de RFC 4904 expressam seleção de grupo. Seus nomes registrados não provam atualidade, autorização, existência ou disponibilidade.

O mesmo vale para enumdi e isub-encoding. É preciso guardar quem inseriu, quando, sob qual fronteira de confiança, quem validou e qual decisão consumiu. Só então uma linguagem coordenada participa de um processo auditável.

O registro atual não apaga sua história

A tabela viva inclui adições posteriores ao RFC, como premium-rate e verstat. Sistemas precisam atualizar inventário. Investigações, porém, precisam usar o snapshot contemporâneo ao evento. Presença hoje não prova suporte ontem.

Congelar tabela, data e referência evita que um estado mutável seja transformado em fato eterno. A cronologia é parte do recibo de namespace.

Fontes e limite de evidência

As fontes comprovam normas, história e o snapshot IANA, não chamada atual, dono do número, identidade, produto, implantação, rota, preço ou resultado.