Resumo

  • A RFC 9590 permite que o servidor omita o METADATA correspondente quando não consegue consultar as anotações de uma caixa e ainda finalize LIST com OK marcado.
  • NIL, resposta ausente, nome \NonExistent e pai devolvido apenas por causa de descendentes representam quatro estados de evidência, embora todos possam virar uma célula vazia.

Um cliente pede as caixas postais de primeiro nível e a anotação que define a cor de cada uma. Recebe os nomes, várias cores e A01 OK List completed. A coleta é registrada como concluída. Uma cor, porém, não chegou.

Não é seguro chamá-la de “não configurada”. O servidor pode ter respondido NIL, pode não ter conseguido fazer a consulta, pode ter listado um contêiner hierárquico que não é uma caixa existente ou pode ter incluído um pai apenas para revelar um descendente selecionado. A etiqueta final não resolve essa diferença.

O ganho de uma operação agregada

A capacidade LIST-METADATA transforma METADATA em opção de retorno do LIST-EXTENDED. Em vez de executar LIST e depois um GETMETADATA para cada nome, o cliente pede nomes, atributos e anotações no mesmo comando.

Para cada caixa listável que corresponda ao padrão canônico e às opções de seleção, o servidor deve retornar LIST seguido de uma ou mais respostas METADATA. Pela RFC 5464, vários pares entrada–valor podem vir juntos ou divididos. O cliente precisa montar uma matriz por caixa e entrada, não pressupor uma linha completa por caixa.

Há uma exceção normativa decisiva: se o servidor não consegue consultar as anotações de determinada caixa, pode eliminar o METADATA correspondente. O LIST ainda pode acabar com OK. A operação terminou; a cobertura local pode continuar parcial.

O vazio tem procedência

NIL é um resultado explícito. Na RFC 5464, significa que a entrada não tem valor. No exemplo da RFC 9590, a cor de foo volta como NIL porque não foi definida. A pergunta recebeu uma resposta.

Uma omissão de consulta não é NIL. Nenhum par foi observado para aquele alvo. Preencher NIL no aplicativo criaria uma afirmação que o servidor não enviou.

\NonExistent pertence a outra classe. Segundo a RFC 5258, o nome não identifica uma caixa existente e implica \NoSelect, mas pode aparecer para preservar contexto hierárquico ou de assinatura. A RFC 9590 mostra esse nome sem METADATA.

Com SUBSCRIBED RECURSIVEMATCH, um pai também pode ser listado só porque algum descendente satisfaz os critérios. Se o pai não satisfaz a seleção, sua ausência de METADATA é esperada. Não se trata de falha nem de valor vazio.

São quatro origens para uma aparência semelhante. Preservar a origem é o que permite decidir depois.

Uma taxa sem população não informa

O denominador correto reúne as caixas que combinam com o padrão, satisfazem a seleção e são alvos das entradas pedidas; em seguida, cruza caixas e entradas. Valores concretos e NIL explícitos contam como observados. Pais contextuais ficam em classe separada. Pares elegíveis sem resposta continuam visíveis como lacunas.

Um registro reproduzível mantém tag do comando, padrão, opções, entradas pedidas, nomes e atributos LIST, pares esperados, valores recebidos, NIL, omissões, tentativas posteriores, época da sessão e ação de cache. Sem isso, a expressão “metadados sincronizados” é uma camada simbólica construída sobre um token estreito.

A RFC 5258 lembra ainda que descendentes podem ser apagados ou renomeados depois de LIST e antes do acesso. A resposta tem um instante; não congela o universo de caixas. A RFC 9051 encerra comandos e estados, mas não comprova renderização nem percepção pelo usuário.

Registro não é adoção

IANA registra LIST-METADATA e a opção METADATA do LIST-EXTENDED. O registro dá nome comum ao mecanismo; não demonstra implantação, conformidade de produto ou frequência real de falhas.

Pela primazia do código em execução, a afirmação deve parar nos bytes emitidos e nos pares efetivamente interpretados. A especificação mínima define a semântica compartilhada. Política de repetição, validade do cache, exibição de desconhecido e limiar de aceitação ficam sob decisão local. Colocar essas escolhas dentro do significado de OK seria transformar coordenação em promessa.

Fontes