On Mon, 17 Mar 2003, Dan Mills wrote:
> On Monday, March 17, 2003, at 12:02 PM, Andreas Aardal Hanssen wrote:
>
> > On Mon, 17 Mar 2003, Dan Mills wrote:
> >> Why? Using dot as a separator seems sane, so you'd have:
> >> .foo.bar -> /foo/bar ("foo/bar" reported on imap).
> >> But why have:
> >> .foo -> .foo (".foo" reported on imap).
> >> instead of:
> >> .foo -> /foo ("foo" reported on imap).
> >> That is, do a s/\./\//g and treat dots as separators in all cases. If
> >> they are at the beginning of the mailbox string, then strip it off and
> >> show it as a toplevel mailbox over imap.
> >
> > Ambiguity. The folder /foo and the folder foo, as interpreted by the
> > IMAP
> > protocol, are the same.
This is true if / is the hierarchy separator, but not otherwise. If / is
not the hierarchy separator, then I'd suggest that /foo is an illegal
folder name.
> > To allow the folder ".foo" to be selected, the
> > server would have to try both "foo" and ".foo", and I don't want that
> > sort
> > of ambiguity in the spec.
Why does the folder .foo need to be selectable?
> So (on the imap side) dots are not allowed in mailbox names, unless
> they happen to be at the beginning of the name? I don't see the
> usefulness of making that exception.
Agreed.
> i.e., what happens if you try to create a mailbox (over imap) called
> "foo.bar"? The possibilities I see are:
>
> a) The dots are encoded into something else to avoid having them
> interpreted as directory separators later.
> b) The mailbox is created as-is, thus creating subfolders in the
> process.
> c) An error is thrown.
>
> (a) is awful and bound to cause problems later, (b) is sort of ok, but
> not really optimal since people should be using "/" as the separator on
> the imap side, which leaves (c). Unless there's some other option I'm
> missing.
RFC 2060 tells us what it means:
If the server's hierarchy separator character appears elsewhere in the
name, the server SHOULD create any superior hierarchical names that are
needed for the CREATE command to complete successfully. In other words, an
attempt to create "foo/bar/zap" on a server in which "/" is the hierarchy
separator character SHOULD create foo/ and foo/bar/ if they do not
already exist.
There is no mechanism to escape a hierarchy separator character. Therefore
folder names cannot contain the hierarchy separator character.
> With that in mind, selecting ".foo" should do one of:
>
> a) Select "foo" at the top level.
> b) Select ".foo" if dots are allowed in names (ie, they get encoded
> into something else).
> c) Throw an error.
>
> (c) is not wise, because compatibility with existing Maildir++ users is
> desired. (b) is correct iff dots are allowed in names, otherwise (a)
> is the correct option.
'.' is the hierarchy separator. Although it isn't defined by RFC 2060, it
makes sense to me that a leading hierarchy separator can be deleted - it
isn't separating anything. Therefore .foo and foo are the same folder.
This folder should always be .foo *or* foo in the file system storage.
Which of these we choose depends, I think, on how compatible we wish to be
with the paper definition of Maildir++.
--
Charlie
