MBOX-Line: From nicolson at google.com  Tue May 27 14:14:51 2014
To: imap-protocol@u.washington.edu
From: =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= <nicolson@google.com>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] Creating subfolders in Gmail
In-Reply-To: <CAO3aFYv=FB5TyxMU3yRi47rpvHcS8e5aieQMDSbS4U48NUtvCQ@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>
Message-ID: <CACU8CfQeuPaGmn=OpKXsQphqBkTUCq+4Nsb6HB4XcY=r-upXLQ@mail.gmail.com>

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> 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> 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> 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>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> 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
>>>>>            Phone: +64 3 453-6880 | Fax: +64 3 453-6612
>>>>>
>>>>> Real newspaper headlines from U.S. papers:
>>>>>    TRAFFIC DEAD RISE SLOWLY
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Imap-protocol mailing list
>>>>> Imap-protocol@u.washington.edu
>>>>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Imap-protocol mailing listImap-protocol@u.washington.eduhttp://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Imap-protocol mailing list
>>>> Imap-protocol@u.washington.edu
>>>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Imap-protocol mailing list
>> 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/69f5956e/attachment.html>
