Hi Charles -
Thank you very much for your email. I have bounced it to the IMAP mailing
list. This response is also going to the IMAP mailing list.
I agree that it is desirable to transition towards a future in which
mailbox names, email addresses, newsgroup names, and header texts are
8-bit UTF-8. However, I worry that an improperly executed transition will
wreak havoc.
In particular, I am unconvinced that the last vestiges of "just send
8-bits" using non-UTF-8 character sets and no MIME tagging have been
exterminated. I am also concerned by your comments about "Gods of the
IESG" and "market forces will so decide"; these are the attitudes that
lead the to "just send 8-bits" debacle.
It is because certain people did not listen, and transmitted 8-bit texts
in a plethora of unidentified character sets, that we are in the
unfortunate position that we are today.
It is certainly *NOT* the case that "IMAP currently insists on 7-bit ...
simply because that is the way it always has been." Rather, this was a
carefully considered requirement, to exterminate unlabelled usage of ISO
8859-1, Shift-JIS, EUC-KR, etc. so as to make the IMAP world safe for
UTF-8.
With such a "safe world", we can conceivably have an IMAP extension that
switches on 8-bit as UTF-8. The issues are:
1) If the client negotiates this extension, and the data is stored in
other forms (MIME encoded-words for header items, modified UTF-7 for
mailbox names, other charsets for body texts) then the server has to
convert to UTF-8 and adjust size counts accordingly.
2) If the client does not negotiate this extension, and the data is
stored in UTF-8, then the server has to downgrade header items to
MIME encoded-words and mailbox names to modified UTF-7.
3) If header items or mailbox names are 8-bit but *NOT* UTF-8, then the
server has no way of doing the right thing. Since (2) will be the
more common case than (1), the server will end up causing further
data to the data unless it is lucky enough to recognize a sequence
of octets that is invalid UTF-8.
Hence the "havoc" that I alluded to earlier.
I am also concerned with the notion that USEFOR is taking on this task.
This is perpetuating the mistake of having mail and netnews have similar,
but incompatible, specifications.
I recommend instead that USEFOR confine its efforts to NNTP updates and
RFC2822 extensions specific to news, and get a charter going on a WG
dedicated to UTF-8 extension to messaging.
I would be very much interested in participating in such a working group,
and feel that this unified approach would deliver much better long-term
results than having netnews take a "go-it-alone" approach.
Please consider this.
Finally, I'll refer to your other comments:
> 1. I am surprised, in view of the number of changes, that you do not
> call it IMAP 4rev2.
The "changes" are primarily clarifications or minor upwards-compatible
extensions. It is unfortunate that there was an IMAP4rev1 name at all; it
happened only because one vendor (which no longer exists) threatened to
sue if RFC 2060 updated IMAP4 instead of creating IMAP4rev1.
> 2. I see that you have made a pre-emptive strike to allow UTF-8 in
> mailbox names at some future date. May I suggest that you include a
> similar pre-emptive strike regarding 8-bit headers and UTF-8 for both
> news and email
This is what the people at the email side of things have been doing.
Rumors to the contrary not withstanding, we are not idiots who stick to
7-bits because we don't know any better. Rather, interoperability and a
transition to UTF-8 has been the goal from the beginning. We probably
would have been there years ago if it weren't for the "just send 8-bits"
debacle.
> 3. I see that you have incorporated connections to SASL, TLS, etc.
> This is even further from my areas of expertise, but I have been
> watching recent discussions on the NNTP-Extension working group
> (http://www.academ.com/academ/nntp/ietf.html). The problem they
> encountered was that, whilst PLAIN authentication was probably good
> enough, the IETF expects something more that does not transmit passwords
> in the clear.
That's why PLAIN is not permitted unless SSL or TLS has been negotiated.
I've been waiting for a STARTTLS and AUTH command in NNTP. Just glom the
specification from POP3. Please.
> Encrypting the NNTP data stream is stupid, because everything in it
> is intended (usually) for the public domain, and the performance hit
> is severe. So they were talking about turning the TLS off after the
> authentication. This all strikes me as a sledgehammer and nut approach.
I sympathize; nevertheless we do not allow authenticated access to our
NNTP servers without using SSL NNTP. In fact, we no longer allow any
plaintext authentication for any of our services. The cost of one
security breach is much greater than the cost of encryption.
Fortunately, computers are faster these days.
The other choices are CRAM-MD5, DIGEST-MD5, which basically involve
storing plaintext equivalents of the authentication credentials on the
server.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
