Summary

  • O código INPROGRESS aparece em um OK sem tag e pode carregar uma contagem, deixar o total desconhecido ou servir apenas para manter a conexão ativa.
  • O desfecho continua sendo a resposta com a tag do comando: OK, NO ou BAD. Dados retornados e efeitos em outros sistemas exigem recibos próprios.

Uma operação mostra 99% durante vários segundos. Para o usuário, falta pouco. Para um orquestrador mal desenhado, já há confiança suficiente para disparar a próxima etapa. É nesse salto, do provável para o autorizado, que um indicador de progresso vira risco operacional.

O RFC 9585 não promete que 99% esteja perto do fim no sentido econômico ou temporal. O servidor pode revisar a meta, reduzir o valor de progresso ou descobrir uma nova fase. Pode, ainda, encerrar o comando com falha. A contagem descreve trabalho segundo a métrica escolhida pelo servidor; não descreve necessariamente objetos úteis produzidos.

A extensão resolve uma dificuldade real do IMAP. Pesquisas e cópias em caixas grandes podem demorar, e o silêncio não permite distinguir cálculo de conexão perdida. Mensagens livres já eram possíveis, mas cada cliente precisaria adivinhar seu significado. Publicado em maio de 2024, o RFC 9585 padroniza a capacidade e o código de resposta INPROGRESS.

O anúncio em CAPABILITY vem primeiro. Um servidor que implementa a extensão precisa listar INPROGRESS. Isso demonstra suporte ao mecanismo, não uma obrigação de emitir atualizações em todo comando. Operações rápidas podem chegar à resposta final antes do primeiro intervalo e não gerar notificação intermediária.

Quando o servidor decide notificar, a recomendação é um intervalo de dez a quinze segundos. O aviso pode ter como único objetivo evitar que o cliente encerre a conexão por tempo esgotado. Na forma sem detalhes, tag, progresso e meta são todos NIL. Há um sinal de presença, mas não uma medida.

A forma detalhada tem três posições. CMD-TAG aponta, quando possível, para o comando de origem. PROGRESS representa itens processados. GOAL informa o total positivo que se espera alcançar quando o comando terminar. Se não houver unidade natural, a implementação pode usar uma porcentagem, com meta 100 e progresso de 0 a 99.

As lacunas também fazem parte do contrato. Sem progresso disponível, progresso e meta ficam NIL. Com uma contagem parcial e total desconhecido, só a meta é NIL. Se a tag estiver indisponível ou contiver ], o campo da tag também é NIL. Esse aviso ainda orienta uma sessão com uma única operação. Com várias em voo, deixa de identificar qual delas está ativa.

Meta e progresso são preferências de forma, não invariantes. O documento diz que o progresso deve, em geral, crescer e que a meta não deve mudar. Ao mesmo tempo, obriga o cliente a suportar recuos e revisões. A interpretação recomendada é que uma etapa anterior acabou e o servidor encontrou mais trabalho demorado. Isso mantém o cliente funcional; não transforma a meta antiga em inventário completo.

O limite de conclusão está na sintaxe básica do IMAP4rev2. Respostas sem tag começam com * e carregam dados ou estados que não encerram o comando. A resposta de conclusão repete a tag escolhida pelo cliente e assume OK, NO ou BAD. Por isso, INPROGRESS precisa estar dentro de um OK sem tag e não pode integrar uma resposta com tag.

A palavra OK isolada induz ao erro. * OK [INPROGRESS ...] não tem a autoridade de A003 OK para o comando A003. O primeiro mantém a história aberta. O segundo registra sucesso e fecha o comando. Um agregador que omite o asterisco e a tag destrói a diferença que o protocolo criou.

Fechar o comando tampouco substitui seu conteúdo. No exemplo de SEARCH, avisos informam quantos itens foram processados. Depois, uma resposta SEARCH entrega os identificadores encontrados. Só então o OK com tag confirma a conclusão. Meta, conjunto de resultados e estado final são três artefatos distintos.

O RFC proíbe usar os valores como autoridade para outro fim. Em particular, GOAL não pode substituir a saída de SEARCH para determinar quantas mensagens existem numa pasta. Em COPY, uma contagem processada também não prova quantas cópias persistiram, foram indexadas, replicadas ou reconhecidas por uma rotina externa de retenção.

Não receber aviso também não prova paralisação. Até o primeiro sinal, o cliente assume progresso zero e meta desconhecida. Trata-se de um estado de conhecimento, não de uma inspeção do servidor. Um comando curto pode concluir sem avisos; um servidor problemático pode mandar avisos e continuar sem produzir o efeito esperado.

Os números recebidos precisam de validação hostil. A seção de segurança menciona valores capazes de provocar exceções aritméticas. Metas zero ou negativas, grandezas fora do razoável e progresso superior à meta devem ser ignorados. Revisões precisam entrar no histórico; suavizá-las em uma curva bonita retira evidência do operador.

Uma implantação madura acompanha estados, não apenas percentuais. Registra conexão, sessão autenticada, capacidade anunciada, comando, tag e simultaneidade. Armazena cada aviso bruto e separa a saída funcional. Só muda de “executando” para “sucesso”, “falha” ou “erro” após a resposta final correspondente. Se o efeito importante está fora do IMAP, ainda reconcilia o destino.

Esse último recibo impede que o OK cresça além do protocolo. O servidor declarou sucesso segundo o IMAP; ele não declarou, por consequência automática, que um arquivo foi indexado, que uma réplica convergiu, que uma obrigação de retenção foi satisfeita ou que o cliente recebeu confirmação.

O RFC 9585 torna a espera menos cega. Ele não elimina a necessidade de esperar pelo comprovante certo.

Sources