Resumo

  • Verified informa que a correção foi examinada e considerada precisa. Mesmo assim, o RFC Editor não a incorpora às versões TXT, PDF ou XML comuns do RFC.
  • A via de erratas trata de erros existentes na publicação. Ideias novas, preferências posteriores ou mudanças do consenso precisam voltar ao processo técnico e, quando cabível, gerar outro RFC.

A correção permanece ao lado do documento

Uma equipe encontra duas instruções incompatíveis em um RFC. A página de erratas exibe o trecho original, uma redação corrigida, a data e o estado Verified. Seguir a correção pode ser essencial para interoperar. Fingir que ela sempre esteve no corpo do RFC elimina a origem da decisão.

O RFC registra o texto que atravessou revisão, aprovação e produção em determinado momento. A errata registra um julgamento posterior e limitado sobre um defeito daquele texto. Um documento mostra o acordo; o outro mostra a correção. A engenharia precisa de ambos.

O RFC Editor faz a ligação sem ocultar a emenda. A errata verificada aparece junto ao RFC, mas não entra nas edições normais em TXT, PDF ou XML. O leitor enxerga que houve uma decisão posterior.

Essa separação evita que a equipe responsável pela publicação adquira autoridade sobre o significado do protocolo apenas porque opera o banco de correções.

Cada estado produz um efeito próprio

Reported confirma somente o recebimento de uma alegação. Ela ainda pode estar certa, errada, incompleta ou tentar reabrir uma controvérsia ampla. Um produto não deveria aplicá-la automaticamente.

Verified significa que o relato é válido pelos critérios do fluxo e deve estar disponível a implementadores e operadores. É o estado mais forte, mas corrige o erro dentro da intenção original; não redesenha o protocolo.

Rejected encerra o pedido nessa via. Às vezes o relato é inválido. Em outros casos, a mudança é significativa e precisa de um RFC que atualize ou substitua o anterior.

Held for Document Update conserva uma questão que não exige alteração necessária no RFC atual. Uma revisão futura pode avaliá-la. O estado não cria obrigação imediata nem aprova antecipadamente uma nova regra.

Reunir os quatro estados num campo único de “texto corrigido” apaga a diferença entre alegação, validação, rejeição e memória para o futuro.

A autoridade de verificação segue o fluxo

A RFC Series contém fluxos IETF, IAB, IRTF, Independent Submission e Editorial. Cada um tem finalidade e autoridade de conteúdo próprias. A parte que verifica uma errata depende da origem do RFC.

No fluxo IETF, erratas técnicas são encaminhadas a autores, presidências do grupo de trabalho e Area Directors. Os Area Directors respondem pelo processamento, embora possam delegar a análise. Questões editoriais claras começam no RFC Editor e sobem quando o sentido técnico está em jogo.

O desenho separa competência editorial de competência normativa. Manter arquivos e formatos não autoriza alterar políticas de protocolo. Conhecimento técnico também não autoriza apagar a trilha pública da correção.

Uma auditoria deve, portanto, registrar quem verificou, em qual fluxo, quando e com qual justificativa. O rótulo Verified sozinho não contém a cadeia de autoridade.

A intenção aprovada é o limite

A declaração ativa da IESG de 2021 restringe erratas a erros que já existiam quando o documento foi publicado. Conhecimento novo, capacidade posterior e discordância do resultado aprovado pertencem a grupos de trabalho, debates de área ou à própria IESG.

Uma solução técnica clara, alinhada à intenção original, pode ser Verified. Se a solução exige discussão, deve ficar Held. Uma alteração que faça o protocolo operar de modo diferente do consenso deve em geral ser Rejected. O mesmo limite se aplica a mudanças de processo, como um procedimento de registro IANA.

Poucos caracteres podem carregar grande poder. Trocar um verbo normativo, inverter um padrão ou ampliar uma faixa de códigos muda interoperabilidade e distribuição de risco. O verificador precisa examinar discussão do grupo, Last Call, posições da IESG, algoritmo completo e evidência de implementação.

Se o registro não demonstra uma correção única, preservar a incerteza é mais responsável do que produzir certeza artificial.

Reemitir a publicação não muda o sentido

RFC 9720 permite reemitir a versão definitiva em RFCXML e seus formatos derivados por razões controladas, como evolução do esquema, erros de XML e mudanças nas ferramentas. Versões anteriores devem continuar arquivadas; data e razão da reemissão precisam ser públicas.

RFC 9920, publicado em fevereiro de 2026 e substituto do RFC 9280, mantém estabilidade entre as propriedades históricas da série. Reconhece a reemissão para apresentação consistente, mas preserva o conteúdo semântico como exigência central.

Corrigir uma figura cortada ou um caractere mal renderizado é manutenção de publicação. Validar uma falha textual é correção vinculada. Alterar o comportamento pretendido requer uma nova decisão normativa. São atos distintos.

Essa fronteira permite descobrir, num incidente, se duas equipes aplicaram significados diferentes ou apenas consultaram formatos diferentes do mesmo significado.

Uma referência reproduzível tem data

“Conforme ao RFC 1234” não basta. O dossiê deveria indicar a versão consultada, os RFCs que a atualizam ou tornam obsoleta, a data da consulta das erratas e quais itens Verified foram adotados.

Testes devem ligar cada correção a comportamento observável. Se pares ainda seguem o trecho original, notas de versão precisam explicar compatibilidade. Uma falha de segurança pode exigir mitigação imediata mesmo sem mudança do arquivo histórico.

Itens Held podem orientar uma futura revisão sem virar falhas automáticas de conformidade. Itens Rejected mostram que uma leitura foi considerada e não recebeu autoridade de correção.

Essa disciplina não declara o arquivo infalível nem concede poder legislativo ao administrador de erratas. O conjunto operacional evolui, mas cada camada continua identificável.

O registro comum mínimo

Heng Lu propõe um núcleo comum estreito, decisões futuras localizadas em atores competentes e adoção voluntária testada por código em operação. A governança de erratas funciona assim quando não excede seus predicados.

O registro pode afirmar RFC, seção, passagem original, proposta, tipo, estado, verificador, datas e motivo. Não prova que todos os fornecedores implantaram a correção, que Held é obrigatório ou que o silêncio de um grupo encerrado equivale a aprovação.

Separar essas afirmações fortalece a legitimidade. A errata vale por dizer exatamente qual defeito foi julgado e até onde alcança o julgamento, sem alegar que o passado foi apagado.

Fontes