On Tue, 05 Jan 1999 09:25:00 -0800 (PST)
Ned Freed <Ned(_dot_)Freed(_at_)innosoft(_dot_)com> said...
BTW, what is ietf-822(_at_)imc(_dot_)org? Some RFC822-email list I presume.
Should
it continue to be included in these exchanges?
ietf-822 was the list where MIME was developed. As such, it is the right
place for discussions of MIME-related issues.
Fine. Someone has pointed me to its website where I can retrieve the
missing articles. Maybe I should join that list to continue this
discussion.
I have CCed this to the usenet-format-list, but not in the Reply-To
line, so Ned will not get any more bounces.
So, dealing with the points raised as best I can remember them, Ned
seems to be suggesting that it is possible to cope with headers with
8bit characters in them within the existing message structure, even
within message/rfc822. But I just do not see how this is possible. So
please can we have an explanation of how it's done, preferably with a
simple example. I agree it would be far better to use a message type
if it can be done, and using an application type was known to be a
second-best kludge when it was put forward.
I already outlined the path forward: First we finish 822bis, so we
have a coherent specification to work from. Then we form a design team
to put together a specification for how 8bit in headers would work.
But it is unreasonable to say that all other internet developments (news
in this case) have to wait until 822bis is completed, and then some new
design team is formed, before they can proceed. This is a problem we
have to solve _now_.
Please note that the notion that you can simply say it is OK to use
8bit in headers is a dog that does not hunt. You to have specify where
it can be used, what its semantics are, you have to specify how to
downgrade it to 7bit, and you have to give a revised grammar for the
result. Nothing less is likely to pass muster. And while I'm fairly
sure that UTF-8 is the right answer here, there may be substantive
profiling issues with how UTF-8 is used (language tags in particular
come to mind).
Not so. Within the news environment, all those questions have been
addressed, and downgrading to 7bit is not needed. Gatewaying may get a
bit complicated, but application/news-transmission (which is aimed at
machines rather than humans) gets over some of the problems. Which just
leaves the matter of a human friendly way to transmit news across email
and have is restorable to exactly the same thing at the far end.
We had hoped to use message/something for this, and your earlier
message seemed to suggest that it could be done within the existing
constraints, but it seems not to be so. So for the moment we have proposed
application/news-message - not that we like it very much.
I suppose something like the following might be possible:
Content-Transfer-Encoding: 8bit
Content-Type: message/news; boundary="foofoo" (or should it be multipart/news?)
Other-Email-Headers:
This is an encapsulated news article.
--foofoo
Content-Transfer-Encoding: quoted-printable (1111)
Content-Type: application/news-headers; charset=utf-8 (1111)
(or text/news-headers?)
Newsgroups: various.groups.in.some.greek.hierarchy.using.utf-8.characters
Message-ID: <12345(_at_)foo(_dot_)com> (message-ids are still strict ascii)
Path: here!there!everywhere
Subject: Some Greek text, no doubt
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-6 (or whatever the Greek iso code is)
Other-News-Headers:
--foofoo
Content-Transfer-Encoding: base64 (2222)
Content-Type: text/plain; charset=iso-8859-6 (2222)
The body of the article, written in greek using iso-8859-6 (whatever).
--foofoo--
NOTE: The lines marked (1111) and (2222) would ideally use CTE: 8bit,
but could lawfully be changed to something else if a transport without
8BITMIME capability was encountered en route. It may be that they could
be omitted entirely in the default (8bit) case.
I cannot say I like such a scheme, but at least it might do something
reasonable on existing implementations, and it does not look too bad if
the recipient gets to see the text exactly as I wrote it above.
Then we'll likely need to define an SMTP extension to negotiate
the use of 8bit headers in mail.
There already is such an extension (8BITMIME) but it is only a SHOULD,
not a MUST ;-( .
I don't know about NNTP. You say
that NNTP is 8bit clean, and who am I to argue, but this leaves
the substantive issue of how to handle NNTP gateways to other
environments, to say nothing of client support for UTF-8.
NNTP is not a problem. Client support for UTF-8 is obviously needed
in newsreaders, but only for users who want to read Greek (whatever)
newsgroups, and they are probably going to need special clients in any
scheme. It seems that news servers do not need to understand UTF-8 at
all and will need minimal upgrading (if any).
And once all this is done there should be no problem putting 8bit
message headers in message/rfc822 parts.
Ned
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 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