Resumo

  • O RFC 3017 organizou em XML os dados para escolher e configurar um ponto de presença: telefone, mídia, túnel, script, DNS, proxies, gateway e transformação do nome de usuário.
  • Os contadores crescentes ajudavam a detectar mudança dentro de uma linhagem conhecida. Eles não substituíam autenticação do emissor, protocolo de atualização, commit, rollback nem observação da chamada e do serviço.

O número no topo do arquivo havia passado de 41 para 73. Ainda assim, a conexão continuava usando a configuração anterior. Em outro cliente, a mesma atualização trocou o telefone e falhou antes da autenticação.

As duas situações cabiam no desenho do RFC 3017 porque “versão recebida” e “estado ativo” nunca foram a mesma coisa. Também não era seguro comparar qualquer 73 com qualquer 41. O consórcio podia produzir catálogos distintos para públicos diferentes; o usuário podia extrair só um país ou uma mídia. O nome do catálogo era uma string arbitrária.

Publicado em dezembro de 2000, o RFC tratava do roaming discado entre provedores. A meta era uma estrutura portátil, extensível e compacta, capaz de ser processada por dispositivos variados. Só que a estrutura levava mais do que um endereço. Ela podia fornecer ao software um dialScript, parâmetros de túnel, servidores e proxies, prefixo e sufixo de usuário e informação de preço.

O catálogo parecia descritivo. Para o discador, era entrada de controle.

O consórcio juntava afirmações, não medições simultâneas

Provedores contribuíam com seus POPs; o consórcio compilava uma versão unificada e a distribuía. RFC 2194 mostra o antecedente operacional: membros enviavam dados a um secretariado, que montava manualmente números e publicava atualizações por FTP, web e cliente. Havia também proxy, suporte, servidor e configuração de discador.

Esse caso não demonstra adoção do RFC 3017. Mostra que os dados percorriam várias custódias antes de chegar ao viajante. Um telefone podia estar correto na origem e desatualizado no catálogo; um registro podia sumir porque foi retirado, filtrado para outro público ou omitido na compilação.

XML uniforme simplificava o intercâmbio. Não eliminava a necessidade de saber quem afirmou o quê e quando.

A diferença tinha número, mas não tinha protocolo

phoneBook@version deveria aumentar sempre que o catálogo mudasse. O servidor podia comparar a versão do cliente e devolver, por exemplo, uma URL com diferenças.

O RFC não definiu as diferenças. Também não definiu transporte, vínculo com a base, aplicação atômica, confirmação, rollback ou exclusão. O texto declarou que protocolo de atualização ou transferência estava fora do escopo.

RFC 2477 deixa visível a parte ausente: um update precisava autenticar o servidor, levar qualquer versão anterior à mais recente, verificar integridade antes de aplicar, verificar o catálogo resultante, ser leve e respeitar idioma e charset.

Logo, um contador maior podia motivar uma ação, mas não provar o resultado. Não dizia se o cliente recebeu todos os bytes, se usou a base correta, se o catálogo final teve o digest esperado ou se o processo ativo abriu a nova cópia.

O entryVersion de POP tinha limite parecido. Podia ajudar a mesclar, mas pop não possuía XML ID; setup, support e provider possuíam. Uma troca de telefone ainda exigia identidade externa para saber se era o mesmo POP, substituição ou adição. Ausência ainda exigia semântica de remoção.

Contador sem identidade e transição era só uma pista.

Um DTD válido não testava o número

A maior parte dos campos era #PCDATA. Notações para FQDN, endereço IP e imagem comunicavam tipo pretendido, não veracidade operacional. Um número desligado continuava sendo texto válido. Um proxy inacessível podia passar. A taxa máxima anunciada não era a taxa daquela chamada.

O efeito não ficava na tela. O script podia dirigir a discagem; prefixo e sufixo podiam alterar automaticamente o usuário; setup podia definir DNS, mail, proxy e gateway. Informação errada podia mudar destino, identidade e caminho do tráfego.

As extensões também exigiam prudência. Novos elementos deveriam ser opcionais para preservar a validade de documentos antigos. Isso não significava que um cliente antigo entendia cada valor novo. Compatibilidade dependia de parser, conjunto implementado e política para o desconhecido.

Assinar o arquivo não mantinha o POP aberto

O RFC exigia autenticação confiável do emissor e integridade, mas deixou a segurança fora do DTD e citou assinatura PGP como possibilidade.

Uma assinatura verificada pode ligar bytes a uma chave conforme uma política. Não disca telefones, não mede tarifa, não confirma que o túnel ainda existe e não mostra qual edição o cliente ativou. Ela protege uma afirmação; não congela a realidade afirmada.

Depois da ligação vinha a identidade. No RFC 2486, o Network Access Identifier participava da autenticação PPP e do roteamento da solicitação ao domínio de origem. O link podia subir e o NAI falhar. A autenticação podia passar e a atribuição de endereço, túnel ou DNS falhar. Aplicação acessível era outra observação.

O sistema precisava de vários recibos, não de um rótulo “atualizado”.

DHCP podia oferecer outra configuração

O próprio RFC 3017 observava que alguns valores de setup poderiam chegar por DHCP. Se catálogo e DHCP entregassem DNS diferentes, a DTD não resolvia a precedência. A política do cliente decidia, e a telemetria precisava registrar o valor efetivamente usado.

Um diagnóstico sério guardaria emissor, nome e público do catálogo, digest, versão, POP, endereço, entryVersion, assinatura, parser, extensões, base, resultado do commit e digest ativo. Depois separaria discagem, portadora, PPP, NAI, autenticação, endereço, túnel, DNS, proxy e aplicação.

Só assim era possível distinguir catálogo velho, merge incorreto, telefone indisponível, identidade recusada e falha de serviço.

O padrão foi útil porque não fingiu ser tudo

RFC 3017 padronizou a forma comum e explicitou que o mecanismo de atualização ficava fora. Essa limitação não era ausência de rigor. Era uma fronteira de responsabilidade.

Running-Code Primacy, de Lu Heng, pede que configuração publicada encontre o sistema em execução. Reality Layers separa documento, emissor, estado instalado e resultado. Minimum Initial Specification ajuda a entender por que a forma compartilhada podia ser pequena e por que transição, compatibilidade e validação local ainda precisavam existir em outro lugar.

São lentes analíticas, não afirmações sobre participação de Lu Heng no RFC.

O catálogo tornou o roaming mais viável. Seu número maior dizia que alguém havia mudado o livro.

Quem dizia se o viajante estava conectado era a rede.

Fontes