Re: Content-Canonicalization: crlf?

> What I would like to see is a hint in the headers that the data is > really textual, even though it's not readily human readable, and hence > not a candidate for text/*.
This is an entirely different issue. The handling of non-text materials by displaying them as text -- a kind of fallback presentation methodology if you will -- is a distinct problem quite different from conversion to local form prior to display. In fact what consistutes appropriate local form may well change depending on how something is to be displayed!
In one sense at least the "hint" you're asking for is already provided by the content type. Its supposed to be appropriate to handle any subtype of text this way. Its not really appropriate to do this with anything else, at least not without some additional information about the type.
Providing an option to safely view (the safety part is important) arbitrary objects as text is a useful option to have lying around, however. It can even be useful when its clearly not the right thing to do for most users. At a minimum its useful as a diagnostic tool... Several of the PC LAN mail systems have provided options of this sort for quite some time, and users seem to deal with such options without undue incident.
> Yes, this is redundant information if the recipient possesses the full > opus of defined MIME types.  Unfortunately, there's no guarantee that > the receiver is up-to-date in his definitions.
You are also assuming that the sender knows what the receiver should do. Even if the sender does understand the type (which as you yourself point out is not always the case), it has no real way of knowing what a given type-receiver pair should do, at least not specifically. This is very dependent on what viewers the receiver has available for different material, something the sender doesn't have any way of knowing. The best you could provide is an indication of whether or not display as text is ever going to be a useful endeavor. And even then the sender won't always get it right.
I never cease to be amazed at the incredible variety of behaviors users want to see agents manifest. They want perfectly readable text converted to a surreal format and crammed into a huge bulky awful word processor that turns it into garbage. They want unintelligible gibberish displayed directly -- stuff that you'd be crazy to think of as text. They want control character sequences leaked to a terminal without interpretation and the security consequences be damned.  And so on. The thought of a message sender dictating this dimension of the presentation problem for a given type is something of a stretch for me.
For these reasons, I see this aspect of handling a given type as best being handled by appropriate settings in a mailcap file on the receiving system, not as something to put in the message with the object itself.
> Nor, I admit, is there any guarantee that the sender is up-to-date > enough to know to put the "hint" in.  However, the sender can usually > resend the data if the wrong thing is done.  The recipient doesn't > always have the option to re-receive it.
Another aspect of this problem is the variability from one instance of a given type to another. Some objects of a given type may be appropriate for display as text while others may not be. Its possible, for example, to write PostScript in such a way that most of it is perfectly readable text requiring no viewer. The vast majority of PostScript objects lie at the opposite end of the spectrum, of course. There are plenty of other examples besides PostScript, of course -- in fact a case could be made for an option to tell when text material should NOT be simply displayed since its not intended to be readable in a convention sense!
This moves the problem into a different realm -- that of suggestions as to what constitutes appropriate handling for a given object in the context of a specific message, rather than blanket statements about the characteristics of the type as a whole and how it should be handled everywhere. I don't trust a sender to tell me much of anything about a type as a whole, but I do have some faith in its ability to tell me about a specific object it just sent to me. (Although I've recently run into an instance of a sender emitting base64 text/plain that turned out to be pure binary data... Well, it was just a beta version of a certain unreleased package; I'm sure you know the one I mean...)
We already have one way to provide this sort of information about an object. We call it content-disposition. This sort of thing could be a parameter to the display disposition. (The first, if I'm not mistaken.)
There is also some overlap with the URC concept here. (This is actually true of content-disposition in general.) My understanding of URC information is that it provides information about the characteristcs of a given object rather than of the type as a whole, information which may either be missing from the content itself or may be difficult to determine from the content without a lot of work. The line between URCs and dispositions is very fine, perhaps even nonexistant, but I see it as being drawn between the object's characteristics and how the object should be handled in the context of a specific message. (And of course we don't have URCs yet!)
Anyhow, if this is to be persued as anything other than a mailcap option to be applied to a type as a whole, I think it's best done as an option to the display disposition. And that, Steve, puts the ball back in your court, I think ;-)
Ned