[Top] [All Lists]

Re: Restrictions on the Content-Type "message"

1999-01-08 23:56:02
Uh, pay attention, please. The above is application/news-transmission, not
application/news-message, for which, if you recall, I said that the case
is far murkier.

I see no problems with application/news-transmission, assuming it is a
news equivalent to application/batch-SMTP (RFC 2442).  It's something
end-users will never see.

Apologies to all -- I completely missed the point that this was talking about a
transport protocol type. (Indeed, I cannot see how discussing such a thing has
any relevance whatsoever to the topic at hand.) I thought the discussion was on
the topic of message types.

I note in passing that the present USEFOR drafts apparently don't contain
definitions of either of these types, other than to note that news-transmission
isn't well defined.

However, unlike message types, there is absolutely no problem assigning types
to transport protocol objects. The key distinction here is that transport
protocol objects have very different semantics and uses than composite message

About the only tricky part can be definition of appropriate "batching" rules.
Experience has shown that when you get this wrong, as happened in the case of
the various initial attempts to define batch SMTP, you end up with all sorts of
amusing problems. And we basically had to wait for existing use of batch SMTP
to die out before we could try again.

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.


The solution I prefer is:

* Create rules for UTF-8 headers and downgrading thereof.
* Create UTF8HEADER SMTP extension.  Provides RFC 2047 downgrading for
  both top level headers and nested message/rfc822 headers.
* 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.

I'm not wild about the parameter name "variant", but aside from that
this is exactly what I think should happen.

* 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.

FWIW, gateway support quality also varies greatly, but has greatly improved in
the last few years. (As has MUA/UI support quality.)

* old gateways which don't do proper downgrading/upgrading will get yelled
  at and fixed.

I hope so, although past experience with gateways upgrade leads me less than
optimistic that this will happen in a timely fashion.