[Imap-protocol] Namespace separators
tss at iki.fi
Wed Jun 27 07:13:38 PDT 2007
On Mon, 2007-06-25 at 09:45 -0700, Mark Crispin wrote:
> On Mon, 25 Jun 2007, Timo Sirainen wrote:
> > I find this # thing also a bit weird. The client can't know about those
> > namespaces without NAMESPACE command, and if it does then there's really
> > no need for # because it can find out the exact prefixes anyway. So why
> > should the client do anything differently if there's #?
> Without a breakout mechanism such as #, then you have the ambiguity
> problem that you reported in your earlier message. How do you know that a
> name is in one namespace as opposed to some other one?
> More importantly, what happens if the different namespaces have different
> hierarchy semantics; different delimiters, different ways of expressing
> root, etc.? Maybe a particular namespace doesn't have hierarchy at all.
NAMESPACE reply returns the prefixes and you can compare those to the
mailbox name. How is a "foo/" prefix any more ambiguous than "#foo/"
> > I've understood that many commonly used clients ignore namespaces and
> > only show what is visible with LIST "" *, so I'd want to keep it
> > possible to list contents of all namespaces with it.
> Does your server list all other users' mailboxes with that command (since
> after all a user may have a public access mailbox)? Why not?
I was actually going to make it do that, once support for shared
mailboxes is finished.
> Does your server do an "ls -R /" for that command? Why not?
If user's mailbox root directory is set to /, then yes..
> Assuming that the user has a stupid client that does LIST "" * (a very bad
> thing to do),
The "*" wasn't really my point. Let's try again:
I've understood that many commonly used clients ignore namespaces and
only show what is visible with LIST "" %, so I'd want to keep it
possible to list contents of all namespaces with it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 196 bytes
Desc: This is a digitally signed message part
More information about the Imap-protocol