MBOX-Line: From jjmckay at comaxis.com  Tue May 27 12:14:20 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: <CACU8CfTUfhSjsym0wayFQOko=8d6_VWercCkzp6HrVXoW-mfSw@mail.gmail.com>
References: <537FEFE5.4040103@comaxis.com>	<53801B87.29010.51A00D5@David.Harris.pmail.gen.nz>
	<CACU8CfTUfhSjsym0wayFQOko=8d6_VWercCkzp6HrVXoW-mfSw@mail.gmail.com>
Message-ID: <5384E40C.3070907@comaxis.com>

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
> 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/898c6f72/attachment.html>
