On Tue, 25 Feb 2003, Russ Allbery wrote:
Are you aware of IMAP servers that use the news spool storage format for
IMAP mailboxes? I'm not, and I would have thought that would be an
untenable storage format since it doesn't contain enough metadata in an
indexed form to provide basic IMAP functionality without a huge speed hit.
I am. UW imapd is quite capable of exporting a local news spool as the
#news namespace. The news spool is, indeed, quite an untenable storage
format for IMAP due to the lack of useful metadata. [But try to tell that
to the maildir groupies...]
If the IMAP server doesn't use the same storage format for mailboxes and
for news articles, then it is internally aware that the news messages are
something different than the rest of its mailboxes.
Actually, it does and it isn't; but that's admittedly an implementation
issue. However, I find myself quite unwilling to accept the premise that
news messages are something different than any other kind of messages.
I don't believe that the contention that proposal (A) requires any
impossible modifications is even remotely viable or defendable, and none
of your posts have convinced me otherwise.
Let's try a different approach, which will help explain the problem
better.
It is relatively straightforward to undertake an extension to a protocol
which requires no changes to any other protocols or their implementations.
It is nearly impossible to undertake an extension that requires changes to
other protocols or their implementations.
I don't know if it has actually happened, but working groups have been
threatened with litigation if they do something that would cause an
existing standards-compliant implementation to become non-compliant (or
it does something non-compliant and they can't point a finger at someone
else's non-compliance as being the cause). This is, regrettably, the
world that we live in today.
The path of least resistance is always to do something that requires no
changes to anything else. It may be ugly, and it may be highly desirable
to change. Nonetheless, if it can be ignored, it won't generate
opposition.
The choice is simple. Go with UTF-8 in headers, and face substantial
opposition; or go with something that stays compliant with RFC 2822 (such
as the punycode method suggested by the Kohn draft) and not be opposed.
Considering all the other issues that Usefor needs to decide, this choice
should be a no-brainer.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.