MBOX-Line: From jjmckay at comaxis.com  Tue May 27 13:22:12 2014
To: imap-protocol@u.washington.edu
From: Jeff McKay <jjmckay@comaxis.com>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] Creating subfolders in Gmail
In-Reply-To: <CACU8CfTk-Ojb5ub1md+GBodkY0j=UebmMd6oMP1CHLUgGFRjQA@mail.gmail.com>
References: <537FEFE5.4040103@comaxis.com>
	<53801B87.29010.51A00D5@David.Harris.pmail.gen.nz>
	<CACU8CfTUfhSjsym0wayFQOko=8d6_VWercCkzp6HrVXoW-mfSw@mail.gmail.com>
	<5384E40C.3070907@comaxis.com>
	<CACU8CfTk-Ojb5ub1md+GBodkY0j=UebmMd6oMP1CHLUgGFRjQA@mail.gmail.com>
Message-ID: <5384F3F4.5090507@comaxis.com>

It is the second case I am trying to implement, where in the UI, I can 
see bar nested under foo.  That does not appear to work
as you stated.   Here is the trace of me creating two folders:

<send 24>A103 CREATE "Migrated"
<recv 17>A103 OK Success
<send 43>A104 CREATE "Migrated/BUDGET CALCULATION"
<recv 17>A104 OK Success
<send 89>A001 APPEND "Migrated/BUDGET CALCULATION" (\Seen) "18-Apr-2014 
09:49:00 -0700" {135007}
<recv 12>+ go ahead

When I get a new list, I see this:

* LIST (\HasChildren) "/" "Migrated"
* LIST (\HasNoChildren) "/" "Migrated/BUDGET CALCULATION"

So it would have appeared to work, but, the UI displays only 
"Migrated/BUDGET CALCULATION".    There is also another
label called "[IMAP]/Migrated" with nothing in it.


On 5/27/2014 12:40 PM, Jamie Nicolson (???) wrote:
> I'm not sure what you mean by "single top level folder". "foo/bar" has 
> the hierarchy delimiter in it, so from IMAP's point of view it is a 
> nested folder.
>
> If you want to be able to store messages in "foo/bar", but not "foo", 
> you can CREATE foo/ and then CREATE foo/bar. The first CREATE will be 
> a no-op on Gmail, but will succeed with OK. The second CREATE will 
> result in this folder layout:
>
> * LIST (\Noselect \HasChildren) "/" "foo"
> * LIST (\HasNoChildren) "/" "foo/bar"
>
> Now you can COPY and APPEND messages to foo/bar. If you also want to 
> be able to store messages directly in foo, you just have to CREATE foo 
> (without the hierarchy delimiter suffix). You can do this before or 
> after creating "foo/bar". Then you'll have this:
>
> * LIST (\HasChildren) "/" "foo"
> * LIST (\HasNoChildren) "/" "foo/bar"
>
> The web UI displays these two cases differently. In the first case 
> (where foo/bar is selectable but foo is \Noselect), we show "foo/bar" 
> as a standalone label. In the second case (where foo/bar and foo are 
> both selectable folders), we display bar nested under foo. This is 
> just a quirk of the web UI.
>
>
> On Tue, May 27, 2014 at 12:14 PM, Jeff McKay <jjmckay@comaxis.com 
> <mailto:jjmckay@comaxis.com>> wrote:
>
>     Yes that is what I get also, sorry for misstating the error
>     message.  I am still unclear though about how to create a folder
>     with a sub-folder.  You said that the correct syntax should be:
>
>     CREATE "foo/bar"
>
>     which creates a single top level folder called "foo/bar".   I know
>     that you want to support being able to create folder names
>     that contain the hierarchy delimiter,  but there seems to be a
>     conflict here.
>
>
>     On 5/27/2014 11:09 AM, Jamie Nicolson (???) wrote:
>>     I don't see any error message in the Gmail code for "hierarchy
>>     character ignored". When I try to reproduce this, I see something
>>     different:
>>
>>     a create foo/
>>     a OK [CANNOT] Ignoring hierarchy declaration (Success)
>>
>>     This seems to follow 6.3.3.
>>
>>
>>     On Fri, May 23, 2014 at 9:09 PM, David Harris
>>     <David.Harris@pmail.gen.nz <mailto:David.Harris@pmail.gen.nz>> wrote:
>>
>>         On 23 May 2014 at 18:03, Jeff McKay wrote:
>>
>>         > Has something changed with how Gmail handles the hierarchy
>>         character
>>         > in the CREATE command? I am sure I had this working at one
>>         point, but
>>         > now:
>>         >
>>         > CREATE "TopLevelFolder/"
>>         >
>>         > generates "NO hierarchy character ignored"
>>
>>         The server would appear to be in error. See RFC3501, section
>>         6.3.3 ("The
>>         Create Command"):
>>
>>               If the mailbox name is suffixed with the server's hierarchy
>>               separator character (as returned from the server by a LIST
>>               command), this is a declaration that the client intends
>>         to create
>>               mailbox names under this name in the hierarchy.  Server
>>               implementations that do not require this declaration
>>         MUST ignore
>>               the declaration.  In any case, the name created is
>>         without the
>>               trailing hierarchy delimiter.
>>
>>         This seems pretty unambiguous to me, but no doubt there's an
>>         alternative
>>         reading I haven't considered (there usually is). I assume
>>         GMail actually
>>         *does* support submailboxes (I don't personally use it)?
>>
>>         Interestingly, the example for section 6.3.3 is an almost
>>         exact match to your
>>         report:
>>
>>               Example:
>>                  C: A003 CREATE owatagusiam/
>>                  S: A003 OK CREATE completed
>>
>>         Note that there is a reverse condition to this where a server
>>         may report a
>>         mailbox with a trailing hierarchy delimiter as part of a LIST
>>         response; I
>>         confess I've never understood exactly what that means
>>         (Exchange used to
>>         do it and may still do so) - Mark Crispin once explained it
>>         to me as having
>>         some meaning related to a test for existence, but I couldn't
>>         grasp what he
>>         meant.
>>
>>         Cheers!
>>
>>         -- David --
>>
>>         ------------------ David Harris -+- Pegasus Mail
>>         ----------------------
>>         Box 5451, Dunedin, New Zealand | e-mail:
>>         David.Harris@pmail.gen.nz <mailto:David.Harris@pmail.gen.nz>
>>                    Phone: +64 3 453-6880 <tel:%2B64%203%20453-6880> |
>>         Fax: +64 3 453-6612 <tel:%2B64%203%20453-6612>
>>
>>         Real newspaper headlines from U.S. papers:
>>            TRAFFIC DEAD RISE SLOWLY
>>
>>
>>
>>         _______________________________________________
>>         Imap-protocol mailing list
>>         Imap-protocol@u.washington.edu
>>         <mailto:Imap-protocol@u.washington.edu>
>>         http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>
>>
>>
>>
>>     _______________________________________________
>>     Imap-protocol mailing list
>>     Imap-protocol@u.washington.edu  <mailto:Imap-protocol@u.washington.edu>
>>     http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
>     _______________________________________________
>     Imap-protocol mailing list
>     Imap-protocol@u.washington.edu <mailto:Imap-protocol@u.washington.edu>
>     http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140527/b85ea21e/attachment.html>
