[Top] [All Lists]

Re: Restrictions on the Content-Type "message"

1999-01-12 10:11:18
 Chris Newman <Chris(_dot_)Newman(_at_)innosoft(_dot_)com> writes:

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.

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

3. Some new enhanced feature for email. Obviously this is the ideal
solution, except that it does not exist yet. Ned reckons it could be done
in 6 months. I predicted 5 years. Doubtless the truth lies somewhere in

The solution I prefer is:

OK, let's look at the possibilities.

* 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. There might be other
applications for it. Presumably easily (trivially?) implemented on top of
8BITMIME. 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
incorrectly implemented).

* Extend message/rfc822 to permit 8-bit headers in appropriate transports
 and to use:  Content-Type: message/rfc822; variant=news


* Permit use of 8-bit "message/rfc822; variant=news" with any SMTP server
 that advertises UTF8HEADER.


* a news->mail gateway can use message/rfc822; variant=news, and has to
 have full downgrading support.
* a mail->news gateway has to provide full upgrading to 8-bit support.
* Support for a top-level message/rfc822 is already part of MIME, although
 UI quality varies.  This should be sufficient incentive for MUA vendors
 to improve support for an already mandatory facility.
* old gateways which don't do proper downgrading/upgrading will get yelled
 at and fixed.

All yes, but the upgrading is perhaps the tricky part.

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