MBOX-Line: From jjmckay at comaxis.com  Tue May 27 16:58:54 2014
To: imap-protocol@u.washington.edu
From: Jeff McKay <jjmckay@comaxis.com>
Date: Fri Jun  8 12:34:53 2018
Subject: [Imap-protocol] Creating subfolders in Gmail
In-Reply-To: <CACU8CfQeuPaGmn=OpKXsQphqBkTUCq+4Nsb6HB4XcY=r-upXLQ@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>
	<5384F3F4.5090507@comaxis.com>
	<CACU8CfQFeSgVxhHXjtguuso7tYUw8wEVMZkRxcoqKxLvo2+UKQ@mail.gmail.com>
	<5384FC15.9060307@comaxis.com>
	<CAO3aFYv=FB5TyxMU3yRi47rpvHcS8e5aieQMDSbS4U48NUtvCQ@mail.gmail.com>
	<CACU8CfQeuPaGmn=OpKXsQphqBkTUCq+4Nsb6HB4XcY=r-upXLQ@mail.gmail.com>
Message-ID: <538526BE.1030705@comaxis.com>

The LIST command will show the various system folders, under the top 
level "[Gmail]".  Trash is there, but I don't see
"Migrated".  I can avoid using folder names from that subset, but it 
does not seem to be complete.

On 5/27/2014 2:14 PM, Jamie Nicolson (???) wrote:
> Unfortunately, no. It's a big set, consisting of every translation of 
> every system label. For example, you can't create a label named 
> "Trash" (US English), and neither can you create one named "Bin" (UK 
> English) or "Corbeille" (French). Since our translations are subject 
> to change, and we may add system labels in the future, we don't want 
> to publish a static list somewhere that would quickly become out of 
> date. It might be possible to add a special result code to the CREATE 
> response indicating that the folder name will be aliased. Would that 
> be useful?
>
>
> On Tue, May 27, 2014 at 2:00 PM, Michael Grinich <mg@mit.edu 
> <mailto:mg@mit.edu>> wrote:
>
>     Is there a list of these reserved folder names anywhere public?
>
>
>     On Tue, May 27, 2014 at 1:56 PM, Jeff McKay <jjmckay@comaxis.com
>     <mailto:jjmckay@comaxis.com>> wrote:
>
>         Thanks. Bad luck and ignorance on my part to have picked a
>         reserved folder name to test, but it's good to know that it works
>         the way I thought it did.
>
>
>         On 5/27/2014 1:39 PM, Jamie Nicolson (???) wrote:
>>         Ah, yes, "Migrated" matches a Gmail system label (like Inbox,
>>         Sent, etc), and therefore it is aliased to [IMAP]/Migrated in
>>         the web interface. Note that you can't even create a label
>>         named "Migrated" in the web interface; you'll get the error,
>>         "The label name Migrated is invalid." The same thing would
>>         happen if your top-level folder were named Sent, Spam, Trash,
>>         etc. This shouldn't effect how things work in IMAP, but will
>>         change how they are displayed in the web interface.
>>
>>
>>         On Tue, May 27, 2014 at 1:22 PM, Jeff McKay
>>         <jjmckay@comaxis.com <mailto:jjmckay@comaxis.com>> wrote:
>>
>>             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
>>>
>>>
>>
>>
>
>
>         _______________________________________________
>         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/5c2b26e2/attachment.html>
