Resumo

  • A RFC 3966 comparava URIs tel depois de desconsiderar separadores visuais, caixa e ordem textual dos parâmetros, mas preservava a forma local ou global, o contexto e cada nome de parâmetro.
  • Igualdade significava o mesmo recurso sob aquele contrato de identificação; não comprovava atribuição atual, alcançabilidade, rota, identidade humana, consentimento nem conclusão da chamada.

Uma agenda telefônica humana tolera muitas formas para o mesmo número. Os dígitos ganham grupos, parênteses e hífens para serem lidos. Um banco de dados que exige igualdade byte a byte transforma apresentação em identidade; um sistema que apaga tudo além dos dígitos pode unir espaços de numeração incompatíveis. Publicada em dezembro de 2004, a RFC 3966 resolveu o dilema declarando quais diferenças eram cosméticas e quais continuavam semânticas.

O tel URI era o nome de um recurso identificado por um número de telefone. Não dizia como obter uma linha externa, escolher um prefixo internacional, usar tons ou pulsos, interpretar sinais de progresso ou enviar dígitos posteriores. Essas ações pertenciam à configuração local. O URI tampouco prometia um aparelho físico: um número podia terminar em serviço fixo, móvel ou nômade e participar de voz, dados, fax ou outra modalidade.

Essa separação corrigiu o escopo da RFC 2806, que havia acolhido seleção de operadora, ações de contexto de discagem, formas de fax e modem, pausas e sequências posteriores. A RFC 3966 reteve a identidade e retirou a receita operacional. A história vizinha das strings telefônicas que carregam ações permanece na RFC 3601, não na relação de igualdade examinada aqui.

Uma equivalência feita de esquecimentos precisos

Ao comparar a parte numérica, a implementação removia , ., ( e ), os separadores visuais permitidos. A comparação não distinguia maiúsculas de minúsculas. Os parâmetros eram pareados por nome, sem depender da ordem em que tinham chegado. Assim, duas representações globais — ou duas representações locais — podiam ser equivalentes apesar de visualmente diferentes.

O apagamento parava na fronteira do significado. Uma representação global e outra local não se tornavam iguais só porque um operador sabia que ambas poderiam alcançar o mesmo destino. Se apenas uma delas continha determinado nome de parâmetro, o resultado era desigual. Para números locais, phone-context participava da identidade. Extensão, subendereço ISDN e parâmetros adicionais obrigatórios também participavam.

Havia ainda uma ordem de serialização preferida: isub ou ext primeiro, quando presente; depois phone-context; por fim os demais parâmetros em ordem lexical. Isso estabilizava saídas para sistemas que ainda faziam comparação textual. Mas a regra semântica comparava nomes independentemente da ordem recebida. Produzir um texto canônico e decidir equivalência eram controles relacionados, não sinônimos.

A RFC 3986 forneceu o enquadramento geral de URI. A RFC 3261, ao empregar sintaxe de assinante telefônico no SIP, mostrou por que sistemas ao redor ainda podiam ser sensíveis aos caracteres. Uma implementação auditável guarda o texto original, a estrutura analisada, cada transformação e a forma canônica em registros separados. O resultado normalizado não deve apagar a prova de entrada.

Contexto criava unicidade, não uma rota

A especificação preferia números globais, mas ramais privados, códigos de emergência e outros serviços locais nem sempre admitiam essa forma. Por isso um número local precisava de phone-context, expresso como domínio controlado ou como os dígitos iniciais de um número global válido. A combinação entre dígitos locais e contexto pretendia formar um identificador globalmente único.

O contexto não era um prefixo de discagem. Combinar 911 com phone-context=+1 não produzia +1-911. Um contexto em forma de domínio nem sequer precisava resolver para um host; precisava estar sob o controle administrativo de quem geria aquele espaço local. Portanto, igualdade de contexto não descobria gateway DNS, rota operacional, atribuição vigente ou autorização de uso.

Quem usava o URI apenas para identificar podia tratar o contexto como opaco. Quem pretendia efetuar a chamada precisava entendê-lo e conseguir operar dentro dele. A própria RFC observava que até um número global podia estar desatualizado ou ser inalcançável a partir de determinado lugar. Reconhecer um recurso e alcançá-lo exigiam evidências distintas.

Um conjunto igual podia continuar inutilizável

ext designava um ramal atrás de PBX não ISDN; isub, um subendereço ISDN. Eles não podiam coexistir no mesmo URI. Mais tarde, a RFC 4715 refinou a codificação de subendereços. As RFCs 4694, 4759 e 4904 registraram extensões ligadas a portabilidade, consulta ENUM e grupos de troncos.

Para extensões futuras obrigatórias, a RFC 3966 reservou o prefixo m-. Ao encontrar um parâmetro obrigatório desconhecido, uma implementação não podia usar o URI. Parâmetros opcionais desconhecidos podiam ser ignorados. Isso separava duas decisões: as estruturas correspondem? O receptor sabe agir sobre elas? Mesmo que ambos os textos tragam o mesmo m- desconhecido, a simetria não concede capacidade ao software.

A RFC 5341 criou depois o procedimento de registro de parâmetros, e o atual registro IANA de parâmetros tel URI publica o vocabulário coordenado. Um nome registrado é descobrível; seu valor não se torna automaticamente verdadeiro, atual, autorizado pelo emissor ou suportado pelo receptor. Igualdade, validade, capacidade e autoridade precisam de respostas separadas.

O recurso não era uma identidade humana

Durante o estabelecimento de uma chamada, o mesmo tel URI podia ser transformado em diversos outros URIs. A sinalização negociava o serviço; um ponto de terminação podia possuir vários identificadores; um número não precisava selecionar uma pessoa ou instrumento único. A RFC 6116 descreveu posteriormente a resolução ENUM de números E.164 para serviços e URIs. Ela acrescenta um recibo de consulta — registros retornados e instante — sem converter a igualdade da RFC 3966 em autenticação de quem atende.

As considerações de segurança reforçavam o limite. Um cliente web não devia iniciar uma chamada a partir de um link tel sem consentimento explícito. A ação podia custar dinheiro, ocupar linha, revelar informações do chamador ou servir a abuso. O texto visível do link podia exibir um número enquanto o alvo continha outro. Dois alvos equivalentes não garantiam exibição honesta, muito menos aprovação humana.

A página informativa do RFC Editor, a busca de erratas e o registro no IETF Datatracker documentam estado e correções reportadas. Não trazem taxa de adoção, incidente de colisão nem resultado de chamada. Para auditoria, conservam-se octetos e apresentação originais; forma local/global; dígitos antes e depois da remoção; mudanças de caixa; multiconjunto e ordem recebida de parâmetros; ordem canônica; tipo e controlador do contexto; extensão ou subendereço; reconhecimento de parâmetros obrigatórios; versão do analisador; regra e resultado da comparação. Evidência de atribuição, transformação de discagem, alvo de sinalização, rota, consentimento, resposta, pessoa que atende, serviço e custo ficam em recibos próprios.

O mérito da RFC 3966 foi tornar a comparação útil sem declarar invisível aquilo que carregava sentido. Sua lição mais durável é o limite inverso: o que o contrato não observou não pode ser incluído clandestinamente na palavra “mesmo”.

Fontes