------------- Begin Forwarded Message -------------
From Chris(_dot_)Newman(_at_)innosoft(_dot_)com Tue Jan 12 20:40:46 1999
Date: Tue, 12 Jan 1999 11:11:09 -0800 (PST)
From: Chris Newman <Chris(_dot_)Newman(_at_)innosoft(_dot_)com>
Subject: Re: Restrictions on the Content-Type "message"
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Charles Lindsey <chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk>
[For some reason, the message you sent appeared to be private rather than
from the list. You may redirect this reply to the list if you intended
this to be public debate.]
On Tue, 12 Jan 1999, Charles Lindsey wrote:
I suspect application/news-message is a complete non-starter. The last
thing MIME needs is a new composite type. I suppose multipart/news is
possible, but ugly. I doubt there will be sufficient motivation for MUA
authors to add good support for such an optional and ugly type.
AIUI there are three possibilities for encapsulating news articles:
1. Application/news-message. This happens to be what is written into our
current proto-draft, but it is not cast in concrete. It works, from a
strict technical point of view, but it is agreed to be ugly. Exceedingly
ugly if you like.
While you can put any _data_ in an application type that you wish, you
can't change the rules which govern how a MIME agent will process
application types in general. Application types are processed as a single
opaque entity which is either saved to disk or passed directly to a viewer
application. In particular, a MIME agent does not show an application
type to the user. Since news messages sent through email should be
readable by users, using application is NOT an option.
Also, what if a news message has a MIME attachment? If you use an
application type, then the attachment is inherently invisible to the MUA.
2. Multipart/news. This is the one I described briefly a few days ago.
Details are not fully worked out. It would certainly work, and might even
give an acceptable interface on present news/mail readers. But it is not
pretty and certainly not ideal. Regard it as the fallback position for
Very ugly and will probably be less functional than the current email/news
infrastructure. But it is an option, unlike #1.
* Create rules for UTF-8 headers and downgrading thereof.
We have worked this out for news. Would you like me to post an outline of
what we have done here?
* Create UTF8HEADER SMTP extension. Provides RFC 2047 downgrading for
both top level headers and nested message/rfc822 headers.
May I suggest calling it "8BITHEADER" extension.
IMHO, it should either be UTF8HEADER with the simple obvious meaning, or
it would be 8BITHEADER and add an extra "HEADERCHARSET=<blah>" parameter
to MAIL FROM. Given the latter is more complex and doesn't seem to be
significantly more functional, I prefer the former.
applications for it. Presumably easily (trivially?) implemented on top of
No. In order to interoperate with existing 7-bit infrastructure and
clients (or worse, clients which assume some random localized 8-bit
charset), an MTA which advertized UTF8HEADER MUST support RFC 2047
downconverting. Otherwise you break things left and right.
However, RFC 2047 downgrading may not be the answer. RFC 2047 is
much disliked in USEFOR. In our draft it is a MUST accept, but MUST NOT
generate. I think the point about any downgrading is that it must be
reversible, which means you need to know how it started out so you can
translate it back to the same thing again. One of our problems with RFC
2047 is that it is a one-to-many mapping (and, we suspect, frequently
I don't think anyone likes RFC 2047. But the only interoperable way to do
internationalized headers with today's email software is RFC 2047. Any
new/better/simpler solution to internationalized headers will have to
support RFC 2047 downconversion for interoperability with deployed
software. There is no alternative.
------------- End Forwarded Message -------------
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
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