On Fri, 19 Sep 2003, Arnt Gulbrandsen wrote:
(B> > That is an extremely harmful position to take.
(B> Oh?
(B
(BYes. It is extremely harmful to take the position that IMAP defines a
(Bproprietary homogenous IMAP mail store. It is extremely harmful to take
(Bthe position that any mail store that does not match precisely with this
(Bproprietary IMAP mail store is somehow deficient.
(B
(BIMAP is designed to be a means to export many different mail stores, with
(Bnone superior or inferior to the other. In some cases, IMAP smoothes over
(Bthe differences between different mail stores. In others, IMAP announces
(Bthe differences.
(B
(BThis was the design intent of IMAP from the very beginning. Heterogenuity
(Bis a good thing.
(B
(B> IMAP would seem to define at least two things: there is an MSN, and
(B> there is a UID and associated UIDVALIDITY. (Yes, I'm aware that your
(B> code sends UIDNOTSTICKY for some mailboxes, but that's not in the
(B> standard.)
(B
(BUIDs were not in the original IMAP design.
(B
(BA server *is* permitted to have non-sticky UIDs. That is the entire
(Breason why UIDVALIDITY exists: to inform the client that the UIDs failed
(Bto stick.
(B
(BSome people requested UIDNOTSTICKY as a means of giving a client advance
(Bwarning that this would happen. I don't think that it is really all that
(Buseful.
(B
(B> > IMAP goes to great lengths to inform the client about the semantics of
(B> > the server's particular mail store, so that the client can make
(B> > intelligent decisions in dealing with it.
(B> Great lengths? My na$Bo(Bve impression is rather the opposite - it presents
(B> a single, fairly simple view.
(B
(BI doubt that anyone who reads the rules about hierarchy and LIST would
(Bcall it "simple."
(B
(B> Consider mailbox names. An IMAP server
(B> does not tell a client:
(B> 1. whether mailbox names are case sensitive
(B> 2. what the maximum length of a mailbox name is
(B> 3. whether any names are reserved, and if so, which
(B> 4. which set of characters are permitted in mailbox names
(B> 5. how many mailboxes may be present as children of a single mailbox
(B> 6. which particular restriction caused the rejection of a CREATE
(B
(BYou just proved my point. A client has to deal with a great deal of
(Bheterogenuity in the server's mail store.
(B
(BIMAP does tell the server the following:
(B 1) a list of existing names which match a pattern, a current path
(B in the hierarchy, and the server's own default path (hierarchy root
(B or some per-user root)
(B 2) a list of subscribed names which match a patter, a current path
(B in the hierarchy, and the server's own default path
(B 3) the root of a hierarchy
(B 4) the hierarchy delimiter (if there is hierarchy)
(B 5) on a per-name basis, the semantics of the hierarchy.
(B
(BThat is quite a lot, and there are many implications to this:
(B
(BHierarchies can be "hard" (such as UW imapd's export of the UNIX
(Bfilesystem) or "soft" (such as Cyrus).
(B
(BA hard hierarchy is one in which each level is its own named object. Such
(Bobjects may be terminal and/or have other levels of hierachy. Each
(Bnon-terminal level contains its subordinate levels. Thus, with
(Boffice/secret and office/secret/top, there is an object called "office"
(Bthat contains an object called "secret", and "secret" in turn contains an
(Bobject called "top".
(B
(BA soft hierarchy is basically a non-hierarchical (flat) namespace in which
(Ba particular character is defined by convention to be the delimiter for
(B"%" in LIST. There is no relationship between office/secret and
(Boffice/secret/top other than the first 13 octets being the same. Since
(Bthe namespace is basically flat, the terminal vs. other levels of
(Bhierarchy distinction has no meaning; office/secret does not actually
(B"contain" office/secret/top in any way.
(B
(BWhich of these two is superior is a matter of religion. For the purposes
(Bof this discussion, it is irrelevent; IMAP supports both.
(B
(B> The client has to deal with NO on CREATE anyway, so the server should
(B> not be wasting network bandwidth and client memory with saying
(B> "such-and-such name can never be of use to you in any way".
(B
(BA \NoSelect name with no children is certainly "never of no use". In
(Bfact, it is very useful; you can create names inside it.
(B
(BA client needs to know about such names. Otherwise, a client must do two
(BRTTs if a \NoSelect with no children foo/ does not show up in foo/%, since
(Bthe client does not know if an empty response means "foo does not exist"
(Bor "foo is empty".
(B
(BIf you feel that it is unreasonable for LIST to distinguish between "does
(Bnot exist" and empty, please tell the developers of UNIX to fix this bug
(Bin ls:
(B % ls foo
(B ls: foo: No such file or directory
(B %
(B
(B-- Mark --
(B
(Bhttp://staff.washington.edu/mrc
(BScience does not emerge from voting, party politics, or public debate.
(BSi vis pacem, para bellum.
