Resumo

  • A RFC 2062 removeu formas antigas do núcleo do IMAP, mas preservou um mapa limitado para encontros com implementações anteriores.
  • Servidores novos não eram obrigados a aceitar comandos obsoletos e, em geral, não podiam emitir respostas retiradas; clientes mantinham tratamentos específicos de recepção.
  • Entender uma entrada antiga não dava ao emissor licença para continuar produzindo-a.

As duas pontas de uma conexão quase nunca mudam juntas. Por algum tempo, software novo precisa ouvir o passado sem escolhê-lo como idioma de saída. As oito páginas da RFC 2062 organizaram essa assimetria.

O documento era Informational e dizia não definir um padrão da Internet. Reuniu sintaxes herdadas da RFC 1176, de variantes IMAP2bis e da RFC 1730 depois que o IMAP4rev1 as retirou do texto principal. Preservar a documentação não preservou a autoridade de produção.

Entre os comandos estavam FIND ALL.MAILBOXES, FIND MAILBOXES, SUBSCRIBE MAILBOX, UNSUBSCRIBE MAILBOX e PARTIAL, além de formas FETCH como BODY[0] e nomes RFC822. Um servidor novo não precisava implementá-los. Poderia fazê-lo por compatibilidade com um cliente antigo, mas essa concessão não criava uma recomendação para novos clientes.

PARTIAL mostra que a mudança tinha valor probatório. A resposta vinha como FETCH sem declarar o intervalo devolvido. Como comandos podiam ser executados fora de ordem, o cliente precisava processar e sincronizar cada etapa. Uma substituição funcional podia produzir um vínculo mais claro entre pedido, posição e dados recebidos.

As respostas obsoletas tinham regras diferentes. Novos servidores não deviam emiti-las, salvo MAILBOX como resposta a FIND antigo. O cliente devia ignorar a resposta experimental COPY e interpretar STORE como FETCH. Compatibilidade de entrada podia significar análise condicionada, descarte ou normalização, nunca aceitação indiscriminada.

A RFC 2683 advertiu depois que a tolerância de alguns servidores não tornava correto enviar comandos retirados. A RFC 2061 também separou conselhos de interoperabilidade das exigências básicas e recomendou não reintroduzir comandos de bboard, mesmo em software voltado a clientes antigos. Tolerância era uma saída ordenada, não renovação.

A RFC 3501 manteve a RFC 2062 como referência histórica. A RFC 9051 tornou a escolha entre IMAP4rev1 e IMAP4rev2 visível por capacidades e ENABLE IMAP4rev2; um servidor que anuncia ambas normalmente não envia formas removidas sem o pedido correspondente do cliente rev1. É uma continuidade de desenho, não prova de causalidade.

Para a operação, um teste de parser prova entrada possível, não saída configurada. Aceitar FIND não prova que o cliente deva enviá-lo. Um token no registro da IANA não prova implantação nem os bytes de uma sessão.

Uma retirada demonstrável separa gramática aceita, gramática emitida, modo negociado e tráfego observado. Primeiro se corta a saída velha; depois se mede a entrada residual, limita-se a exceção a pares identificados e remove-se o parser apenas quando a necessidade desaparece. Assim, compatibilidade é obrigação receptora limitada, não autorização para manter o comportamento antigo em produção.

Fontes