re: POP, PCmail, IMAP what next?

[Tim Kehres <[e-mail]>]

Mark,

> As Mr. IMAP, I'm not sure that a single protocol can solve all the world's
> problems, nor that it's really desirable to try.  I'm open-minded to
> suggestions, though.

I would tend to agree with this statement, at it relates to message access
protocols that support a single transport protocol type.   On the other hand,
if we could come up with an approach where remote clients can send/receive
messages using multiple addressing types (822, X.400, Fax, etc), this would
be quite useful.   Of course, for this to work, the server message store would
have to have the ability to route to more than one transport type.

In regard to access protocols that support 822 - we have several in place
already - many of which have been shown to be good (the POP and IMAP protocols
come to mind initially).  I'm not sure that we gain anything by defining 
another protocol to compete with these.

> A summary of the current protocols:
> 
> P7 is POP done wrong, as is much of the rest of ISO.

P7, although of questionable use as a protocol to use in a real world
situation, has built into it a very good model of how arbitrary queries 
can be performed.  Most of the 822 based access protocols do not allow for
this much flexibility.

In addition P7 (together with P3) also define a formal method for message
submission, something that is left out of the 822 based access protocol specs.

> IMAP.....
:
>                                                        It is also the only
> protocol that even tries to address the multinational character set problem

This is (IMHO) a very important area.  Any new access protocol should be able
to handle multibyte character sets.  Of course, if the protocol has to be
tied to a particular character encoding scheme, its usefullness would be
diminished.

> The problem as I see it is that POP is all that some people need, and anything
> more is too much of an implementation burden.  But, POP is way inadequate for
> other people, who have different problems to solve.

The environments that we have been looking at use many different transport
protocols, but the users don't want to have to use different UA's for each
transport.  Encoding one addressing format into a foreign addressing format
(X.400 O/R names for instance in an 822 format), is also not desirable.  It
also forces the use of gateways, which using a different message storage 
model, might not be necessary.

Another thing to consider is that we are moving towards integration of
email with other applications.  Although I don't think that it makes any
sense to integrate the mail access protocol with other functions (with the
exception of BBS support), it might make sense to look at several applications
taht are perceived as being common canidates for being email enabled, and 
make sure that the any new access protocol is compatible.

In summary, I believe that following goals are desirable:

   o  Message access protocol is independent of the underlying transport
      protocols (different addressing formats may limit this however)

   o  Powerfull access methods are provided (SQL like?).

   o  Provides for an environment that encourages the use of different
      tranports, rather than competing with them (I'd rather find a way
      to work with cc:Mail rather than converting their customer base for
      instance).

   o  International character support (multibyte character encodings).

   o  Provides an environment that can easily accomodate email enabled
      applications.

Implied in the above goals is a model of what the server message storage
module should look like (from an I/O and external data representation 
perspective).  This is a significant departure from what the existing
822 based access protocols currently define.  

Comments/suggestions???

Best Regards,

Tim Kehres