Right, not all system folders are exposed through LIST. Even if they were
it wouldn't help, because *all translations* of the name are affected, not
just the translation that your user happens to use.
To reiterate, this doesn't prevent you from creating the folder, nor does
it change the way it appears in IMAP. It only affects how that IMAP-created
folder will show up in the web UI.
On Tue, May 27, 2014 at 4:58 PM, Jeff McKay <jjmckay@comaxis.com> wrote:
> 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> 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 <%2B64%203%20453-6880> | Fax: +64 3
>>>>>> 453-6612 <%2B64%203%20453-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/20140528/93182d7b/attachment.html>