🚀 go-pugleaf

In article <1992Oct14.205117.978@twg.com> "David Herron" <david@twg.com> writes:
>Nope.. wrong.. these protocols are too stable enough ;-).  Though your
>inclusion of IMAP v3 into that list isn't correct since the RFC which
>is labeled IMAP v3 is not part of the Official IMAP development stream.

There is no indication whatsoever in the content _of the RFCs_ that there
_is_ such a thing as the "Official IMAP development stream", or that IMAP2
is part of it and IMAP3 isn't.  Now I have heard lots of comments from
Stanford and Washington I sort of understand what's going on, but as far
as the two RFCs are concerned they have identical status.

>Oh?  Just buy a TCP/IP implementation for your system.  There seems
>to be dozens of companies with 'em ... ;-)

Yeah, I've got three on my hard disc right now!  (Couldn't get CUTCP to
work until I realised I had PC/TCP's kernel TSR in my AUTOEXEC.BAT, this
never happens on Unix, mutter mutter) It is certainly not trivial 
maintaining TCP for thousands of users with different Ethernet cards.
Some IP-based packages aren't suited to LAN systems,
(e.g. they assume that user <-> IP address is a constant mapping, and
don't have separate "system", "machine" and "user" configuration files.  
Microsoft Mail, cc:Mail and the other products you mentioned are 
_definitely_ designed with LANs in mind.

>P7 is part of the X.400 protocol suite.  It is sort of equivalent
>to POP in capability.  It is mostly a maildrop, but does have some
>intelligence in the entity which handles the maildrop as delivery
>notification messages are to be generated there.  It doesn't allow
>for more than one folder or any other sort of message grouping
>in the P7 server.

P7 is the MOTIS (ISO 10021, CCITT X.400) Message Store Access Protocol.
Its is "sort of equivalent to"

      SMTP (the Message Submission Service)
 plus POP/IMAP (the Message Retrieval Service)
 plus logging on to Unix to change one's POP/IMAP password
 plus logging on to Unix to change one's .forward file 
      (part of the Message Administration Service) 

Because submission and retrieval are integrated, you can do things like
forwarding messages directly from the message store.

>I don't understand why a P7 server using MIME is a cool/nifty idea ...
>MIME is a cool/nifty idea by itself regardless of which mailbox access
>protocol you use.  But the X.400 world already has its own multi-body-part
>standard so why would they want to use MIME?

Because MIME has a wider range of content-encodings (even if some of them
are rather parochial - American ISDN, for goodness' sake!), and also has
a concept of 'alternate' and 'parallel' representations, which IPMS 
(i.e. the "e-mail" application on top of the underlying X.400/MOTIS message
transfer application) does not (yet).

Also, a MIME file can be extracted out as a unit when the message leaves
the OSI domain (assuming a gateway offering an OSI stack talking P7 on one
side, and a lightweight LAN protocol on the other, which is the way some
people are going) and interpreted by a workstation as a text file rather
than a BER-encoded object.

>And .. talking about reliable servers .. Why would a P7 server be
>more/less reliable than, say, an IMAP server?

Because P7 is built on top of, among other things, the OSI Reliable 
Transfer Service (RTS). Imagine a situation where you are trying to retrieve
a 100Mb MIME message over a cellular phone link that goes down every time
you go under a bridge. Potentially, you have a better chance of eventually
transferring the message with P7 than with SMTP, since SMTP requires a 
TCP connection to be maintained throughout the transfer of the message. 

Also, there is more incentive to test OSI products in formal ways, and more
opportunities to do so.

p.s. isn't it strange that someone in the MUA business has never heard of P7?