265 lines
12 KiB
Plaintext
265 lines
12 KiB
Plaintext
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>
|