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

[Bruce Lilly]

On Sat April 16 2005 18:46, Keith Moore wrote:
> Bruce,
> 
> bottom line - this parameter violates both the intent and the wording 
> of the MIME spec.  it's simply unacceptable.
> solve the problem in a different way.

I'm not going to engage in speculation regarding "intent".

Regarding the wording in the core MIME RFCs (2045, 2046, 2048, 2049;
2047 is not applicable), the only remotely applicable text that I can
see is in RFC 2048:

   New parameters must not be defined as a way to introduce new
   functionality in types registered in the IETF tree, although new
   parameters may be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

RFC 2048 is about to be updated; the corresponding text from the most
recent draft is:

   New parameters SHOULD NOT be defined as a way to introduce new
   functionality in types registered in the standards tree, although new
   parameters MAY be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

The use of BCP 14 keywords clarifies the meaning of the text.  Regarding
that text, no new functionality is introduced by the "process" parameter;
it is added to convey additional information that does not otherwise
change existing functionality.

Absent a specific citation to an applicable section of one of the MIME
RFCs, I'm not inclined to make changes other than clarification that
the usage is strictly end-to-end, user-to-user communication and to
reaffirm the prohibition against automated use for program execution.