Resumo

  • RFC 3939 definiu Caller-ID e Caller-Name para guardar o que a rede telefônica apresentou ao destinatário de uma mensagem de voz, não para autenticar o chamador.
  • O contexto podia desaparecer: um ramal encaminhado deixava de ser discável e expunha o plano interno; um número internacional truncado podia virar outro destino plausível.

O remetente que não tinha endereço

No correio de voz de atendimento, a gravação chegava a um armazenamento de Internet Mail sem que o chamador tivesse endereço RFC 2822 conhecido. RFC 3801 já previa non-mail-user quando uma resposta por e-mail não era possível. Usar From para acomodar o telefone, porém, exigia fabricar uma identidade de correio.

Publicado em dezembro de 2004, RFC 3939 separou as proveniências. Caller-ID continha o número fornecido pelo sistema telefônico; Caller-Name, o nome apresentado. A escolha dizia de onde veio o dado, não quem era a pessoa. Não provava posse da linha, intenção, autorização ou sucesso de uma ligação posterior.

Dígitos sem plano continuavam desconhecidos

O campo aceitava apenas dígitos. Um ramal bastava para uma chamada interna; uma chamada internacional deveria registrar a sequência E.164 completa, sem +, até quinze algarismos. O parâmetro opcional NumberingPlan distinguia unknown, local e e164. Sua ausência significava unknown.

local valia somente no domínio do sistema que armazenou a mensagem. Por isso o próprio RFC recusava chamar o valor de endereço discável. RFC 2806 exigia contexto para números locais em URLs de telefone; RFC 3191 reservava + para um endereço GSTN global no e-mail. O cabeçalho de RFC 3939 era uma captura anterior ao roteamento.

Corrupção convincente

Alguns sistemas truncavam números internacionais para dez dígitos. O exemplo do RFC mostrava um número irlandês que, sem os primeiros algarismos, parecia norte-americano. Não era um erro obviamente inválido: o retorno podia completar para a pessoa errada. Uma regra que aceitasse “dez dígitos” confirmaria justamente a transformação indevida.

O encaminhamento de um ramal interno expunha outro limite. Fora da empresa, o número curto não levava ao autor, mas revelava parte da discagem privada. A entrega do e-mail podia ser perfeita enquanto a utilidade e a confidencialidade falhavam juntas.

O nome também dependia do meio. Redes telefônicas usavam conjuntos de caracteres diferentes; ASCII era a base e RFC 2047 permitia codificar o nome nativo. Um receptor incompatível podia mostrá-lo errado, e provedores podiam reduzi-lo a quinze caracteres.

Para números restritos, o campo devia guardar apenas o que o chamado veria, como Private Name, não detalhes ocultos entre operadoras. Mas no correio essa informação podia persistir e ser encaminhada. Se o cliente não exibisse o cabeçalho, o usuário talvez nem soubesse que um telefone estava armazenado.

Até o horário tinha duas fontes possíveis: o relógio do sistema telefônico ou o relógio local do armazenamento. Sem proveniência, Date não era prova automática do instante exato da chamada.

RFC 3939 resolveu um problema de modelagem sem prometer resolver identidade. Sua lição histórica é que interoperabilidade de formato não equivale a interoperabilidade de significado. Para agir sobre um dado, é preciso transportar também o âmbito que autorizava sua interpretação.