Resumo

  • As opções de seleção definem quais nomes pertencem ao resultado, enquanto as opções de retorno apenas acrescentam informações aos nomes já escolhidos. A árvore, sozinha, não registra essa fronteira.
  • Com RECURSIVEMATCH, um ancestral pode ser devolvido por causa de um descendente que atende SUBSCRIBED, mesmo que o ancestral não seja inscrito ou esteja marcado \NonExistent; CHILDINFO conserva o motivo.

A árvore precisa vir acompanhada do recibo

Uma lista hierárquica parece autoexplicativa. A indentação sugere posse, uma seta sugere filhos e uma linha visível parece representar algo que pode ser aberto. Esse vocabulário da interface é útil, mas não revela a pergunta que o servidor respondeu.

LIST-EXTENDED transforma a descoberta em uma operação parametrizada. O reference name e os padrões delimitam o plano de correspondência. Selection options decidem a participação no conjunto. Return options solicitam dados sobre os membros. A identidade autenticada, as capabilities anunciadas e o momento do processamento completam o contexto.

O mesmo estado pode, portanto, produzir árvores legitimamente distintas. Uma requisição escolhe nomes inscritos. Outra escolhe caixas locais e só depois marca a inscrição. Uma terceira inclui nomes remotos. Uma quarta mostra um pai que falhou no filtro, pois existe um descendente relevante abaixo dele.

Guardar apenas as linhas é como guardar um total sem o cálculo. O recibo mínimo inclui servidor, sessão, geração de capability, principal autenticado, reference name, padrões originais, interpretação canônica, opções de seleção e retorno, command tag, respostas não etiquetadas completas e tempo. É esse conjunto que permite reconstituir por que cada linha apareceu.

Filtrar membros não é o mesmo que anexar atributos

Uma selection option altera a regra de admissão de nomes. Em geral, cada nome precisa corresponder a pelo menos um padrão LIST canônico e satisfazer todas as condições de seleção. RECURSIVEMATCH tem uma regra especial expressa para pais; a exceção não se estende por analogia a outras opções.

Uma return option controla os dados enviados para cada nome já selecionado. Ela não pode fazer o servidor relatar nomes adicionais. Misturar as duas funções produz resultados visualmente plausíveis, mas muda a pergunta e, com ela, a autoridade do conjunto.

SUBSCRIBED demonstra a diferença. Na posição de seleção, pede nomes inscritos em vez de caixas existentes. Pode deixar de fora caixas reais e incluir uma inscrição cujo objeto já foi apagado. Na posição de retorno, só adiciona o estado de inscrição aos nomes que a LIST subjacente já selecionou. Não restringe e não expande o conjunto.

A seleção SUBSCRIBED implica o retorno correspondente, de modo que as linhas escolhidas levam \Subscribed. Mesmo assim, a proveniência precisa informar se a inscrição causou a entrada da linha ou se foi apenas observada em uma linha escolhida por outro motivo. Essa diferença muda decisões de migração, limpeza e reconciliação.

LIST (SUBSCRIBED) também não é uma nova grafia de LSUB. A forma estendida exige atributos corretos e completos em seu significado ordinário; LSUB carrega comportamentos especiais herdados. Se um cliente normaliza as duas respostas como a mesma coleção, descarta a correção semântica que motivou a extensão.

O pai pode falhar no teste e ainda ser útil

Considere Foo/Baz inscrito e Foo não inscrito. Um padrão limitado ao primeiro nível não alcança o filho. O critério SUBSCRIBED elimina o pai. Sem contexto recursivo, a resposta pode ficar vazia, embora haja uma assinatura relevante abaixo.

RECURSIVEMATCH permite retornar Foo com CHILDINFO (SUBSCRIBED). O pai ainda deve coincidir com o padrão LIST canônico da requisição. O descendente causal não precisa coincidir com esse padrão. A linha afirma que algum descendente satisfez o critério e que o pai foi incluído para dar contexto hierárquico.

Ela não afirma que o pai seja inscrito. Se o cliente elimina CHILDINFO e grava somente Foo, a causalidade se perde. Se todas as linhas renderizadas recebem automaticamente comandos de seleção ou exclusão, um nome explicativo adquire poderes que nunca foram verificados.

A validade da opção reforça sua finalidade. RECURSIVEMATCH não pode aparecer sozinho nem somente com REMOTE; o servidor deve responder BAD. Ele precisa de outro critério cuja satisfação por um descendente possa explicar. Não é uma solicitação genérica de recursão completa.

Um nome ancestral pode não designar objeto algum

A hierarquia textual do IMAP não exige que todo prefixo exista como caixa. Customers/ABC pode ser uma caixa sem que exista Customers. Ainda assim, a interface pode precisar mostrar o ancestral para posicionar o filho.

Nesse caso, RFC 5258 admite o pai com \NonExistent e CHILDINFO (SUBSCRIBED). Os atributos se somam: o nome não designa uma caixa existente e foi retornado por causa de um descendente que passou pela seleção. \NonExistent também implica \NoSelect.

Até \Subscribed e \NonExistent podem coexistir. A inscrição é estado associado a um nome; existência é estado do objeto caixa. Uma exclusão pode deixar uma inscrição residual. Tratar inscrição como prova de existência esconderia justamente o estado que uma rotina de saneamento precisa encontrar.

RFC 2342 estabelece uma fronteira próxima. NAMESPACE descreve como nomes pessoais, de outros usuários e compartilhados são organizados, sem provar existência ou acesso. RFC 5258 acrescenta uma questão operacional: depois de executar uma descoberta, uma linha ainda pode ter sido causada pelo descendente, não pelo próprio estado. Gramática e causalidade exigem evidências separadas.

CHILDINFO preserva a causa, não congela o filho

CHILDINFO lista os critérios que fizeram o ancestral não correspondente aparecer e afirma que ao menos um descendente os satisfez. Não revela qual descendente foi, nem garante que continuará com o mesmo nome ou direito de acesso.

Entre a resposta LIST e a próxima ação, outra sessão pode apagar ou renomear o filho. Uma ACL pode mudar. O cliente precisa aceitar que a busca seguinte não encontre mais nenhum descendente qualificado. O item registra uma observação no tempo, não uma chave externa durável.

Em comandos enviados em pipeline, esse motivo também ajuda a atribuir respostas não etiquetadas. Os critérios CHILDINFO, os parâmetros de cada LIST e a ordem de recebimento formam a dependência. O tag final isolado não dá a cada linha intermediária seu significado operacional.

O servidor deveria suprimir CHILDINFO redundante quando também retorna um filho coincidente. A recomendação não permite inferir ausência. O cliente deve tolerar uma razão repetida sem criar dois objetos e não pode concluir que não há descendentes apenas porque o item não veio em uma resposta que não era obrigada a carregá-lo.

CHILDINFO e \HasChildren respondem a perguntas distintas. O primeiro explica por que a seleção incluiu o ancestral. O segundo informa se há filhos acessíveis para auxiliar a navegação. Proveniência de seleção e dica estrutural não devem dividir o mesmo campo derivado.

O indicador de expansão tem dono e validade curta

A opção CHILDREN pede \HasChildren ou \HasNoChildren. Com esses atributos, o cliente pode desenhar uma árvore recolhida antes de baixar todos os níveis. O ganho de desempenho coloca uma observação do servidor dentro de um controle visual muito convincente.

Mesmo assim, \HasChildren é sensível ao acesso. O servidor não deveria usá-lo quando existem filhos, mas nenhum é acessível ao usuário autenticado, embora essa avaliação nem sempre seja barata. E uma resposta correta durante o processamento pode ficar desatualizada antes que a seta seja aberta.

\HasNoChildren quer dizer que não há caixas filhas acessíveis ao principal atual. Não declara inexistência para todos os usuários. Também não equivale a \NoInferiors, que afirma que inferiores não existem e não podem ser criados. Transformar ambos em um booleano permanente de folha apaga a diferença entre visibilidade momentânea e impossibilidade estrutural.

Uma chave de cache segura inclui servidor, conta ou principal, geração de namespace, nome, geração da política de acesso e instante. A abertura deve provocar nova descoberta; ela não deve executar uma conclusão antiga como ordem para remover descendentes.

Extensões adicionam evidência, não soberania

REMOTE é uma selection option incomum: amplia o universo para caixas remotas e locais e não tem return option correspondente. A expansão não comprova que o destino remoto esteja alcançável, que SELECT terá sucesso ou que mensagens estejam disponíveis.

LIST-STATUS pode anexar estado; SPECIAL-USE, funções; NOTIFY e CONTEXT, atualização. RFC 4314 mantém direitos ACL distintos da aparição de um nome. Cada recurso melhora a projeção, mas nenhum rompe sua dependência da requisição, do principal e do momento.

Os registros da IANA estabilizam o vocabulário de capabilities e atributos de nome. Um token registrado tem referência normativa; isso não prova anúncio, implementação correta ou cobertura de uma instalação. RFC 9051 leva o IMAP adiante, mas a pergunta de evidência continua específica: qual comando foi executado, em qual sessão e por que cada nome foi incluído.

A disciplina de reality layers de Lu Heng evita a promoção indevida. O pai é real como linha de uma resposta. O filho é real como causa relatada naquele instante. Caixa, inscrição, direito, sincronização e representação visual são realidades diferentes. A abstração continua confiável somente enquanto a junção puder ser desfeita até as observações originais.

Fontes