mailing list archives

The RFC says:

      All children of a top-level hierarchy node MUST use
      the same separator character.  A NIL hierarchy delimiter means
      that no hierarchy exists; the name is a "flat" name.

After first reading I thought that you couldn't mix NIL with another
delimiter, but I guess because the first sentence says "character", not
"delimiter" it is allowed (plus UW-IMAP does it). Maybe the next RFC
could clear that up.

So, apparently this should be possible:

1 LIST "" %
* LIST (\NoInferiors) NIL INBOX
* LIST (\NoSelect \HasChildren) "/" childboxes
* LIST (\NoInferiors) NIL foo

But what about this one:

1 LIST "" %
* LIST (\NoInferiors) NIL INBOX
* LIST (\NoSelect \HasChildren) "/" childboxes
* LIST (\NoInferiors) NIL "foo/bar"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20070627/16fbef3b/attachment.sig>

On Wed, 27 Jun 2007, Timo Sirainen wrote:
> The RFC says:
>       All children of a top-level hierarchy node MUST use
>       the same separator character.  A NIL hierarchy delimiter means
>       that no hierarchy exists; the name is a "flat" name.
> After first reading I thought that you couldn't mix NIL with another
> delimiter, but I guess because the first sentence says "character", not
> "delimiter" it is allowed (plus UW-IMAP does it). Maybe the next RFC
> could clear that up.

No.  Your confusion here is that INBOX is in a class by itself.  It is not 
part of the default namespace.  That's why the RFC goes on to say that 
INBOX is included in the LIST results if it matches the pattern; that too 
is a special rule since otherwise INBOX would not be listed.

Both of your examples are not possible:

> 1 LIST "" %
> * LIST (\NoInferiors) NIL INBOX
> * LIST (\NoSelect \HasChildren) "/" childboxes
> * LIST (\NoInferiors) NIL foo
>
> 1 LIST "" %
> * LIST (\NoInferiors) NIL INBOX
> * LIST (\NoSelect \HasChildren) "/" childboxes
> * LIST (\NoInferiors) NIL "foo/bar"

because the second and third items have conflicting hierarchy semantics. 
The first example (INBOX) does not conflict since INBOX is not part of the 
default namespace.

-- 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.

On Wed, 2007-06-27 at 09:35 -0700, Mark Crispin wrote:
> On Wed, 27 Jun 2007, Timo Sirainen wrote:
> > The RFC says:
> >       All children of a top-level hierarchy node MUST use
> >       the same separator character.  A NIL hierarchy delimiter means
> >       that no hierarchy exists; the name is a "flat" name.
> > After first reading I thought that you couldn't mix NIL with another
> > delimiter, but I guess because the first sentence says "character", not
> > "delimiter" it is allowed (plus UW-IMAP does it). Maybe the next RFC
> > could clear that up.
> 
> No.  Your confusion here is that INBOX is in a class by itself.  It is not 
> part of the default namespace.  That's why the RFC goes on to say that 
> INBOX is included in the LIST results if it matches the pattern; that too 
> is a special rule since otherwise INBOX would not be listed.

So, based on that description I assume this is legal then:

1 LIST "" *
* LIST () "/" INBOX
* LIST () "." foo
1 OK

INBOX would be in a separate namespace, so:

2 LIST "" INBOX/*
* LIST () "/" "INBOX/sub"
2 OK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20070808/376d99a1/attachment.sig>

The simple answer to your question is yes, it is legal.  But!!

The fact that a specification does not flatly prohibit doing something 
idiotic does not mean that it is a good thing for servers (or clients) to 
do the idiotic thing.

I doubt that very many clients would recognize a non-default namespace 
rooted with INBOX/, much less cope with the situation of the default 
namespace having a different hierarchy character than this non-default 
INBOX/ namespace.

Note too that the case-independent rules only apply for INBOX and not for 
INBOX/ .  Thus there is no reason to expect that INBOX/foo and inbox/foo 
refer to the same object.  Nor is there a reason to be surprised if they 
do refer to the same object.  This is this reason why hierarchies in the 
default namespace rooted with INBOX are a bad idea; although not as bad as 
a namespace rooted with INBOX.

Please consider Postel's robustness principle: "be conservative in what 
you send, and liberal in what you accept."

That principle does NOT mean "accept protocol violations."

It means that, to maximize interoperability, that you should not send 
idiotic things EVEN IF they are in compliance with the specification.  It 
also means that you should be able to cope with reading idiotic things.

RFC 3501 clearly lays out a model of namespaces using the # convention as 
an identifiable breakout character.  If you intend to have multiple 
namespaces (and if you have simultaneous hierarchies with different 
delimiters then you have multiple namespaces) then you should use this 
model and not try to do something else that is ambiguous.

On Wed, 8 Aug 2007, Timo Sirainen wrote:
> So, based on that description I assume this is legal then:
>
> 1 LIST "" *
> * LIST () "/" INBOX
> * LIST () "." foo
> 1 OK
> INBOX would be in a separate namespace, so:
> 2 LIST "" INBOX/*
> * LIST () "/" "INBOX/sub"
> 2 OK

-- 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.