On Tue, 16 Sep 2003, Rob Siemborski wrote:
> I don't think IMAP has anything to say on the matter, really, since the
> specification has remained silent on the issue.
There is quite a bit of IMAP which is unsaid but (for better or worse)
thought to be obvious because it was the useful behavior.
In RFC 3501:
The character "*" is a wildcard, and matches zero or more
characters at this position. The character "%" is similar to "*",
but it does not match a hierarchy delimiter. If the "%" wildcard
is the last character of a mailbox name argument, matching levels
of hierarchy are also returned. If these levels of hierarchy are
not also selectable mailboxes, they are returned with the
\Noselect mailbox name attribute (see the description of the LIST
response for more details).
Note the words "zero or more".
Why "zero"? Because of the next sentence, where "matching levels of
hierarchy" are mentioned.
Perhaps the wording in the specification could be better, but it is there
nonetheless.
> Really, I don't see the need for a server to ever advertise a \NoSelect
> mailbox with no children, since it doesn't have any useful information --
> the user can't do anything *but* create a mailbox there.
This is incorrect. There is other information. The name exists. You may
get an error if you try to create that name as a mailbox; if so, the only
way to create that mailbox is to delete that name as a directory.
As a thought exercise, imagine if "mkdir" followed by "ls" in the UNIX
shell did not list the newly-created directory. Or of "ls" did not list a
directory when you deleted the last name inside it. That is the type of
filesystem that was created with Cyrus, and which some people seem to
think should be the one and only type in IMAP.
> If they want to create a
> message-containing mailbox where the directory already exists and the
> server does not support dual-use, the server can remove the directory and
> replace it with a flat-file mailbox (or whatever).
And this is why the LIST command needs to include the directory name.
> I'm not going to argue that any given server isn't free to use this
> convention of trailing hierarchy separator, but we're far from making IMAP
> a generally less useful protocol by not using it.
IMAP is made a less useful protocol if clients can not depend upon a
behavior and as a consequence are required to do additional commands.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
