http://wwww.imap.org defines IMAP as "a method of accessing electronic mail
or bulletin board messages that are kept on a (possibly shared) mail
server". I am writing a specialized client which focuses on the bulletin
board application and am confused by some of the language in RFC3501,
particularly in light of observed IMAP server behavior. The implementation
recommendations (RFC2683) didn't clear up my confusion and recent threads on
mutable messages have only added to it. As a newbie, would appreciate any
feedback on the assumptions/interpretations below. When I say "IMAP" I mean
"IMAP4rev1" and I am concerned only with the IMAP4rev1 specification as it
exists, possibly operating in conjunction with accepted extension
specifications thereto as they presently exist. I.e., I have no
future-extension agenda.
The interpretations regarding which I request feedback are (apologies in
advance for the lack of brevity):
1. Use of an IMAP server on a standalone basis in the absence of a mail
transfer protocol agent is meaningful and supported, as IMAP does provide a
means of posting new bulletin board messages (the APPEND command). This
implies that messages need not have passed through an electronic mail
delivery process in order to be valid IMAP messages.
2. IMAP messages used in the bulletin board context, which originate via
APPEND, may acceptably lack a "To:" field in their headers. The "To:" field
is optional according to RFC2822 ("The only required header fields are the
origination date field and the originator address field(s). All other header
fields are syntactically optional.") so this omission does not even come
under the exception discussed in the APPEND command specification. The
Exchange 2000 IMAP server is an example of this behavior: bulletin board
posts ("New Post in This Folder", a first-class function, which has nothing
to do with draft or unsent messages) have no "To:" field in the header.
3. RFC2822 explicitly envisions revisions of messages and RFC2822 messages
are immutable only within the scope of a particular "Message-ID" field. Sec.
3.6.4 states that "The 'Message-ID:' field provides a unique message
identifier that refers to a particular version of a particular message... A
message identifier pertains to exactly one instantiation of a particular
message; subsequent revisions to the message each receive new message
identifiers".
3. Based on the above, and despite immutability of messages and associated
UIDs at the IMAP protocol level, a compliant IMAP client may nevertheless
choose to implement a user-level model of editable body content for bulletin
board posts. The Exchange 2000 IMAP server is an example of this behavior:
when post contents change, a new UID is generated, but the original internal
date is preserved and the original date is also retained in the "Date:"
field in the RFC2822 header. Note that while in the recent mutability thread
Larry Osterman mentioned changing message content only in the context of
"unsent messages", post editability is a first-class feature in Exchange,
and has nothing to do with draft/unsent messages. In
Outlook2000/Exchange2000, if the command "New Post in This Folder" was used
to create an item, then the command "Revise Contents" is available whenever
that item is opened (the similar command "Edit Message" is available for
mail messages, in certain circumstances, but the post scenario is my primary
concern). While Outlook/Exchange may implement post editability through
proprietary means, it could be implemented solely via IMAP using
DELETE/EXPUNGE/APPEND, where the APPEND command has a date/time string.
4. A system which wishes to provide a permanent way to locate an individual
post, for example a permanent URL that will retrieve it, and also wishes to
provide the user model of editability of post content, cannot solely depend
on the UID since when contents change the UID must change. However, the
internal date of the message may be used, since as per the above it is valid
to revise post contents while preserving the original internal date. The UID
may be used as a hint, but if it is not valid the timestamp (or, to fully
disambiguate, timestamp + FROM information) is a reasonable way to index an
entry. This is really a tautology since I am defining an "edited post" as a
post which has the date, sender (and, perhaps, subject) of an earlier post
but different body content. While IMAP doesn't provide a way to uniquely
retrieve a message based on the timestamp (since "SEARCH ON" returns
everything on a given day), that is an optimization issue since I am
assuming an intermediate agent that can process returned results and provide
the user model of individual entry retrieval.
5. While the APPEND command specification (6.3.11) states that "the APPEND
comamnd is not used for message delivery" the specification of the internal
message date attribute specification (2.3.11) discusses the case of
"messages delivered by the IMAP4rev1 APPEND command". I assert that the
meaning of "delivery" and "delivered" is different in these two sections:
6.3.11 uses "delivery" in the assumed context of a electronic mail delivery
protocol and associated agent, and 2.3.11 uses "delivered" in a more general
context - this is obvious of course because the APPEND command is explicitly
mentioned. So despite the apparently contradictory statements there is no
semantic conflict between these two sections.
6. Whether or not a user model of editable content "should" be provided for
messages that have been transmitted through a mail delivery system is not
clear. RFC2822 makes it seem as though there's no issue with multiple
versions of messages but the tenor of recent posts in this forum argue,
perhaps, that a system should not fake dates for messages that have been
delivered via a mail delivery system. But this is a UI issue not a protocol
issue. It may be that it would be useful to distinguish a class of IMAP
messages called "posts" which have either never been transmitted through a
mail delivery agent or (perhaps) are presented to the user as if that were
the case, and distinguish such "posts" from "mail messages".
OK, to verge into opinion here... use of IMAP servers as the persistent
storage for "bulletin board" type information in the form of public or
shared message folders that work independently of any SMTP message delivery
is a longstanding (since Cyrus 1.0), prevalent (with not only a number of
IMAP-centric servers but also Exchange supporting folder functionality), and
intended application. And RFC3501 makes the broad statement that "IMAP4rev1
permits manipulation of mailboxes (remote message folders) in a way that is
functionally equivalent to local folders.". It is clear that in the bulletin
board application context it is a valid user requirement to say "I'd like to
correct a typographic error in that post I made last Friday morning, and
please don't change the post date". This functionality is not only available
through IMAP via Exchange (and perhaps other IMAP servers) but is
commonplace in dedicated BBS/discussion forum systems. And editability of
messages in local mail folders is a given. In a publication context an
"edited on:" is provided as well, either as an authorial convention or
enforced by the system, but once again this is a UI or usage-convention
issue not a specification issue. So we should all get over the notion that
there's anything immutable about message content or that IMAP is only for
messages that are transmitted through electronic mail.
So to summarize: RFC2822 message ids and IMAP4 UIDs are certainly immutable
in their reference to a particular instantiation of header and body content;
however, if "editable message" means "give the user the ability to change
some content of a message while preserving its original creation date" this
makes perfect sense in IMAP and is presently implementable therein. No
extensions needed. While the Outlook/Exchange system may be less than an
exemplary IMAP citizen in other ways, there is nothing about its behavior in
regards to message editability that is out of conformance with the letter or
spirit of IMAP.
Thanks for any & all comments,
Bill McCoy
[EMAIL PROTECTED]
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
