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

[blilly at erols.com (Bruce Lilly)]

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.

> What I meant (as if you couldn't figure this out) is that it doesn't have
> to be defined the way you want it to be defined in order for the type to
> be useful.

Would you really be happier if it were defined as a strictly human-readable
text value?
 
> 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.

> > Since the parameter is human-readable
> > information about the media type, *in* a parameter (which is not executable),
> 
> 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. RFC 2048 says "to convey additional information";
its draft successor uses the same phrase.  If a parameter is defined as
human-readable information, then the appropriate action for a UA is to
display the content to the user.

Each defined media type and subtype may specify any number of parameters,
and behavior is indicated by each specification.  A given parameter in a
given Content-Type field for a specified media type and subtype has to
be interpreted per the parameter specification for that subtype or type
(in the case of an inherited parameter). As noted in RFC 2045 "There are
NO globally-meaningful parameters that apply to all media types."