Understanding Reference Names
Hi, Think of the reference name as being the connected directory. For the following examples, think about a UNIX filesystem for the namespace. If you do tag LIST foo then you'll see foo in your home directory. If you do tag list mail/ foo then you'll see foo in your mail/ subdirectory. On the other hand, tag LIST ~fred/foo tag LIST mail/ ~fred/foo will return the same thing: foo in fred's home directory. The point of the reference argument is that a client can have a connected directory, and use LIST and LSUB to resolve the names, without having to know special details such as the meaning of ~ or other prefix character. Assuming to have following home directory: C:[EMAIL PROTECTED] Assuming to have following Mailboxes: INBOX, Read (under Inbox), Trash and Read (under folder Specials) Would it be right to save Reference and Mailboxname on server side like this?: Reference Mailbox INBOX INBOX\Read Trash Specials Read Is that right, that reference Names are not meant as Mailboxes but only as folders where Mailboxes can be stored in, as an hierachical method? Internally I would get the Information like this: For INBOX C:[EMAIL PROTECTED] For Read C:[EMAIL PROTECTED] For Read under Specials C:[EMAIL PROTECTED] @Mark Crispin: Sorry for sending this to you personally, it was meant for the maillist. -- regards Antonio Cambule STÜBER SOFTWARE www.stueber.de -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
Re: Understanding Reference Names
A reference name of is not the same as a reference name of . Also, to avoid possible ambiguity, it is better that non-empty reference names terminate with the hierarchy delimiter, e.g. tag LIST Specials\\ Read rather than tag LIST Specials Read Consider the following command: tag LIST Specials\\Fred Read A server may assemble this as either Specials\\Fred\\Read or as Specials\Read. In general, yes, a reference name is not a mailbox itself, but rather a directory which contains mailboxes. As an aside, I disapprove of the practices of mailboxes under INBOX and Trash mailboxes. IMAP does not prohibit either of these practices, but these practices are associated with substantial client and user confusion. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Understanding Reference Names
At 2004-06-02 13:15:18 +0200, [EMAIL PROTECTED] wrote: I've never seen that I can create an directory in the meaning of reference with an Client. I think you're confused: the reference name is simply an argument that tells LIST which results to return. For example, consider a hypothetical server with this mailbox hierarchy: /users/a/INBOX /users/a/foo /users/b/INBOX /users/b/xyzzy /pub/support #news.comp.protocols.imap If you're logged in as user a, INBOX refers to /users/a/INBOX; foo refers to /users/a/foo. /pub/support refers to /pub/support, as does ~b/xyzzy refer to /users/b/xyzzy. You can think of this as having a current working directory of /users/a. Just as a current working directory provides a context to interpret a file name, the reference name provides a context for LIST to interpret its mailbox name. That's all it does. Now read Mark's reply to you again. It'll probably make more sense. (You may also wish to glance at the examples in RFC 2342 as well.) -- ams
Re: Understanding Reference Names
I've never seen that I can create an directory in the meaning of reference with an Client. I think you're confused: the reference name is simply an argument that tells LIST which results to return. For example, consider a hypothetical server with this mailbox hierarchy: /users/a/INBOX /users/a/foo /users/b/INBOX /users/b/xyzzy /pub/support #news.comp.protocols.imap If you're logged in as user a, INBOX refers to /users/a/INBOX; foo refers to /users/a/foo. /pub/support refers to /pub/support, as does ~b/xyzzy refer to /users/b/xyzzy. You can think of this as having a current working directory of /users/a. The Current working directory is always the one of the connected user or not? So If I'm connected with user a, I will always have the current directory /users/a and the incoming client Reference Name will always be like this example: C: LIST INBOX In the meaning of RFC2342 it would be the Personal Mailbox, right? Assuming I want to go to an Shared Mailbox the Client would send an command like this: C: LIST public\ shared In the meaning of RFC2342 it would be a Shared Mailbox, right? Hope that I understood it right now, it's making me crazy from the beginning that I heard of Reference Name and read about Namespaces. I didn't know about RFC2342, because I didn't know anything about Namespaces. Thanks for that! -- thanks and regards Antonio Cambule STÜBER SOFTWARE www.stueber.de
Re: Understanding Reference Names
As an aside, I disapprove of the practices of mailboxes under INBOX and Trash mailboxes. IMAP does not prohibit either of these practices, but these practices are associated with substantial client and user confusion. Mark, would you expand on this a little, please? I am currently looking at a situation with Thunderbird. When one asks it to delete an IMAP mailbox, it tries to do so by moving it to the Trash. (I.e. using RENAME mailbox Trash/mailbox). This is a problem because some servers do not (and cannot) support a rename that has the effect of moving the mailbox within the hierarchy. Pete Maclean
Re: Understanding Reference Names
At 2004-06-02 16:25:07 +0200, [EMAIL PROTECTED] wrote: So If I'm connected with user a, I will always have the current directory /users/a and the incoming client Reference Name will always be The client can send whatever reference name it wants. OK, let me try to explain this differently. When you login as user a, suppose your current working directory is /users/a. Think of LIST as the equivalent of ls(1). Saying LIST /foo bar is like doing cd /foo; ls bar. That's the same as LIST / foo/bar: cd /; ls foo/bar. That's the same as «LIST /foo/bar»: cd ~; ls /foo/bar. That's the same as LIST /users/b/x /foo/bar: cd ~b/x; ls /foo/bar. And so on. You can think of the reference name argument to LIST as allowing you to change directory before doing the ls, thus providing a context for the interpretation of the mailbox name. Obviously, if the mailbox name is already fully-qualified (as in examples 3 and 4 above), the reference name does not affect its interpretation. -- ams
