Resumo

  • Obsoletes é autoridade sobre a linhagem dos documentos: o novo RFC vira a referência geral para a especificação ou prática atual, e o antigo continua no arquivo permanente.
  • A relação não corrige binários, desliga funções, retira produtos nem cria proibição legal. Cada efeito depende de outro ator e de outra prova.
  • HTTP/2 preservou a identidade h2 enquanto trocava o texto de referência; TLS mostrou que versões formalmente desaconselhadas podem permanecer em operação e impor uma escolha real entre segurança e interoperabilidade.
  • Uma migração só termina com um recibo que reúna linhagem normativa, versão carregada, dependências, testes, dono da exceção, condição de retorno e telemetria da retirada.

O registro mudou antes da máquina

O cabeçalho do RFC 9113 informa que ele torna obsoletos os RFCs 7540 e 8740. Isso tem consequências reais. Quem estuda HTTP/2 hoje deve começar pelo texto novo. O RFC Editor liga o documento anterior ao sucessor. A IANA atualiza referências determinadas. Uma implementação que declara conformidade com o RFC 9113 precisa incorporar as mudanças.

Nada disso abre uma sessão administrativa em um servidor. Uma biblioteca distribuída não adquire novas regras, um proxy não perde uma opção e um equipamento gerenciado não instala firmware por causa da publicação. O evento normativo é válido; seu primeiro objeto é o registro documental.

A fronteira protege a credibilidade do IETF. Cabe ao processo técnico declarar a especificação vigente. Cabe ao RFC Editor preservar o arquivo e as relações. Cabe à IANA manter registros precisos. Nenhuma dessas funções precisa fingir controle sobre máquinas de terceiros.

A confusão é conveniente porque atualizar uma planilha custa pouco. Descobrir clientes antigos, dispositivos embarcados, intermediários e parceiros custa muito. Se a troca do número puder ser relatada como adoção concluída, a organização ganha um indicador verde antes de conhecer a própria infraestrutura.

O catálogo deve orientar a pergunta. Não pode responder em nome do sistema em execução.

Substituir sem apagar

O RFC Editor explica que o texto publicado de um RFC nunca muda. Revisões e substituições recebem números novos. Obsoletes significa que o documento recente substitui os listados como ponto de partida geral para compreender a especificação ou prática vigente. Os textos anteriores permanecem no arquivo permanente.

Essa permanência preserva evidência. Ela permite reconstruir a regra que um produto tentou implementar, comparar duas épocas e atribuir uma divergência ao documento correto. Apagar o texto antigo deixaria a lista mais limpa e a investigação mais fraca.

O RFC 7322 coloca Updates e Obsoletes no cabeçalho e reconhece que um RFC obsoleto ainda pode precisar ser citado junto com o mais recente. Uma série imutável evolui por relações explícitas, não por reescrita silenciosa.

Por isso a linha não é decorativa. Quem afirma conformidade com o RFC novo não pode selecionar apenas trechos convenientes do antigo. Mas a autoridade direta termina na linhagem. Ela não prova que uma correção foi carregada, uma configuração desligada, um produto abandonado ou uma obrigação jurídica criada.

Seis decisões escondidas em “obsoleto”

A primeira é a substituição documental: o processo estabelece a referência nova e preserva a antiga.

A segunda é a mudança de status ou aplicabilidade: uma especificação pode virar Historic; uma Best Current Practice pode elevar requisitos; uma regra pode valer apenas para protocolos novos.

A terceira é a descontinuação de uma função: o protocolo pode conservar nome e grande parte do comportamento enquanto remove um caminho específico.

A quarta é a mudança de implementação: mantenedores alteram código, publicam versões e escolhem ramificações suportadas. Código disponível não é código carregado.

A quinta é a decisão de implantação: o operador inventaria, testa, configura, observa falhas e limita exceções. É ali que alguém aceita a interrupção ou o risco de esperar.

A sexta é a restrição externa: contrato, comprador, seguradora, regulador ou tribunal pode exigir a retirada com base própria. O mandato não nasce do cabeçalho do RFC.

Uma decisão pode provocar outra, mas não a incorpora. A publicação pode motivar um release; isso não significa que o editor da norma o instalou. E o operador não pode usar a fronteira como desculpa para ignorar requisitos enquanto declara conformidade. A norma define comportamento comum; não executa a mudança local.

HTTP/2 continuou sendo h2

O RFC 9113 traz mudanças substanciais. Ele incorpora o tratamento de TLS 1.3 antes separado no RFC 8740, ajusta validação, prioridade, atualização em texto claro e a relação entre Host e :authority. O Apêndice B documenta diferenças reais.

Ao mesmo tempo, o identificador ALPN continua h2. Os registros de quadros, configurações e erros permanecem. A IANA altera referências, mas não cria outra identidade para o HTTP/2 revisado. Os pares negociam capacidade no fio, não o número do texto.

Alguns mecanismos recebem destino específico. O campo HTTP2-Settings e o token h2c são marcados obsoletos. A prioridade do RFC 7540 é desaconselhada. Ainda assim, o RFC 9113 remete ao texto antigo para explicar aquela semântica histórica.

O documento substituído deixou de ser a referência geral, mas continua útil para interpretar comportamento legado. O arquivo guarda memória; o RFC atual aponta direção; mantenedores e operadores decidem quando a direção chega à produção.

Uma matriz que diga “RFC 9113 adotado” não revela se o proxy rejeita o caminho retirado, se a biblioteca emite sinais antigos ou se o firmware foi instalado. É preciso observar a máquina.

TLS e a coexistência que o texto reconhece

O RFC 8446 especifica TLS 1.3 e torna obsoleto o RFC 5246 de TLS 1.2. Mesmo assim, seu apêndice discute negociação com servidores e clientes antigos, implantação gradual em grupos mistos e falhas de intermediários.

Os autores não esperaram que o cabeçalho eliminasse a base instalada. Projetaram uma transição que pudesse encontrá-la.

O RFC 8996 toma medida mais forte contra TLS 1.0 e 1.1. Ele os desaconselha formalmente, move os documentos para Historic e diz que implementações não devem negociá-los. É uma conclusão de segurança clara.

Ainda assim, as considerações operacionais reconhecem sistemas incapazes de usar TLS 1.2 ou superior. Cumprir a recomendação pode romper interoperabilidade; ignorá-la mantém risco. A velocidade depende desses danos, das medidas compensatórias e do risco da atualização.

Isso não autoriza uma exceção perpétua. O IETF fixa a prática atual. O proprietário encontra a dependência, substitui ou isola, aceita a ruptura quando necessário e prova que a versão antiga deixou de ser negociada.

O RFC 9325 mantém orientações distintas para TLS 1.2 e 1.3 e proíbe retorno às versões depreciadas. O RFC 9852 eleva o piso para protocolos novos. A prática vigente é um grafo de escopo e atualizações, não apenas o maior número.

Norma não é processo com acesso de administrador

MUST NOT tem força dentro do escopo da especificação. Define o que uma implementação conforme não pode fazer e fornece base para teste e aquisição.

Mas não é um serviço com privilégios universais. O mantenedor codifica, o fornecedor entrega, o operador carrega, o parceiro suporta e o auditor testa. A autoridade normativa define o comportamento conforme; a autoridade de execução controla o equipamento e responde pela indisponibilidade.

Misturar as duas elimina responsabilidade. “O RFC exigiu” não identifica quem escolheu a data ou aprovou a exceção. “Já estava obsoleto” não identifica quem deixou a função ativa. Cada elo precisa de dono e evidência.

A base instalada não é veto permanente

O RFC 2026 admite que versões antiga e nova possam continuar como Internet Standards para atender uma base instalada, desde que a relação seja explícita. A interoperabilidade acontece entre sistemas reais, e não apenas entre parágrafos.

Mas a base instalada também pode virar desculpa. Uma dependência nunca medida é chamada crítica; poucos clientes antigos mantêm superfície de ataque para todos; uma exceção perde dono e prazo.

O ônus muda com o tempo. Primeiro, quem propõe retirar demonstra alternativa e modos de falha. Depois que existem versões suportadas, experiência e evidência de risco, quem conserva a exceção deve provar necessidade, isolamento e data final.

Inventário mostra onde a capacidade pode existir. Telemetria mostra onde ela é usada. Testes revelam o que quebra. Versão carregada mostra qual código atende tráfego. O cabeçalho dispara a investigação, mas não substitui nenhuma dessas provas.

O recibo de uma retirada verdadeira

Registre a linhagem: RFC novo, relações, BCPs posteriores e comportamento exato. Registre o estado carregado: versão, build, firmware e configuração reais. Registre dependências e declare pontos cegos.

Separe risco e autoridade: motivo, responsável e origem do prazo. Defina teste e retorno com grupos, falha esperada, limiar de parada e duração. Um retorno que reabre risco exige nova decisão.

Toda exceção precisa de sistema, dono, controle compensatório, vencimento e gatilho de revisão. A conclusão requer evidência de retirada: o comportamento não é mais negociado, alertas não foram apenas ocultados e o sucessor sustenta o serviço.

As duas mentiras do catálogo

A primeira é o cumprimento automático. O RFC mudou e o risco some do relatório antes de sumir do fio. A segunda é a opcionalidade eterna. Como o documento não altera a máquina, todo requisito vira opinião e toda compatibilidade perde prazo.

A posição responsável mantém duas autoridades. A relação RFC prova qual é a referência documental atual. O sistema ativo prova o que está implantado. Entre ambos deve haver decisão atribuível, limitada e testada.

Quando “obsoleto” aparecer, pergunte: que regra mudou, que comportamento ainda é possível, quem controla o equipamento e que medida provaria a retirada?

O RFC Editor preserva a história. O IETF define a linha técnica. A IANA mantém referências. Desenvolvedores entregam código. Operadores implantam e verificam. Autoridades externas declaram seu próprio fundamento. Essa divisão é a cadeia de custódia da migração.

Obsoletes diz onde começa a leitura atual. Não diz que o código de ontem parou.

Fontes