Resumo

  • O RFC 1700 dizia ser uma fotografia de outubro de 1994, montada a partir dos arquivos de atribuições mantidos on-line. Em 2002, o RFC 3232 o classificou como Historic porque já era incompleto e às vezes incorreto.
  • Para sustentar um valor vigente, registre nome e URI do registro, momento da coleta, linha, estado, referências, política aplicável e uma cópia com hash. O RFC documenta a origem; a captura documenta o agora.

Há um tipo de erro que sobrevive justamente por parecer bem documentado. Um analista encontra uma tabela numerada, publicada como RFC, e a insere numa base moderna. A fonte é autêntica. A transcrição é fiel. Ainda assim, a conclusão pode estar errada porque falta a data a que aquela tabela pertence.

RFC 3232, de Joyce K. Reynolds, resolveu esse problema para Assigned Numbers. A série que antes publicava periodicamente as atribuições em RFC havia sido substituída pela base on-line no site da IANA. O RFC 1700 representava outubro de 1994; em 2002 seus valores estavam incompletos e alguns estavam errados. O documento passou, então, a Historic.

O gesto não apagou um arquivo. Ele encerrou a ambiguidade sobre qual artefato respondia pelo estado corrente.

O livro era uma exportação

Editado por Reynolds e Jon Postel, o RFC 1700 descrevia a si mesmo como instantâneo de um processo contínuo. As atribuições atuais eram mantidas em arquivos de texto on-line; o RFC surgia da concatenação desses arquivos, com elementos de formatação. Pedidos e correções continuavam sob coordenação da IANA, e Reynolds aparecia como contato.

No RFC 900, uma edição anterior, as marcas de mudança já estavam dentro das tabelas. Números antigos podiam permanecer visíveis durante uma transição, acompanhados de estado e referência. O catálogo era publicação e também vestígio de um fluxo operacional.

Transformar esse fluxo em RFC dava a uma edição um endereço estável. Mas cada atribuição realizada depois criava distância entre a edição e os arquivos mantidos. Uma nova linha apenas faltaria no volume; uma correção posterior tornaria uma linha antiga positivamente enganosa.

O RFC 3232 colocou cada fonte no seu tempo. Para saber o que foi publicado em 1994, consulta-se o RFC 1700. Para afirmar a alocação presente, captura-se o registro mantido. A primeira resposta não perde validade histórica só porque deixou de responder à segunda pergunta.

O procedimento acompanha o número

O registro on-line não é autoridade por ser uma página mais nova. Ele publica o resultado de uma divisão institucional de trabalho. O RFC 2860 estabelece que, para parâmetros no âmbito da IETF, a IANA atribui e registra segundo critérios e procedimentos definidos em RFCs. Dúvidas técnicas vão ao IESG; disputas podem chegar ao IAB.

O acordo também exige informação pública, gratuita e on-line sobre atribuições atuais, além de meios para solicitá-las. Uma linha visível é, portanto, o final de um caminho: regra, pedido, avaliação, ação de registro e publicação.

O RFC 8126 dá nomes às diferenças desse caminho. Um registro novo deve declarar nome, campos necessários, conteúdo inicial, controle de mudanças e política para futuras entradas. First Come First Served verifica principalmente forma e duplicidade. Expert Review exige avaliação por especialista designado. Specification Required, RFC Required, IETF Review e Standards Action estabelecem outros graus de documentação e aprovação.

Copiar só valor e descrição elimina a política, o estado, a referência e o controlador da mudança. Também pode fazer Reserved, Unassigned e Deprecated parecerem a mesma ausência. A tabela fica menor e a explicação de autoridade desaparece.

Todo “atual” precisa de horário

A IANA apresenta seus registros públicos como recursos autoritativos para manter identificadores globalmente coerentes. Em 10 de setembro de 2026, sua página também informa que as funções IANA são executadas pela Public Technical Identifiers, afiliada da ICANN. Essa é uma observação contemporânea e datada, não uma característica que se deva atribuir automaticamente a todas as épocas.

Uma URL estável também não congela conteúdo. Referências são acrescentadas, estados mudam e erros são corrigidos. Por isso, um dossiê deve registrar nome exato e URI do registro, horário com fuso, linha ou faixa selecionada, estado e referências exibidos, além do arquivo bruto com hash. Quando houver HTML e dados estruturados, vale preservar ambos.

A tabela normalizada deve apontar para o artefato capturado. Pedido, revisão de especialista, consenso, execução pela IANA e correção posterior entram como eventos separados. Ligá-los melhora a análise; fundi-los num campo “fonte” apaga ordem e responsabilidade.

Na coleta seguinte, uma diferença não autoriza sobrescrever a anterior. É preciso guardar as duas versões e classificar o que mudou: valor, estado, referência, política ou método do coletor. Só assim a mudança pode ser auditada.

A decisão editorial de Reynolds

O Internet Hall of Fame incluiu Reynolds postumamente em 2025. O perfil registra seu trabalho com Postel no Information Sciences Institute da USC e sua atuação posterior na liderança do RFC Editor. Ela morreu em 2015; esses dados comprovam contribuição histórica, não função ou opinião atual.

Reynolds conhecia por dentro a transformação de registros mutáveis em publicações duráveis. No RFC 3232, ela não escolheu entre preservar história e operar o presente. Definiu a evidência apropriada para cada tarefa.

Um recibo de pesquisa pode repetir esse desenho em três camadas: estado do registro capturado; política e trilha decisória; arquivo normativo e histórico. Cada camada recebe versão, data e identificador próprios. Mudança de política sem alteração de valor vira evento de governança; mudança de linha sem novo RFC vira evento operacional.

O benefício é poder atualizar uma conclusão sem reescrever o passado. Uma fonte viva deixa de fingir que é arquivo, e o arquivo deixa de servir como cópia de emergência do presente.

Fontes