On Sun, Jan 16, 2000 at 02:09:00PM +0100, Claus F�rber wrote:
> Bruce Guenter <[EMAIL PROTECTED]> schrieb/wrote:
> > First place to start is to figure out what is actually necessary. In a
> > lot of cases, POP3 with a few extensions should be perfectly adequate,
> > but it is necessary to know what the needs actually are.
>
> I don't think it's a good idea to overload the POP3, which is a last-
> step _delivery_ protocol with mailbox access.
I'm thinking in a conceptual sense -- ignore the syntax and everything
else and consider what it provides: a method of listing the contents of
a mailbox (by unique ID), seeing what's new, and transferring the mail
from a single mailbox to a client. No frills. However, more is
necessary. The biggest being that the system should be designed to keep
the mail on the server rather than assuming it should be downloaded.
> No, I'd rather start with IMAP, but leave out:
>
> . the requirement that persistent IDs must be numeric and subsequent
> (just use opaque strings instead),
> . the very complex syntax,
> . response fields that are filled in from header fields (instead pass
> the header fields raw to the client),
Agreed. In otherwords, simplification of the requirements on the
server (and in part, the client).
> . the variable hierarchy delimiters (instead, use iURL syntax with %-
> encoding).
Forgive my ignorance, but how is an "iURL" different from an "URL"?
> Some simplicifations and changes:
>
> . have special folders labelled with out-of-band data for each mailbox.
> I.e., don't have a folder "inbox", but an unnamed folder which has the
> function inbox. Same for other commonly used folders such as sent,
> templates, unsent, drafts etc. The name of that folder is left to the
> UA programmers. So you would have user folders and "special" folders.
Too many special cases. That's not a simplification at all. The
simplification is no special cases for mailbox access. The incoming
mail (for cooperation with other programs) could be the unnamed mailbox,
or a mailbox with a 0-length name.
> Some additional features that would be nice:
>
> . server-side filering (optional)
This seems to be a delivery issue rather than a content retrieval issue.
Besides, the client could examine the headers, and move the mail into a
different folder.
> . Storage of metadata such as user name etc.
Standardized storage of configuration data seems to be a definite
requirement. It should be flexable enough to allow client
implementations to put what they'd like there as well.
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
