Resumo

  • A RFC 2342 padronizou a descoberta da convenção usada para nomes pessoais, de outros usuários e compartilhados.
  • Um namespace bem formado não substituía LIST, ACL, SELECT, FETCH, renderização nem uma evidência de atenção humana.

A resposta entregava coordenadas

Um cliente recebe a raiz pessoal vazia com /, a raiz de outros usuários ~ com / e NIL para compartilhamento. Agora consegue montar ~mark/INBOX. A gramática está resolvida, mas Mark pode não existir, seu INBOX pode estar oculto e SELECT pode ser negado.

Esse era o trabalho exato da RFC 2342. Antes dela, clientes frequentemente pediam ao usuário o prefixo local. NAMESPACE devolveu três posições ordenadas — Personal, Other Users' e Shared — cada uma com NIL ou uma lista de prefixos e delimitadores.

Podia haver várias raízes, separadores diferentes e exposição distinta por usuário. O servidor podia omitir namespaces que de fato suportava. Logo, a resposta descrevia a convenção que desejava expor naquela conexão, não um inventário universal.

Descoberta ampla podia ser recusada

A RFC sugeria anexar % ao prefixo de outros usuários e chamar LIST. Também dizia que o servidor não deveria revelar nomes sem list access. Ele podia retornar apenas usuários autorizados ou responder NO a uma busca ampla e exigir um nome específico.

No exemplo mais claro, #Users/% falha, enquanto #Users/Mike/% lista INBOX e Foo. O namespace existia nos dois momentos. A diferença estava na política de enumeração e na pergunta. Ocultar a lista protegia informações de conta que poderiam alimentar um ataque.

RFC 9051 torna a fronteira ainda mais explícita: LIST devolve um subconjunto dos nomes disponíveis ao cliente e pode devolver zero itens. Um nome pode vir com \Noselect ou \NonExistent; uma lista de assinaturas pode manter um nome cuja caixa já não existe.

Namespace anunciado, nome listado, assinatura, existência e seleção atual são estados diferentes.

Visibilidade não concedia leitura

Na RFC 4314, l controla visibilidade em LIST/LSUB; r autoriza SELECT/STATUS; s cuida da persistência de Seen/Unseen. Uma caixa pode aparecer sem poder ser lida. A RFC 9051 descreve justamente o caso com l e sem r: o nome é listável, mas o status não pode ser obtido e a caixa deve ser tratada como não selecionável.

A RFC 8440 permitiu incluir MYRIGHTS no LIST estendido. Isso aproxima a evidência de permissão, mas não converte direito em execução. SELECT bem-sucedido, por sua vez, coloca a conexão no estado selected e retorna FLAGS, EXISTS, UIDNEXT e UIDVALIDITY. Ainda faltam FETCH, processamento do cliente, exibição e presença do leitor.

Nem \Seen resolve a última etapa. FETCH, STORE, pré-visualização ou sincronização podem alterar a flag. Ela registra estado no servidor, não compreensão humana.

A precisão da norma estava em seu limite

NAMESPACE foi valioso porque removia uma suposição sem criar outra. O prefixo autorizava o cliente a formular a próxima operação corretamente; o resultado continuava pertencendo ao servidor, às permissões e ao estado naquele instante.

Essa modéstia serve a qualquer infraestrutura: um esquema pode validar uma referência sem criar o objeto; uma capability pode anunciar uma operação sem prometer sucesso; um controle verde pode permitir a próxima verificação sem certificar o desfecho.

A RFC 2342 publicou a legenda do mapa. Ela nunca afirmou que todas as portas desenhadas estavam abertas.