On Mon, 17 Mar 2003, Andreas Aardal Hanssen wrote:
> I see your point - there is a hole in the spec. The first thing that pops
> into my mind is that in order for IMAPdir to support dots in the middle of
> mailbox names, they could be "encoded" using two dots. So:
>
> foo -> foo
> foo.bar -> foo/bar
> foo..bar -> foo.bar
> foo...bar -> foo./bar
>
> Leftmost derivative, to avoid ambiguity.
Please don't go there.
We need to decide what we are doing and why we are doing it.
On the one hand, we have the IMAP view of the world. We can either use /
or . as the hierarchy separator. Either way works:
foo
foo/bar
foo/bar/
boo/bar/baz
or
foo
foo.bar
foo.bar.
foo.bar.baz
and presumably we can also allow a leading (null) separator.
The next thing we need to do is to map these folders into file system
Maildirs. Obviously the mapping must be ambiguous.
My preference is to use the natural mapping
foo => $prefix/foo
foo/bar => $prefix/foo/bar
foo/bar/ => $prefix/foo/bar
boo/bar/baz => $prefix/foo/bar/baz
but others prefer a Courier compatible
foo => ${prefix}/.foo
foo/bar => ${prefix}/.foo.bar
foo/bar/ => (implicit)
boo/bar/baz => ${prefix}/.foo.bar.baz
Or, if . is the hierarchy delimiter, we can have
foo => $prefix/foo
foo.bar => $prefix/foo/bar
foo.bar. => $prefix/foo/bar
boo.bar.baz => $prefix/foo/bar/baz
or
foo => ${prefix}/.foo
foo.bar => ${prefix}/.foo.bar
foo.bar. => (implicit)
boo.bar.baz => ${prefix}/.foo.bar.baz
We start getting ourselves, and probably others, confused if we try to
allow either . or / to be used as part of a folder name. The only simple
such case is if we are using / as the hierarchy separator, and we are
not using . in the filesystem to separate components (i.e we have the
first case above, and are using subdirectories for subfolders).
To put that another way:
If we use . as the hierarchy separator, we must declare / as an illegal
character in folder names.
If we use / as the hierarchy separator, and we emulate a folder tree
after Courier, then we must declare . as an illegal character in folder
names.
OTOH, we have a file and directory hierarchy, and we wish to export a
subset of it by IMAP. There is no requirement that I can see that all
files and directories can be referred to via an IMAP folder name. Don't
invent that requirement.
There may be a requirement that all folders that are currently managed by
another IMAP daemon can be exported by bincimap without being
moved/renamed. If that is the case, then there are considerable
constraints based on what that daemon actually does (obviously Courier
needs to be considered here).
I personally have a requirement for bincimap to export a set of folders
currently managed by a maildir patched UW-imapd. I am satisfied that I can
move and rename directories as I need to when the time comes to convert
systems. Nevertheless it would be nice to be able to export the current
folders as-is, with no migration.
> So this would be the exception: either one or two dots at the start of an
> item in IMAPdir represents one dot in the start of the mailbox name:
>
> .foo -> .foo
> ..foo -> .foo
>
> How does that sound?
Bad :-)
--
Charlie
