[Imap-protocol] Namespace questions

Mark Crispin mrc+imap at panda.com
Wed May 19 12:47:04 PDT 2010


On Wed, 19 May 2010, Pete Maclean wrote:

> Now I have

> the idea that a client can discover them only by user configuration

> or via the NAMESPACE command. Is this correct?


Correct. Which means that you need to be careful what you choose to put
into namespaces; since as Philip mentioned some clients aren't able to
access them at all.

The fact that namespaces can be used for certain things (such as other
user mailboxes or public mailboxes) does not mean that they MUST be used
for those purposes.

I urge you to be very cautious about deploying a kludge, such as Philip
suggested (make * tranverse namespaces), in the name of making things
better for one client. Such kludges end up biting you with other clients,
which leads to the situation of the compliant client being the bad guy
and/or a kludge tower.

It's much better to rethink the default hierarchy (such as I did with the
chimera in my new server). I haven't quite reached that point yet, but
I'm rapidly coming to believe that namespaces should simply be abolished
in favor of a single One True Hierarchy that all servers much follow. The
slow agonizing demise of netnews just makes it easier by getting rid of
the big reason why namespaces came about to begin with.

With a One True Hierarchy, you wouldn't need a namespace to discover other
users or public, since those would all be static definitions.


> Are you saying that the default namespace should be listed first

> within the class of personal namespaces? That makes sense but I can

> find nothing in RFC 2342 that mentions it.


Yes. That's a bit of folklore that ought to go in to any update to RFC
2342.

Normally, there should be only one personal namespace; and I think that is
what RFC 2342 intended. I broke that at once.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.



More information about the Imap-protocol mailing list