On Mon, 15 Sep 2003, Mark Crispin wrote: > On Mon, 15 Sep 2003, Rob Siemborski wrote: > > While I think its somewhat bizarre to report a leaf mailbox that is > > \NoSelect and doesn't have any children, I can atleast appreciate why this > > is necessary in some environments. However, as you say, such a case does > > not apply to all servers (and since Timo's original question was about a > > dual-use mailbox your statement seemed much broader than I guess you > > intended). > > OK, so we agree that it is necessary behavior in some environments. Do we > also agree that even in those environments in which it is unnecessary and > arguably extraneous, it is harmless?
I suppose this depends on your definition of harmless. I wouldn't want a server that doesn't do this declared at all noncompliant. I do not believe it is harmless in pathological cases like LIST "*/%" where the output could be needlessly doubled by such behavior. Of course, this is a pathological case. > I agree that there is probably no reason for a client to care whether foo/ > is returned for foo/% when there are children; and thus, if the server > does not have the \NoSelect w/ no children case, it's probably alright if > the server omits foo/ from the list. Indeed, I'd argue such a server (which does not have the \NoSelect with no children case) is equally correct with an implementation that does not omit foo/ from the list, since none of this special treatment of trailing hierarchy delimiters (outside of CREATE) is discussed in the protocol specifications. > This sounds like we may have the start of material for yet another > installation of an IMAP folklore (a.k.a. "implementation recommendations") > document. It seems that there are quite a few questions which don't > become clear without considering environments other than your own. It's > probably unreasonable to make all implementors think all of these through. I think this is reasonable regardless. IMAP is a very complicated protocol, documentation to make good implementations easier to create is always welcome. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * [EMAIL PROTECTED] * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK-----
