Resumo
- O tamanho pedido em UIDBATCHES é o máximo de mensagens existentes dentro de uma faixa, não uma promessa de cardinalidade. O servidor pode devolver menos e usar como limites UIDs que não correspondem a mensagens presentes.
- O
OKencerra o cálculo das faixas. Fechar exportação, migração ou sincronização exige preservar caixa e UIDVALIDITY, época do plano, eventos de mudança, comandos realmente executados e destino explícito para mensagens removidas, novas ou sem resultado.
Noventa por cento não é uma nota de qualidade
Uma leitura apressada de RFC 10022 pode converter a recomendação de 90% em indicador de desempenho: lote com 1.900 mensagens seria bom; lote com 1.899 seria ruim. O documento não constrói essa régua.
O servidor deve manter cada faixa abaixo ou igual ao tamanho solicitado. Também deve evitar faixas substancialmente menores e procurar alcançar 90% quando possível. Mas pode devolver menos quando isso simplifica ou melhora de forma relevante a implementação e quando a caixa muda durante o cálculo, sobretudo por expunges.
A recomendação de proximidade convive, portanto, com exceções deliberadas. Ela orienta interoperabilidade e experiência do cliente; não certifica um inventário. Se o pedido foi 2.000 e a faixa contém 1.977 mensagens atuais, o plano ainda pode estar correto. Registrar 2.000 como processadas seria falso; registrar automaticamente uma falha também poderia ser falso.
O operador precisa de duas colunas: limite planejado e população observada. A primeira dimensiona memória, paralelismo e custo. A segunda nasce somente quando um comando posterior encontra mensagens reais.
Essa separação é pequena no protocolo e enorme na gestão. Sem ela, a organização premia o planejamento por resultados que pertencem à execução.
As faixas são uma planta, não a lista de moradores
UIDBATCHES opera no espaço de UID da caixa selecionada. As faixas vêm do maior UID para o menor, permitindo que o primeiro lote represente as mensagens mais recentes. Isso parece uma lista ordenada, mas continua sendo um conjunto de fronteiras.
RFC 10022 permite que o UID inicial ou final de uma faixa não corresponda a mensagem alguma. Exclusões deixam lacunas. O servidor pode escolher pontos convenientes em torno de uma população aproximada. Uma faixa como 163886:99703 seleciona as mensagens existentes naquele espaço quando o comando seguinte for executado; não afirma que as duas pontas existem.
O último lote pode terminar em UID 1 mesmo se o menor UID presente for 302. O 1 comunica que a divisão chegou ao fundo. Não é uma mensagem sintética.
Modelos de dados que transformam limites em objetos introduzem uma mentira estrutural. Interfaces que estimam contagem pela diferença numérica repetem a mentira. Logs que chamam faixa de “lista de mensagens” eliminam a distinção que a extensão preservou.
A referência durável continua sendo delimitada por caixa, UIDVALIDITY e UID. A resposta de UIDBATCHES acrescenta uma época de planejamento. Ela não autentica conteúdo e não atravessa uma mudança de UIDVALIDITY.
O piso de 500 guarda uma decisão anterior
O cliente deve pedir pelo menos 500 mensagens por lote. Abaixo disso, recebe TOOFEW. A justificativa não é apenas computacional.
UIDONLY remove números de sequência da conexão habilitada. Comandos e respostas passam a se apoiar em UID; remoções aparecem como VANISHED. Se UIDBATCHES aceitasse lotes de uma mensagem, um cliente poderia reconstruir a posição fina que UIDONLY retirou. O piso impede que uma conveniência de lote revogue, por acidente, a arquitetura de identidade.
Isso mostra como extensões devem compor: uma nova capacidade não pode receber autoridade para desfazer silenciosamente a fronteira de outra. UIDBATCHES oferece partições grosseiras suficientes para trabalho, sem devolver o mapa posicional completo.
O cliente controla o teto que consegue processar. O servidor controla o desenho válido. O padrão controla a granularidade comum. Nenhum controla sozinho o significado empresarial de “concluído”.
O plano envelhece sem perder imediatamente a validade
Novas mensagens recebem UIDs acima do antigo máximo. Elas não entram no meio das faixas devolvidas. Assim, o contorno das faixas antigas permanece estável.
O conteúdo pode diminuir. Cada EXPUNGE ou VANISHED retira um elemento. Uma faixa inicialmente próxima de 2.000 pode produzir 1.960 respostas em um FETCH posterior. A faixa ainda aponta para o espaço certo; a população mudou.
Novas chegadas formam uma faixa acima do plano. Para um arquivo com corte às 10h, elas podem pertencer à próxima época. Para sincronização contínua, podem abrir um lote imediatamente. O protocolo não conhece a promessa feita ao usuário e não deve escolhê-la.
RFC 10022 limita a recomputação. O cliente não deve reenviar UIDBATCHES salvo ao selecionar outra caixa, após mais de meio lote ter sido removido ou após chegar mais de meio lote novo. O servidor deveria acompanhar solicitações e pode responder LIMIT para conter abuso.
O limiar protege recursos, não substitui uma regra de negócio. Um plano pode continuar tecnicamente aproveitável e já não ser suficiente para uma migração que prometeu “tudo até o corte”. A empresa precisa nomear quem decide a expiração operacional.
Uma resposta vazia responde a uma pergunta específica
Mesmo sem faixas, o servidor precisa enviar a resposta não marcada UIDBATCHES, com o correlator do tag, e depois encerrar o comando. Isso ocorre numa caixa vazia e também quando a janela solicitada não existe.
Se há quatro lotes e o cliente pede 6:8, vazio mais OK significa “nenhuma faixa nessa janela”. Não significa “nenhuma mensagem na caixa”.
O contexto é parte do fato: conta, caixa selecionada, UIDVALIDITY, tag, tamanho, janela e hora. Um lago de logs que guarda apenas a linha final conserva a resposta e perde a pergunta.
Os estados negativos também merecem fidelidade. TOOFEW pede lote maior. TOOMANY pede janela menor ou estratégia parcelada. LIMIT pede espera ou correção da frequência. Um intervalo de lotes escrito ao contrário pode receber CLIENTBUG. Cada um aponta para um dono e uma ação diferentes.
Reduzir todos a “erro do servidor” é uma forma de dependência: a equipe passa a precisar da interpretação privada do fornecedor para recuperar semântica já disponível no padrão.
Cem mil mensagens formam o núcleo interoperável
Uma janela explícita não pode abranger mais de 100.000 mensagens. O servidor precisa suportar pelo menos essa escala. Numa caixa enorme, porém, um pedido sem janela por todas as faixas pode receber TOOMANY.
Há equilíbrio nessa regra. A capacidade anunciada deve funcionar num patamar comum; o cliente não recebe um cheque em branco para cálculo global.
O caminho para caixas maiores é pedir janelas sucessivas. Como o estado pode mudar entre chamadas, o texto sugere sobrepor a fronteira, por exemplo 1:100 e 100:200. O lote repetido permite comparar duas visões.
Sobreposição não congela a caixa. Não determina automaticamente qual resposta serve ao objetivo. Ela é evidência de continuidade ou de divergência. Se o cliente remove o duplicado antes de comparar, paga o custo e destrói o benefício.
Um registro útil guarda ambas as respostas, horários, eventos intermediários e decisão. É assim que uma técnica local se transforma em prova auditável sem exigir autoridade central.
PARTIAL e MESSAGELIMIT ficam do outro lado da fronteira
PARTIAL pagina resultados reais de SEARCH e limita respostas reais de UID FETCH. UIDBATCHES prepara faixas que ainda poderão ser usadas em FETCH, STORE, COPY, MOVE ou outra ação. Uma página é parte de uma consulta executada; uma faixa é uma unidade planejada.
SEARCHRES usa $ para referenciar o último resultado de busca. RFC 10022 proíbe que UIDBATCHES grave em $, pois não é SEARCH. A proibição impede que um plano aproximado vire conjunto confirmado por efeito colateral.
QRESYNC e CONDSTORE ajudam a observar mudanças, sequências de modificação e mensagens VANISHED. Podem mostrar que o plano divergiu. Não atualizam retroativamente a resposta antiga.
MESSAGELIMIT define quantas mensagens certos comandos posteriores podem processar. Se o servidor anuncia 1.000, o cliente deveria escolher lotes UIDBATCHES de no máximo 1.000. Uma faixa legítima de 2.000 não autoriza um único FETCH acima da capacidade anunciada.
A linha CAPABILITY é um catálogo de contratos. O tamanho executável resulta da interseção entre eles, o verbo e o estado da caixa. Somar capacidades como selos verdes esconde as dependências.
O fechamento precisa reconciliar identidades
Sete conjuntos tornam a situação legível:
| Conjunto | Pergunta de evidência |
|---|---|
P |
Quais mensagens pertencem à política e à geração deste trabalho? |
B |
Quais mensagens existentes eram alcançáveis pelas faixas ao planejar? |
A |
Quais receberam de fato um comando posterior? |
C |
Quais obtiveram resultado terminal aceito? |
X |
Quais previstas foram observadas como removidas ou desaparecidas? |
N |
Quais chegaram acima do antigo máximo? |
U |
Quais permanecem sem resultado ou passíveis de repetição? |
Uma exportação com corte pode exigir P = C ∪ X, U vazio e motivo para cada X, deixando N para a época seguinte. Uma sincronização contínua pode abrir lote para N sem esperar. A regra pertence ao dono do serviço.
Contagens iguais não provam identidade. Uma remoção e uma chegada podem manter o total, substituindo um membro. A chave de conciliação inclui caixa, UIDVALIDITY, UID e época.
Essa estrutura preserva um comum mínimo: identificadores, sintaxe, limites e resultados verificáveis. Como propõe Heng Lu, decisões futuras que não alteram esses invariantes ficam perto de quem opera, assume risco e pode observar efeito.
O que as fontes não provam
RFC 10022 não demonstra adoção por provedor nomeado, comportamento de produto ou cumprimento em produção. A recomendação de 90% não é métrica publicada de serviço. Os cenários são testes derivados do contrato, não relatos de incidentes.
O registro da IANA fixa o significado de UIDBATCHES, TOOFEW e TOOMANY. Não verifica binários. CAPABILITY declara; a resposta delimita estado planejado; o comando posterior produz efeito. Confundir essas camadas concede poder probatório a uma palavra que não executou nada.
Primazia do código em execução não significa abandonar a norma. Significa permitir que recibos reais corrijam uma síntese institucional. Se U permanece, o painel não pode vencer a realidade apenas porque o cálculo foi conforme.
Fontes
- RFC 10022 — Extensão IMAP UIDBATCHES
- Registro de publicação do RFC 10022
- RFC 9051 — Internet Message Access Protocol, versão 4rev2
- RFC 3501 — Internet Message Access Protocol, versão 4rev1
- RFC 9586 — Extensão IMAP UIDONLY
- RFC 9394 — Extensão IMAP PARTIAL para SEARCH e FETCH paginados
- RFC 4731 — Extensão para controlar informações devolvidas por SEARCH
- RFC 7162 — Ressincronização rápida de flags e caixas IMAP
- RFC 5182 — Referência ao último resultado SEARCH
- RFC 9738 — Extensão IMAP MESSAGELIMIT
- IANA — Registro de capacidades IMAP
- Heng Lu — Primazia do código em execução
- Heng Lu — Especificação inicial mínima, decisão futura localizada e adoção voluntária
- Heng Lu — Sobre camadas de realidade
- Heng Lu — Sobre soberania de dados
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
