Resumo

  • RFC 5385 documentou um modelo de Word capaz de produzir uma visualização muito próxima do ASCII de um RFC, embora o texto conforme ainda dependesse de estilos controlados, impressão em modo texto e pós-processamento Perl.
  • Em compras e governança, equivalência visual deve ser tratada como teste de renderização. Ela não identifica o artefato autorizado nem prova preservação semântica; a política atual da série RFC separa a versão definitiva RFCXML das versões publicadas em HTML, texto e PDF.

O requisito que costuma faltar no edital

O fornecedor abre o editor. Altera um parágrafo. A prévia se atualiza. O PDF exportado parece idêntico. A demonstração termina e a comissão marca “WYSIWYG” como atendido.

Faltaram perguntas mais importantes. Qual objeto contém o significado aprovado? Qual versão do modelo inseriu os campos? O que o conversor substituiu? É possível reproduzir o arquivo em outro ambiente? Se houver uma nova renderização daqui a cinco anos, a versão anterior continuará acessível?

RFC 5385 oferece um caso concreto para formular essas perguntas. Publicado em 2010 como contribuição independente e informativa, ele descreveu a versão 2.0 de um modelo Microsoft Word para Internet-Drafts e RFCs. O autor podia trabalhar visualmente, reorganizar o documento em modo de estrutura e obter impressão ou prévia linha a linha, página a página, semelhante ao ASCII conforme.

Mas a saída textual não era o arquivo aberto no editor. O procedimento criava um .prn por meio do driver Generic/Text Only e executava um programa Perl. O programa removia retornos de carro, convertia aspas e hífens, eliminava intervalos entre rodapé e cabeçalho, inseria form feed e detectava caracteres ilegais.

A demonstração visual provava uma boa projeção. Não provava a identidade entre fonte e saída, porque essa identidade nunca existiu. Havia uma transformação deliberada no meio.

Estilo é dado operacional

O modelo redefinia estilos internos do Word, como Normal e Heading1 a Heading9, e acrescentava estilos para figuras, listas, referências e apêndices. Usar outros estilos era desaconselhado de forma explícita.

O motivo era funcional. Os estilos internos permitiam promover e rebaixar seções no modo de estrutura, com renumeração. Uma linha grande e em negrito podia parecer um título sem possuir o comportamento de título. Para uma pessoa, a diferença era invisível; para o documento, determinante.

Em uma aquisição atual, o fornecedor precisa demonstrar exportação da estrutura, não apenas da imagem. Cabeçalhos devem continuar cabeçalhos, links devem ter destinos, tabelas precisam manter leitura coerente, imagens devem carregar descrição. Uma cópia visualmente perfeita pode ser inutilizável para acessibilidade, pesquisa ou migração.

O contrato de aceitação deve incluir a fonte semântica, versão do modelo, campos, recursos, estilos e avisos. Se o produto só entrega PDF e captura de tela, a organização comprou uma representação e alugou sua memória ao fornecedor.

O conversor também toma decisões

Normalizar aspas parece uma operação puramente técnica. No entanto, qualquer conversão de conjunto de caracteres escolhe o que preservar, aproximar, rejeitar ou apagar. O mesmo vale para remover conteúdo interpretado como cabeçalho ou rodapé.

O pós-processador de RFC 5385 estava publicado no apêndice, o que tornava suas decisões inspecionáveis. Ainda assim, uma execução auditável exigia registrar a cópia utilizada, entrada, ambiente, mensagens e código de saída. O texto do RFC não era um comprovante automático de cada execução.

Sistemas modernos devem entregar isso por padrão. Hash da fonte aprovada. Identidade do modelo e do gerador. Configuração. Logs. Hash de cada saída. Relatório que compare títulos, referências, termos normativos, links, texto alternativo e normalização Unicode.

Reprodutibilidade não significa necessariamente bytes idênticos quando há datas ou identificadores dinâmicos. Significa conseguir explicar cada diferença e provar que o significado controlado permanece. Um fornecedor que responde “nosso serviço sempre gera o documento correto” oferece confiança, não evidência.

O nome do modelo não congelava o modelo

A seção de segurança de RFC 5385 afirma que o modelo não continha macros na forma desenvolvida e distribuída. Também relata a ideia de incluir somas MD5 do .dot e do .pl. O modelo, porém, mudava para acompanhar boilerplate atualizado; por isso sua soma vigente ficava no local de distribuição, não congelada no RFC.

MD5 é um detalhe histórico, não uma recomendação presente. A questão de controle permanece: o documento explicativo era estável, mas o ativo executável tinha versões. A expressão “modelo de RFC 5385” não bastava para provar qual conteúdo foi usado.

Em contratos, relatórios e formulários de conformidade, modelos com nome fixo são alterados o tempo todo. Sem uma referência imutável, duas partes acreditam ter aplicado o mesmo padrão e descobrem cláusulas diferentes.

Exija versão, hash, data de vigência, responsável e changelog. Grave essa identidade dentro do recibo de produção. E revise o texto expandido: um modelo aprovado pode falhar ao inserir um campo ou carregar uma configuração errada.

Uma referência podia desaparecer depois de uma edição comum

RFC 5385 mudou a forma de manter referências. No sistema anterior de notas finais, a primeira citação definia a referência; apagá-la podia eliminar a nota mesmo com outras remissões. O modelo novo usava parágrafos numerados no corpo e permitia rótulos por marcadores.

Antes da exclusão, as páginas podiam ter aparência equivalente. Depois, os comportamentos divergiam. Uma prova estática não revelava a fragilidade.

O ensaio de aceitação deve manipular o documento. Mover seções, excluir a primeira citação, trocar figura, inserir apêndice, regenerar sumário e exportar todos os formatos. Sistemas são confiáveis quando suas propriedades sobrevivem a mudanças normais e casos de borda, não quando uma amostra cuidadosamente preparada parece correta.

A arquitetura moderna separa significado e distribuição

RFC 6949 registrou necessidades que o ASCII sozinho já não atendia. RFC 7990 propôs um novo marco. RFC 9720, publicado em 2025 e substituto de RFC 7990, refinou o vocabulário.

RFCXML é o formato definitivo. Um RFC publicado nele é a versão definitiva. HTML, texto simples e PDF são formatos de publicação; os arquivos correspondentes são versões de publicação. A versão definitiva guarda toda a informação pretendida e responde a dúvidas sobre o significado publicado.

Não se deve chamar o Word de 2010 de versão definitiva com base nessa política posterior. A comparação útil é de arquitetura: RFC 5385 tornou visível a separação entre oficina, transformação e saída; RFC 9720 definiu formalmente a autoridade entre fonte semântica e representações.

O mesmo desenho deve constar em contratos de tecnologia. A organização precisa declarar se a autoridade reside no banco, em um documento estruturado, em uma assinatura ou em outro artefato. PDF e HTML podem ser cópias oficiais, mas a regra de conflito deve apontar para um nível único.

Atualizar a apresentação sem apagar a história

RFC 9720 permite republicar versões definitivas e de publicação por razões limitadas, com preservação máxima do significado, registro do motivo e arquivo das versões anteriores. A política reconhece que ferramentas mudam e que a regeneração pode introduzir alterações involuntárias.

Essa é uma cláusula essencial de saída de fornecedor. Se um produto novo precisar reconstruir o acervo, a empresa deve manter fontes, versões antigas, ferramentas ou especificações suficientes, hashes e comparação semântica. Substituir todos os PDFs e manter apenas os mais novos não é migração controlada; é perda de evidência.

RFC 9920 ainda separa formulação e aprovação de política da implementação pelo RFC Production Center, atribuindo responsabilidade pelas ferramentas. Operar o gerador não concede autoridade para mudar conteúdo. Aprovar conteúdo não autoriza ignorar controles de geração.

Critérios de compra que resistem à migração

Peça uma fonte semântica exportável, modelos versionados, geração repetível, logs, hashes, validação estrutural e arquivo de versões. Inclua um documento de teste com nomes não ASCII, links, referências, figura com descrição, tabela, código e pressão de paginação.

Gere todas as saídas em dois ambientes. Compare aparência e estrutura. Altere apenas um elemento semântico e verifique sua propagação. Altere apenas uma regra visual e comprove estabilidade do conteúdo. Simule uma republicação e recupere a versão antiga.

Por fim, entregue o material a uma equipe que não participou da demonstração. Ela deve identificar o artefato autorizado e reconstruir cada cópia. Se depender do fornecedor para explicar qual arquivo “vale”, a dependência já virou governança.

Fontes