Re: Mulberry gone, now what?

On Fri, 7 Oct 2005, usenet@xxxxxxxxxx wrote: 
But the problem is that the client can't "determine what sort of
naming and hierarchy conventions ....", the server dictates it in
general.


I'm not sure which meaning of "determine" you intend here.

If by "determine" you mean "decide", then that is correct; in IMAP the server (and by extension the server management) decides the naming and hierarchy conventions, not the client.

Over a decade ago, this was considered to be a feature, not a bug. The idea here was that all clients of the server would be made to behave in the same way; and thus the server provider's helpdesk doesn't need to know how a particular client works.

This conflicts with the desire of client authors to have all servers accessed by the client behave in the same way; and thus the client vendor's helpdesk doesn't need to know how a particular server works.

The sad result was that both sides refused to compromise. At least one client author told me that he did not care what the server exported; his policy was that his client defined the one true way of hierarchy and naming, regardless of server policy.

The lesson is that it is a mistake to allow either server or client to decide naming and hierarchy policy; the protocol must decide. But it wasn't until the widespread deployment of URIs that this was generally recognized (not to mention any sort of concensus of what the one true naming and hierarchy should look like!).


If by "determine" you mean "figure out the server's naming and hierarchy conventions", IMAP provides the means to do this. The problem is that many clients don't use these mechanisms and/or ignore what these mechanisms tell them.


None of this, by the way, is an attribute of IMAP; naming and hierarchy was glommed onto IMAP after the fact. IMAP2 had none of this nonsense; and I opposed the addition of the mailbox management commands to IMAP. I always felt that a separate protocol should manage mailboxes, leaving IMAP to focus on its original design of managing messages within a mailbox.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
.

Relevant Pages

  • Re: Mulberry gone, now what?
    ... >> IMAP allows a great deal of latitude in much of the specification. ... > IMAP permits the server to export whatever sort of namespace and naming ... > IMAP declares that they're all good, and provides a means for the client ... > to determine what sort of naming and hierarchy conventions that the server ...
    (comp.mail.imap)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
  • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
    ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
    (Full-Disclosure)
  • Re: What doesnt lend itself to OO?
    ... > rather than client code. ... no way to do that without also touching the object with clock semantics ... will not encapsulate both clock semantics and network semantics. ... The server can do whatever it wants ...
    (comp.object)