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

[Keith Moore]

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

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

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.

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

Content-type parameters are not displayed in most mail readers.

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

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.

> 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 no inherent security risk aside from social engineering

hogwash.