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

[blilly at erols.com (Bruce Lilly)]

On Tue April 19 2005 13:13, Keith Moore wrote:
> Bruce,
> 
> I've already cited the relevant text

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.

However, some of the considerations of course apply to application
software implementations of other media types, and those are discussed
in the draft, using language similar to (but with RFC 2119 emphasis;
for what that's worth in an Informational RFC) that of the cited section.

> The process parameter as you have defined it is not an essential part 
> of this content-type.

Duh.  That's why it's an optional parameter.  If you don't like it, you
need not use it.

> Nor is it likely to be used in the way you assume, 
> because (as I have already said twice) content-type parameters are 
> rarely displayed to recipients.

I can easily see the entire Content-Type field; look at any I-D-announce
or IETF-Announce list announcement of a draft or RFC -- there are
message/external-body wrappers with Content-Type and Content-ID fields
for the media.

> Nor is the parameter as you have defined 
> it portable to different implementations of troff that have different 
> options.

There is an optional "versions" parameter which can be used to indicate
peculiarities.  However, unless one tries fairly hard, one is unlikely
to encounter incompatible options, as implementations are generally
intended to be compatible, and authors creating content for wide
distribution tend to be careful not to use incompatible features.

> This parameter is just poorly designed, and it's a security 
> risk, and there's simply not enough justification for it to be defined
> the way you propose.

Sending executable content such as a build script as you proposed as an
alternative would be a security risk.  Since the parameter is human-readable
information about the media type, *in* a parameter (which is not executable),
there is no inherent security risk aside from social engineering, and that
exists regardless of any parameters, and regardless of media type.