regarding your comments on proposed media type text/troff' to Informational RFC

[Keith Moore]

> On Tue April 19 2005 15:14, Keith Moore wrote:
> > > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > > (Octet-Stream Subtype), which is not directly relevant:
> > > 
> > > 1. it concerns application software implementation issues rather than
> > >    media type definitions, parameters, content, or registration
> > > 
> > > 2. it is specific to the application/octet-stream media subtype, which
> > >    is in a completely different media type category.
> > 
> > I've already explained why the text is relevant despite the above.
> 
> I don't buy your explanation; it seems to be predicated on an assumption
> that a certain vendor will attempt automatic interpretation of parameter
> value content -- that vendor not being likely to want to support troff,
> which is a direct competitor to said vendor's products.

Your assumptions about my assumptions are incorrect.

> Would you really be happier if it were defined as a strictly human-readable
> text value?

If you defined it in such a way that it could say whatever it wanted to
a human (and not, say, as a command that the human was expected to type),
yes, that would be more acceptable.  Since parameters are rarely 
presented to humans, it wouldn't IMHO be very useful to have such a 
parameter.

> > It is well established that email may be used to send executable content,
> > but we try to discourage having ways that make it easy for the email
> > reader to distinguish executable content from non-executable content
> > and execute it.
> 
> Surely one would like to encourage, rather than discourage, easy
> differentiation of executable and non-executable content.

Not when you look at what actually happens in practice when you do that.

> > The purpose of content-type parameters is for machine interpretation rather 
> > than human readability.
> 
> There is nothing in the core MIME RFCs or draft successors that requires
> machine interpretation.

true.  

> If a parameter is defined as
> human-readable information, then the appropriate action for a UA is to
> display the content to the user.

It's not going to happen, as UAs don't special-case handling of most
content-types.  (now maybe the plugin for the content-type could 
display such content to the user, but that doesn't seem much more
likely given common practices).

Keith