wasm-demo/demo/ermis-f/imap-protocol/cur/1600095026.22635.mbox:2,S

214 lines
8.6 KiB
Plaintext

MBOX-Line: From jjmckay at comaxis.com Tue May 27 13:56:53 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: <CACU8CfQFeSgVxhHXjtguuso7tYUw8wEVMZkRxcoqKxLvo2+UKQ@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>
Message-ID: <5384FC15.9060307@comaxis.com>
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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140527/3eba4a3e/attachment.html>