(A note aside the topic:
Could you please edit your To: and Cc: address lists to contain
ONLY the ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu unless you are
making
PRIVATE exchange with the sender ? I do know that "g(roup reply"
is so easy to use, but getting the same message thru the list, and
privately just wastes my time at weeding out the duplicates... )
Ok, I feel the following speach became 1) long, 2) somewhat soapy...
Steve Dorner answers to Masataka Ohta:
At 8:58 PM 9/15/94, Masataka Ohta wrote:
And how can you post or read mixed 8859/1 KOI article?
multipart/mixed
text/plain; charset=iso-8859-1
text/plain; charset=koi-8
text/plain; charset=iso-8859-1
etc.
Ugly without a MIME reader, yes. But it works for MIME. And yes, you can
mix charsets on a single line.
Right.
For a moment we are slipping from NNTP to generic MIME..
I feel now that some of us are thinking that their pet idea must
be used on the GLOBAL TRANSPORT, which I do find unnecessary.
I do see that ISO-2022-INT-* has its place for those users WHO
CAN USE IT LOCALLY, but it doesn't mean even their mailers (MTAs)
must send it out! (The same with MNEM encoding!)
I myself use as old fashioned MUAs as possible -- yes, really!
and for my most common needs that is all perfectly ok. I never
see any QP-coded texts, because my MTA converts QP away when
storing to my mailbox.
(When UCB-Mail, and ELM+metamail aren't enough, I use other
tools, but that is a rare case..)
Now I don't see any reason why those who prefer ISO-2022-INT-*
in their mailboxes would not arrange all incoming messages
translated into that format ?
Is the only thing preventing such from happening just our
lazines to write the necessary translators into MTAs, and
get them installed ?
And back to NNTP/News..
Here again the problem is a lack of widely installed tools
which can do the things Right -- whatever your interpretation
of the "Right" is..
However keep in mind that THE NORMAL CASE is to use SINGLE
LANGUAGE in the whole article, and format it as if it is
MIME text/plain -message.
Anything more esoteric (multiple languages, multiple bodies, ..)
needs MIME, and possibly MNEM, or ISO-2022-INT-*.
Ideal would be to get the installed base of user clients
upgraded to MIME, but aside of PINE (and other IMAP using
MIME-capable systems) I haven't seen it happening...
... not that I have seen many PINE users reading news either,
however they can do it...
So for the NNTP environments where we can assume 8-bit clean
transport, the minimum would be to get SMART News-servers
installed which are able to recognize whatever text type
is sent within the enclave (Examples: sfnet -groups typically
use 8-bit ISO-8859-1 to encode finnish, relcom -groups use
KOI-8, etc.) and when they are feeding the messages out from
the enclave, those servers should add
MIME-Version: 1.0
C-T: text/plain; charset=XXXX
C-T-E: 8BIT
into the message, if there aren't any MIME-headers.
(If the message uses only chars that are in range 1..127,
the charset can be given as US-ASCII, and C-T-E: 7BIT ...)
The next step is extending the things so that NNTP would have
equivalent feature to ESMTP's BODY=8BITMIME which will make a
need for in-transit body-converter codes, but we do have
experience about them in the MIME+ESMTP-conformant MTA's anyway.
Finally here comes the initial suggestion that I made about
NNTP: For the most common case we can assume that whatever
charset the body claims to be, headers are most likely in the
same charset, and thus storing 8-bit chars in headers without
encoding them is likely to be the Usable Thing.
Also when transporting to outside the enclave, encoding the
headers with RFC 1522 can most likely succeed when assuming
that text/plain; charset=XXX applies there too.
The worry about touching to news headers that Henry Spencer
and others have voiced is well founded. However I think
the DUPLICATE DETECTOR feature for which these gentlemen
are mostly worried about is based on the Message-ID staying
intact, right ?
Of course when there are multiple routes out from the enclave,
all of them must use conversion capable servers, but that should
be obvious...
Unlike with email, NEWS are feed thru relatively few inter-enclave
links, thus deploying such conversion servers needs to be done at
the "strategic" points only. Not everywhere.
Problems on NEWS<->MAIL gateways are analogous to inter-enclave
servers, thus same solutions should apply.
Users who "just mail/reply the article" are a problem, though...
Btw: I always compose my mails with MIME-headers:
C-T: text/plain; charset=ISO-8859-1
C-T-E: 8BIT
but when the mail goes to a system which doesn't have
BODY=8BITMIME capability, all ENGLISH messages (that is,
they use chars in range 1..127) get their headers translates as:
C-T: text/plain; charset=US-ASCII
C-T-E: 7BIT
and so far nobody has complained me anything..
( dimacs.rutgers.edu doesn't run ESMTP capable sendmail, thus
the conversion happens before this message reaches the list.. )
I do have gotten complaints from people who "just-send-8-bit"
with their SunOS sendmails et.al., when they get replied, and
those replies are in MIME-QP, but for them the answer is simple:
Get better MUA, or MTA, or both.
--
Steve Dorner, Qualcomm Incorporated
/Matti Aarnio <mea(_at_)nic(_dot_)funet(_dot_)fi>
<mea(_at_)utu(_dot_)fi>