On Wed, 26 Mar 2003, Bill McCoy wrote:
> 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.
RFC 3501 does not use the term "bulletin board" anywhere. This is
intentional, as "bulletin board" means different things to different
people.
For example, here are three common interpretations of "bulletin board":
1) a publicly-readable, but write-protected, mailbox that is posted to
via mail to a particular email address.
2) a newsgroup that is posted to via newsgroup posting
3) a publicly-readable, and at a minimum append-enabled, mailbox that is
posted to by appending to it.
>From what I've read of your message, you seem to be contemplating an
implemention of something very much like a type (3) bulletin board. IMAP
certainly does not preclude doing so; but it doesn't stipulate that this
is the One True way of doing it either.
> 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 is true for type (3), but not for other types. It's important to
understand this distinction, even though it may not be meaningful in your
particular context.
Put another way, if you decide to do posting by APPEND, you necessarily
have restricted your implementation to a particular context. This is
probably what you want, but you need to be aware that this is what you're
doing.
> 2. IMAP messages used in the bulletin board context, which originate via
> APPEND, may acceptably lack a "To:" field in their headers.
Correct.
> 3. RFC2822 explicitly envisions revisions of messages and RFC2822 messages
> are immutable only within the scope of a particular "Message-ID" field.
Correct.
> 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.
Yes, as long as a new UID is issued for the edited message. Remember as
well that UIDs must be strictly ascending in the mailbox, so unless you
use a sorted view this will change the position of the message in the
mailbox vis-a-vis other messages.
> 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.
Correct.
> 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.
Ummm... I neither agree nor disagree with this.
It is, of course, quite possible to receive more than one message in any
particular second of time. Also, if a permanent URL is desirable, it is
reasonable to implement "editability" without the DELETE-EXPUNGE, so that
both copies are available.
I would be more likely to search for Message-ID, since Message-ID
immutability is primarily for transport purposes and not to detect user
edits.
That doesn't mean that what you propose is unreasonable; but rather that
it's not how I would address the problem.
> 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
^^^^^^ 2.3.3?
> "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
^^^^^^ 2.3.3?
> context - this is obvious of course because the APPEND command is explicitly
> mentioned.
This dual use of "deliver" is unfortunate, but you are correct that the
line is not always as distinct.
"Deliver" as used in 2.3.3 refers to what a "message delivery agent" (MDA)
would do. This is after the message passes through the mail transport
(MTA, e.g. SMTP) infrastructure.
The more correct word for 6.3.11 is probably "submission".
> 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.
This is largely left up to the individual mail user agent (MUA)
implementor. Internet standards such as IMAP generally do not presume to
dictate what happens at the end user level.
It *is* considered to be bad taste (to say the least) to edit a message
and then resubmit it to the mail transport infrastructure as if it was the
original message.
> 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.
Correct.
> 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".
Correct, as long as a new UID is issued for the corrected message.
> 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.
I don't think that anyone stated either of these.
If you are referring to a recent discussion, that was about something
quite different: changing a message in the mailbox without assigning a new
UID. Many of us reacted unfavorably to that, since that would indeed
break all existing IMAP software.
It is, however, perfectly alright to take a message, alter it, APPEND the
altered version to the mailbox (thus assigning a new UID), and possibly
delete+expunge the original copy.
> 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.
Correct.
I hope that this response helps clarify things for you. Sometimes, it is
very easy to get confused over the precise meaning of a word, especially
when the two conflicting meanings are very similar.
At least from my reading of your message, you seem to have a correct
understanding of the requirements and capabilities of IMAP, and of how you
would use (and be restrained by) IMAP to do what you want.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
