mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Timo Sirainen <tss@iki.fi>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:40 -0000
Message-ID: 1182779912.3768.174.camel@hurina permalink / raw / eml / mbox
What exactly is the use for mailbox root names? It seems like it should
be exactly the same as the namespace prefix. UW-IMAP anyway does
something weird:

1 LIST hello/world/ ""

It returns "hello/" as the mailbox root, even if hello doesn't exist.
Why? Does Pine really depend on this? I remember I changed Dovecot to do
this a few years ago because Pine wouldn't work otherwise correctly with
~/mail/ or mail/ or similar folder collection paths (I used to return ""
as root). Now that I'm looking over the code I'm just wondering why.

-------------- 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/20070625/779a8294/attachment.sig>
Reply
E-mail headers
From: tss@iki.fi
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:40 -0000
Message-ID: 1182781450.3768.176.camel@hurina permalink / raw / eml / mbox
On Mon, 2007-06-25 at 16:58 +0300, Timo Sirainen wrote:
> 1 LIST hello/world/ ""
> 
> It returns "hello/" as the mailbox root, even if hello doesn't exist.
> Why? Does Pine really depend on this? I remember I changed Dovecot to do
> this a few years ago because Pine wouldn't work otherwise correctly with
> ~/mail/ or mail/ or similar folder collection paths (I used to return ""
> as root). Now that I'm looking over the code I'm just wondering why.

Looks like I can't reproduce this anymore. Maybe there were other things
that caused Pine to break. So is it OK then if I return mailbox root =
namespace prefix, and if there is no prefix then just return ""?

-------------- 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/20070625/6a659ba9/attachment.sig>
Reply
E-mail headers
From: mrc@CAC.Washington.EDU
To: imap-protocol@localhost
Date: Fri, 08 Jun 2018 12:34:40 -0000
Message-ID: alpine.OSX.0.99.0706250744160.1955@pangtzu.panda.com permalink / raw / eml / mbox
On Mon, 25 Jun 2007, Timo Sirainen wrote:
> > 1 LIST hello/world/ ""
> > It returns "hello/" as the mailbox root, even if hello doesn't exist.
> > Why? Does Pine really depend on this?

That's because that form of LIST is a syntax-only operation.  What it's 
telling you here is that the top-level of "hello/world/" is "hello/". 
Pine is probably more likely to do
 	tag LIST hello/world ""

> > I remember I changed Dovecot to do
> > this a few years ago because Pine wouldn't work otherwise correctly with
> > ~/mail/ or mail/ or similar folder collection paths (I used to return ""
> > as root). Now that I'm looking over the code I'm just wondering why.

Uh-oh, you had better be careful here!!!!!!

~/mail is a very different case from mail/ because ~ serves as a hierarchy 
breakout character.  The root in
 	tag LIST ~fred/mail/ ""
is most certainly *not* ""!  It is "~fred/".

In fact, that's probably what is going on here.  Since ~fred/ is a 
namespace reference, that form of LIST is actually used, whereas
 	tag LIST fred/mail/ ""
probably isn't actually used but is "fred/" for consistency.  I don't dare 
change it (see below).

> Looks like I can't reproduce this anymore. Maybe there were other things
> that caused Pine to break. So is it OK then if I return mailbox root
> namespace prefix, and if there is no prefix then just return ""?

I would recommend that you not do so.  It is safer to you copy what UW 
imapd does, even if it doesn't seem to make sense.  I don't pretend to 
understand or remember hierarchy in its full, hideous, glory.

You weren't around during the hierarchy wars (nearly 15 years ago); but 
everybody who was has evil memories.  I have the most evil memories of 
all, as I was caught in the middle.  Nobody was really happy with the 
result; but what came out was a carefully-balanced compromise between two 
very different views of how hierarchy and hierarchy navigation should 
work.

The underlying purpose of the reference argument in LIST is to provide the 
information for a client to have the concept of "connected directory" even 
though the server has no such thing.  Basically, the reference is either 
"I am connected to this directory" or "I am connected to the directory 
that contains this name", depending upon if there is a trailing hierarchy 
delimiter.

I forget why getting the root of the hierarchy was important, but it was. 
If I were to alter the status quo, I am sure that someone will call me to 
task for betraying the Great Compromise....  ;-(

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