I am the Editor for the Usefor working group, which is charged with
updating RFC 1036 (see http://www.landfield.com/usefor for latest draft,
list archive, and other goodies).
Our draft introduces many changes to the Netnews protocol, but the most
obvious one is that headers will be allowed to contain 8-bit octets
(not everywhere, but certainly in newsgroup-names, and also in phrases,
comments, parameters and unstructured headers). These headers are to be
interpreted as being in the UTF-8 charset.
This poses no problems so far as transport of articles by NNTP or UUCP
is concerned, because those transports are already 8-bit clean. It does
pose problems for news articles that have to be transported by email
for whatever reason (e.g. posting-and-mailing, mailing to moderators,
gatewaying to mailing lists) and we have fallen over backwards to make
sure that the resultant email will comply with the relevant email
standards. And it also raises a problem with those IMAP4 servers that
offer a news as well as an email service.
Whether our proposals make it all the way to a standards track RFC is,
as ever, in the lap of the Gods of the IESG. What is for sure is that
8-bit headers are certainly going to happen sooner or later, IESG or
not, because market forces will so decide (indeed, they are already
doing so, for both news and email). But for the moment the WG is
proceeding on that basis, and my job as editor is to see that it is all
correctly described in the document.
Now my understanding is that IMAP currently insists on 7-bit only in
headers, simply because that is the way it always has been; therefore it
would be natural for IMAP to change if/when the new Netnews standard is
adopted. It seems to me that there are two ways to do this: either the
IMAP base document is changed, or else an extension is defined (with a
suitable IANA-registered capability).
I think the former approach would be premature, and my current thinking
is that we should define such an extension. I have therefore drafted
some text to include in our draft, and I would like to hear your opinion
as to (a) whether that is the correct way to go about defining an
extension, and (b) whether I have said the correct things.
It comes in two parts. Firstly, the existing section dealing with
character sets acquires a new paragraph:
4.4. Characters and Character Sets
Transmission paths for news articles MUST treat news articles as
uninterpreted sequences of octets, excluding the values 0 (US-ASCII
NUL) and 13 and 10 (US-ASCII CR and LF, which MUST ONLY appear in the
combination CRLF which denotes a line separator).
NOTE: this corresponds to the range of octets permitted for MIME
"8bit data" [RFC 2045]. Thus raw binary data cannot be
transmitted in an article body except by the use of a Content-
Transfer-Encoding such as base64.
[Suggested paragraph to deal with IMAP]
This requirement includes the transmissiom paths between posting
agents, injecting agents, relaying agents, serving agents and reading
agents, but it does NOT include paths traversed by Netnews articles
that have been converted to Email (8.8.1.1). In particular, this
means that IMAP4 servers which provide access to Netnews SHOULD
implement the extension described below.
and then there is a new section describing the extension:
4.4.3. The NEWS-8BIT-HEADERS IMAP Extension
The current IMAP4 protocol [RFC 2060] forbids 8-bit character in
headers (so as to conform with the previous Netnews standard [RFC
1036] amd with the current Email standards).
[That reference to RFC 2060 should be changed to refer to [RFC 2060bis]
if that has been accepted by the time this standard is published.]
Implementations of IMAP4 conforming to this extension MUST
1. In the case of Netnews messages only, accept 8-bit octets in
headers (part specifiers HEADER or MIME, or the header portion of
a MESSAGE/RFC822 part) and pass them on to the client unchanged in
any FETCH response;
2. Interpret all octets in such headers as being in the UTF-8
charset;
[Does the IMAP server ever actually need to interpret headers; i.e. does
this matter?]
3. Include the capability NEWS-8BIT-HEADERS in any CAPABILITY
response.
NOTE: It is the responsibility of the client to interpret such
headers. Users who require to see them displayed correctly will
need to acquire clients with the necessary UTF-8 facilities.
The new capability NEWS-8BIT-HEADERS is to be registered with IANA.
[Memo: remember to update the IANA Considerations section.]
[RFC 1036] M. Horton and R. Adams, "Standard for Interchange of
USENET Messages", RFC 1036, December 1987.
[RFC 2060] M. Crispin, "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[RFC 2060bis] M. Crispin, "Internet Message Access Protocol - Version
4rev1", draft-crispin-imapv-*.txt, October 2002.
As you can see, I have been looking at your draft-crispin-imapv-20.txt.
Since IMAP is far from my area of expertise, I will make only a few
comments.
1. I am surprised, in view of the number of changes, that you do not
call it IMAP 4rev2.
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 (could add a bit of legitimacy to my extension :-) ). I
am sure that a similar extension for Email will be required before many
years are out, and you will observe that my proposed capability name
lends itself to a similar email capability when they get a round tuit.
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. But the only SASL mechanism that avoids that involves the
use of STARTTLS, and that causes the whole of the following datastream
to be encrypted.
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.
How this affects IMAP, I wouldn't know, but I do suggest that it might
be worth your while to review recent discussions on their mailing list,
since it would seem to make good sense for NNTP and IMAP to have similar
facilities in this area.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: [EMAIL PROTECTED] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
