Hi,

I just read Section 5 of RFC3501, and I would like
to formulate some statements just to check if those
who are familiar with RFC3501 do agree/disagree.

1. A delimiter is valid for all names in a mailbox
hierarchy. i.e. let '.' (dot) be our delimiter
and let '/' (slash) be another delimiter.
Now it is in compliance with RFC3501 to build
a mailbox hierarchy like

tit_and_tat
tit_and_tat.tit
tit_and_tat.tat
love_and_piece
love_and_piece/love
love_and_piece/piece

Am I right? (Regardless if there is any implementation
that supports that.)

2. If a mailbox name has a leading '#' the part of the name
following the '#' is the namespace.

#news.comp.mail.imap
\__/ \____________/
| |
ns name

#news.de.comp.lang.c
\__/ \____________/
| |
ns name

Correct?

3. The only mandatory name is INBOX. It is an error trying to create
a mailbox with the same name and it also is an error trying to
delete the mailbox named INBOX. But it's conform to delete any
other mailbox. There may be implementations that do have other
mailboxes like 'trash', 'sent items' which are also "read only".

Best Regards,

Oliver

Oliver Block writes:

> 1. A delimiter is valid for all names in a mailbox
> hierarchy. i.e. let '.' (dot) be our delimiter
> and let '/' (slash) be another delimiter.
> Now it is in compliance with RFC3501 to build
> a mailbox hierarchy like
>
> tit_and_tat
> tit_and_tat.tit
> tit_and_tat.tat
> love_and_piece
> love_and_piece/love
> love_and_piece/piece
>
> Am I right? (Regardless if there is any implementation
> that supports that.)

No, the hierarchy delimiter must be the same within a namespace. Different
namespaces may have different delimiter characters, though.

>
> 2. If a mailbox name has a leading '#' the part of the name
> following the '#' is the namespace.
>
> #news.comp.mail.imap
> \__/ \____________/
> | |
> ns name
>
> #news.de.comp.lang.c
> \__/ \____________/
> | |
> ns name
>
> Correct?

Right. But there's nothing that will guarantee you that "." is the
hierarchy delimiter here. Nothing prohibits the letter 's' from being the
designated hierarchy delimiter within the "#new" namespace. That would be a
rather dumb thing to do, of course, but it's technically allowed.

> 3. The only mandatory name is INBOX. It is an error trying to create
> a mailbox with the same name and it also is an error trying to
> delete the mailbox named INBOX.

No, not really. INBOX does not have to exist. If it doesn't, I see nothing
that would prohibit you from creating a folder of that name.

> other mailbox. There may be implementations that do have other
> mailboxes like 'trash', 'sent items' which are also "read only".

Correct.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEkzN0x9p3GYHlUOIRAkqaAJ9YfMbJs1h/8fVGByJ2fQ9hUFYZLQCeIZnZ
3HZmZf6gEBuktWobLXZn7+c=
=QgdG
-----END PGP SIGNATURE-----

On Fri, 16 Jun 2006, Sam wrote:
>> 3. The only mandatory name is INBOX. It is an error trying to create a
>> mailbox with the same name and it also is an error trying to delete the
>> mailbox named INBOX.
> No, not really. INBOX does not have to exist. If it doesn't, I see nothing
> that would prohibit you from creating a folder of that name.

It is an error to attempt to CREATE (RFC 3501, 6.3.3) or DELETE (RFC 3501,
6.3.4) INBOX.

The intent is that there is always an INBOX. However, RFC 3501 section
6.3.8 refers in passing to the possibility of there not being an INBOX.
In such a case, the restriction against creating INBOX still applies.

Note that there is no specific provision against creating some name that
happens to correspond to INBOX. For example, in UW imapd, it is
permitted to CREATE #driver.mbx/INBOX which will create an INBOX in the
alternative mbx format.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.