InfoMagic Internet Tools 1993 July/Internet Tools.iso/RockRidge/mail/pine/imap_archive/text0010.txt

Text File | 1993-07-02 | 20.4 KB | 371 lines

> Most of us consider `mail forwarding' to mean encapsulating the message within
> another message.  You would be putting user interface and sending within a
> message.  `Remailing' in this fashion may be reasonable though.

X.400 (which I honestly believe that everyone outside the USA will be using
in 10, if not 2 years' time) allows optional added body parts for both
kinds of what it calls `forwarding'. For auto-forwarding the text is
supplied in a management operation, for manual forwarding a new message is
submitted with a parameter referring to "a message that is already in the
MS which is to be combined with the submitted message body". But I accept
that it is possible to define a private protocol for auto-forwarding
control, and to fetch and re-send a manually forwarded message.

> I'm not convinced that draft messages belong on the IMAP server as opposed to
> `home directory' server.  What if the IMAP server is overseas (this is a real
> world situation for me!)?  Putting it in IMAP seems to be false `efficiency'.

I wasn't really thinking of efficiency here. Even within a campus, a user
may want to send mail from machines that have do not have a common file
system, i.e. for which the only interconnectivity is IP. Having their draft
messages in a common pool is _added function_; having the draft-message
management functions integrated with other parts of the mail protocol
simplifies things and may also add function. E.g. IMAP2's SEARCH and FETCH
commands are mostly equally applicable to draft messages; it would be
duplication of effort to have identical commands in a separate server.
IMAP2 is already ideal for managing a message pool. All it needs is some
way to insert and update the drafts.

> Please consider bringing it up to the IETF-REMMAIL group.

Ok. But I hope readers will forgive me for reminding the list that the
effort in implementing mail these days is not in designing protocols, but
in writing user-friendly Windows and Mac clients. The fact that the PC POP
clients still haven't got IMAP2 support suggests that any wonderful new
mail protocol from the IETF will be of little use to the average user for a
long time yet, _unless_ it extends an existing protocol. And to me, IMAP2
seems the best candidate.

(I think I've made my point - time for someone else to have a go!)
--
Alasdair Grant                                       [e-mail]
MVS Systems Group / Small Systems Integration Group         [phone]
University Computing Service                          [phone] (fax)
Pembroke St., Cambridge CB2 3QG, UK
From [e-mail]  Thu Sep  3 09:31:55 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA14662; Thu, 3 Sep 92 09:31:55 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA20814; Thu, 3 Sep 92 09:31:50 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from nexus.yorku.ca by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA20804; Thu, 3 Sep 92 09:31:44 -0700
Received: from localhost ([127.0.0.1]) by nexus.yorku.ca with SMTP id <9222>; Thu, 3 Sep 1992 12:31:36 -0400
To: [e-mail]
Subject: Re:  re  IMAP2 futures?
Date:     Thu, 3 Sep 1992 12:31:25 -0400
From: [e-mail]
Message-Id: <[e-mail]>

In   <[e-mail]>  you write:
[in part of a larger discussion on the server function-set]
| However, this is merely `for efficiency' since the same resulting function can
| be accomplished by existing mechanisms.  This is a good reason to reject it;
| any function which by its fundamental nature is optional and exists only for
| `efficiency' tends not to get implemented widely.  You can either end up with
| a lot of protocol baggage or recognize reality.  Most modern protocol design
| does the latter.

  I too would argue that little of the added functionality belongs in the
imap protocol.  It is all too easy to discover you're specifying the
transitive closure of all the states of all the subsystems, unless you try
quite strongly for separation of concerns.
  Failing to do so ends up in exponential increase in complexity and
implementability.  Ie, an unused protocol.

  In concrete terms, it's a bad idea to add too many things to a protocol
because you end up trying to add things which interact in wierd and
wonderous ways. For examplem renaming a mailbox can result in the state of
the MUA suddenly become inconsistant. If the MUA doen't knows the
implications of the operations of the mailbox management system, it can
trivially fail, to the detriment of the user.
  This is already possible in standard IMAP: the imap-using MailManager MUA
reports the mysterious shrinking of a mailbox when someone inadvertantly uses
/bin/mail.  It deals with it reasonably, but has no knowlege of why it
happened, and can only report the bare fact.

  To a non-technical user, this means that mail is unreliable: after all,
it disappears without warning!

  As an example of good practice, ftp quite carefully uses separate streams
for commands and data, too keep from having to contain its own multiplexor.
If one wants a muliplexor, one uses the one at a lower level in the protocol
stack.

( This becomes difficult when talking to very single-threaded machines like
PCs and my old CP/M-80 box.  If one has multitasking and slip, one has a
multiplexor.  If one has only uucp or kermit, one hasn't.
  I once did an application that multiplexed over kermit on a single-task
cp/m-80 system.  At the client end, the coding was horrid: it really had to
be aware of too many things at once.)

  On a multi-tasking machine I would separate the applications as far as
possible, and optionally provide a multiplexor and transport layer **if
and only if** I couldn't get an adequate one elswhere.
  Kermit is pretty easy to multiplex, if you must know.  Just don't try to
do it on a z80 unless you really like pain.

--dave
From [e-mail]  Thu Sep  3 10:58:12 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA17098; Thu, 3 Sep 92 10:58:12 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA21814; Thu, 3 Sep 92 10:58:04 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA21808; Thu, 3 Sep 92 10:58:02 -0700
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA03462> for [e-mail]; Thu, 3 Sep 92 13:57:56 EDT
Received: via switchmail; Thu,  3 Sep 1992 13:57:54 -0400 (EDT)
Received: from nifty.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.oedZ7:a00WA7Qeb04S>;
          Thu,  3 Sep 1992 13:56:29 -0400 (EDT)
Received: via niftymail; Thu, 3 Sep 1992 13:56:24 -0400 (EDT)
Date: Thu, 3 Sep 1992 13:56:23 -0400 (EDT)
From: Chris Newman <[e-mail]>
Subject: re: IMAP2 futures?
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-Id: <[e-mail]>

In message <[e-mail]>,
 A Grant <[e-mail]> writes:
>I wasn't really thinking of efficiency here. Even within a campus, a user
>may want to send mail from machines that have do not have a common file
>system, i.e. for which the only interconnectivity is IP. Having their draft
>messages in a common pool is _added function_; having the draft-message
>management functions integrated with other parts of the mail protocol
>simplifies things and may also add function. E.g. IMAP2's SEARCH and FETCH
>commands are mostly equally applicable to draft messages; it would be
>duplication of effort to have identical commands in a separate server.
>IMAP2 is already ideal for managing a message pool. All it needs is some
>way to insert and update the drafts.

It seems to me that the IMAP2bis "APPEND" command could be used to do
what you want.  Using a convention that the folder called "drafts"
holds draft messages, APPEND could be used to add new or updated
drafts, and FETCH/PURGE could be used to get them and delete them.

APPEND is completely unsuitable, however, for any sort of mail
delivery, as it doesn't provide for an envelope.  (I think mail
delivery is outside the scope of IMAP2, as there are existing simple
protocols to do what is necessary).

        - Chris Newman
        Computing Services, Carnegie Mellon University
From [e-mail]  Thu Sep  3 11:34:28 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA18419; Thu, 3 Sep 92 11:34:28 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA22256; Thu, 3 Sep 92 11:34:19 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA22250; Thu, 3 Sep 92 11:34:17 -0700
Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk
          with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <[e-mail]>;
          Thu, 3 Sep 1992 19:34:04 +0100
Date: Thu, 03 Sep 92 19:33:52 BST
From: A Grant <[e-mail]>
To: [e-mail]
Subject: re: IMAP2 futures?
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>

> It seems to me that the IMAP2bis "APPEND" command could be used to do
> what you want.  Using a convention that the folder called "drafts"
> holds draft messages, APPEND could be used to add new or updated
> drafts, and FETCH/PURGE could be used to get them and delete them.

What APPEND command? Has IMAP2bis changed in the last few months?
Where is the new draft, please? (I got it out of the imap distribution
last time.)

> APPEND is completely unsuitable, however, for any sort of mail
> delivery, as it doesn't provide for an envelope.  (I think mail
> delivery is outside the scope of IMAP2, as there are existing simple
> protocols to do what is necessary).

Nobody is asking for mail delivery, just mail submission.
Any system that handles draft messages ought to handle the envelope;
a user should not have to set up the envelope each time. In other words,
a managed draft message should be able to be "ready for sending".
If APPEND is not suitable for mail submission, it will not be suitable
for managing draft messages.
From [e-mail]  Thu Sep  3 12:35:40 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA20043; Thu, 3 Sep 92 12:35:40 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA22949; Thu, 3 Sep 92 12:35:32 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA22943; Thu, 3 Sep 92 12:35:23 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
    (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA05011; Thu, 3 Sep 92 12:35:17 PDT
Date: Thu, 3 Sep 1992 10:26:13 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Subject: Re: re IMAP2 futures?
To: IMAP Interest List <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dave makes some excellent points, and I suggest that everyone re-read his
message.  Separation of concerns is a vital part of engineering.  If we don't
keep it firmly in mind, we are very likely to end up with another fiasco like
the late unlamented `IMAP3', or even worse, the ARPAnet `new FTP' protocol
which was official, documented and unimplemented (as opposed to the real FTP
protocol which was unofficial and undocumented except in folklore).  I have
been told that people where pounding the tables at screaming at each other in
the FTP meetings...

In the past, I followed a set of criteria when evaluating potential changes to
IMAP2.  I think these criteria are good and should be continued in future
IMAP2 development.  Loosely stated, these criteria are listed below.
Exceptions and violations have existed; these criteria represent an ideal
rather than necessarily reality.  But, I think the strength of IMAP2 has been
due to my having held to (and occasionally fought for) these ideals, and the
weaknesses of IMAP have been when these ideals have been violated.

 1) All proposed changes must demonstrate a reason for their existance:
    a)  They must demonstrate that they are useful.
    b') They must demonstrate that they solve a problem that can not be solved
        by other means.
     OR
    b") The `efficiency' gained by the new functionality is such that the cost
        of requiring duplicate code in all implementations pales compared to
        the benefit gained.  [This is nearly impossible to prove.]

Examples:
 . A function to play a game of Pac-Man violates 1a.  ;-)
 . A function to set newline conventions violates 1a and 1b (long-winded
   explanation about why this is a terrible idea available on request) and
   also 3 and 4 below.
 . A function to do a remote Finger violates 1b (a Finger protocol exists).
 . A function to transmit 8-bit data violates 1b (IMAP2bis supports MIME and
   BASE64 decoding on the fly is easy).  It may not even be `efficient' to
   transmit binary, as those of us who compare FTP transfer speeds over V42bis
   links between binary and text know very well...

 2) All proposed changes must demonstrate that they belong in IMAP as opposed
    to some other protocol; the function must fit within the scope of IMAP.
    This necessarily implies that a distributed mail system will use multiple
    protocols; only the most simple and minimal can expect to do everything it
    needs with one protocol.

Example:
 . A function to change the user's password remotely belongs elsewhere.  This
   is undeniably a useful function and IMAP *MUST* consider proper interaction
   with more advanced authentication mechanisms, but maintenance of the
   authentication system is outside the scope of IMAP.

 3) All proposed changes must solve the problem they seek to solve, and not
    create new ones.  The road to bad protocol designed is paved with kludges
    that solve one problem in one limited case.

Example:
 . I believe that putting mail posting capability into a mail access protocol
   violates this rule (I acknowledge this is still a controversy).  The
   arguments for this are efficiency and authentication.  However, it is not
   efficient if the access server is in another continent (I use IMAP to
   Japan all the time!).  Nor are access credentials equivalent to posting
   credentials; a number of cases exist where posting is permitted without
   access (mail hubs), and access without posting (read-only bboards).  What
   is worse, by allowing posting in the mail access protocol, we create
   clients that only post using the access protocol (since they don't have
   enough memory to have multiple means of posting) and that closes a number
   of doors.  UW already has a separate mail hub engine from the mail
   repository, and this would be precluded by such clients.

 4) Multiple protocol states should be avoided, and silly states should be
    avoided like the plague.  This is something that repeatedly comes up in
    protocol design working groups, as yet another group of inexperienced
    individuals pressures for modal switches and for mechanism to list the
    capabilities of an implementation.  The archives of various working groups
    are filled with explanations as to why this is terrible design, and I will
    not belabor the issue here.  Note that even a single mode switch or a
    version command has been well-toasted; MIME has a `version' setting of
    1.0, and it highly likely there will never be any other value permitted.

    Silly states are something that have received a lot of attention recently
    due to my efforts.  A silly state is one which obeys the protocol, but
    creates a silly situation.  Humans generally avoid silly states in their
    interactions, but computers and bureaucracies create them all the time.
    An example of a silly state is that created by a server which answers a
    `what verbs do you support' by dumping its verb table, even though several
    of those verbs are served by an error message that says the verb is not
    implemented.  In all cases the server is responding reasonably; it *does*
    know about the verb so it can say `not implemented' instead of `not
    recognized'.  However, a client which makes decisions based upon its
    perception of what the server can or cannot do will be misled by the verb
    table dump.

    The key point to understand here is that no amount of legislation in the
    protocol specification is going to prevent silly states if the grammar of
    the protocol permits it.  One of the biggest mistakes in MIME was the ban
    on recursive encoding (encoding of types MESSAGE and MULTIPART) instead of
    the use of syntax that would make the concept non-existant.  The ban is
    there for excellent reasons -- I lobbied long and hard for it -- but the
    fact that the grammar permits it has come to haunt us with PEM.

 5) Proposed new capabilities should be interoperable with the past.  The base
    level capability of IMAP2 was defined in RFC-1176 (some say RFC-1064) and
    software implementing that base level is widely distributed.  New
    capabilities should appear as extensions, and it should be clearly
    understood what should be done if the capability is not supported.  The
    use of new capabilities should be completely under the client's control; a
    server should never thrust something unexpected upon an unprepared client.
    New capabilities should be small and have minimal interaction with other
    new capabilities; and where such interaction exists (e.g. between FIND and
    SUBSCRIBE) it should be well-documented.

    It is crucial that both the client and the server completely implement the
    enter base level, and that a client attempting to use capabilities beyond
    the base level is able to do so only with a willing server, and that no
    server should presume that the use of one extended capability by the
    client implies the existance of support in the client of another extended
    capability, and that no client should presume that a successful use of an
    extended capability with a server implies that the server supports another
    extended capability.

 6) It should be reasonable to expect that any new (or existing supported)
    implementations will implement *ALL* capabilities, both base and extended;
    that the `optionality' of an extended capability refers to the fact that
    we don't have to change all the old implementations; and that any
    capability which is marginal enough that a new implementation would not
    want to include it should be rejected on those grounds.  The fact that a
    capability, by not being in the base, is `optional' is not license to add
    a marginal capability on the grounds that it can be ignored.

    The penalty of disobeying this rule is a protocol filled with unnecessary
    and unused clutter.

 7) Some amount of latitude is allowed when the benefits clearly outweigh the
    costs.  For example, the new mail management capabilities in IMAP provide
    that service in the very simple case of a single repository.  By design,
    they are completely inadequate for multiple distributed repositories; that
    is completely outside the scope of IMAP and belongs in a mail management
    protocol.

 8) It is important that any protocol design recognize the realities of the
    underlying infrastructure.  IMAP2 is a byte-stream protocol and as such
    runs on top of a reliable byte-stream protocol such as TCP.  This imposes
    various constraints that aren't obvious to novices.  It is important to
    recognize that `reliability' implies error correction and especially flow
    control, that although these seem to be transparent they do have
    implications in your higher level protocol design.  The CCA Datacomputer
    protocol of ARPAnet days (R.I.P.) should be a textbook example of how
    failure to recognize flow control considerations can lead to deadlocks.
    No service on top of a flow-controlled protocol is truly `asynchronous'.
    The entire reason for UDP's existance is that it permits asynchronous
    protocols, albeit at the expense of lost reliability.

Regards,

-- Mark --