ietf-822
[Top] [All Lists]

UA author advice / message operations vs. message access protocols

2004-12-01 15:08:54

On Wed December 1 2004 11:50, Steve Dorner wrote:

At 8:14 PM -0500 11/30/04, Bruce Lilly wrote:

This is probably an area where some advice to UA authors is called for.

But what advice?

Here are some starter suggestions:

* Get out of the user's way; don't force noise (e.g. "Re: ") into
   author fields -- let the user configure such behavior.

* Let the user configure which message header fields are
  displayed under various circumstances.

* Provide proper threading capability (using Message-ID,
   In-Reply-To, and References fields).
[There are some missing pieces here, particularly for messages
which are responses to multiple predecessors, but I'll leave
that for another day]

* Assume nothing about content in unstructured fields (Subject,
  Comments, Organization, Summary); decode encoded-words
  for display per RFC 2047/2231 and errata, but otherwise treat
  content as opaque data which is meaningful only to humans.

* Provide ability for the user to easily perform typical operations
  (edit recipients and other fields which an author is responsible
  for, compose new messages, prepare responses to the author(s)
  of one or more messages, prepare responses to the Reply-To
  address lists of one or more messages, Resend one or more
  messages, forward one or more messages, etc.)  Don't force
  the user to (e.g.) use a forward function to prepare a new
  (unrelated) message to a group of recipients.

* Ensure compliance with the relevant standards (e.g. ensure
  that header field lines containing encoded-words are no
  longer than 76 octets).

* For text (in the RFC 2277 sense), allow the user to configure,
  view, and edit language and charset of each piece of text
  (ensuring that only legal charsets and language tags are used).

IMAP has a number of features that operate on the server's
message store as directed by the client, including searching
capability.

If the exact operation you want to do is built into the IMAP 
protocol, and if you happen to be talking to a server that hasn't 
taken one of the numerous escape hatches available to IMAP servers, 
great.  Unfortunately, your chances of implementing anything complex 
or unanticipated with help from an IMAP server are small.  You would 
certainly wind up fetching the message to do Bayesian analysis on it, 
for example.

Let's keep things in perspective; fetching a message isn't always
a horrendous operation, and doing so via IMAP is little different
(modulo protocol baroqueness) than using other protocols such
as POP3.  At least IMAP does have the ability to handle some
search/sort operations on the server side of a narrow client/server
communications channel; POP3 doesn't.  Moreover, IMAP has
the ability to specify retrieval of specific parts of a message
(specific header fields, specific MIME parts, etc.), whereas POP3
is limited to a number of lines from the beginning of the message,
or the entire message.  I can't think of any operation that would
require retrieval of an entire message via IMAP that would not
also require retrieval of an entire message via POP3.