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

[blilly at erols.com (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.
>From [e-mail]  Tue Apr 19 18:01:33 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 18:02:04 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

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.
>From [e-mail]  Tue Apr 19 18:24:20 2005
From: LMM at acm.org (Larry Masinter)
Date: Tue Apr 19 18:24:32 2005
Subject: regarding your comments on proposed media type text/troff'
 toInformational RFC
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>

I wish you would reply and say why you think your proposal
(put processing instructions in a parameter) is better than
what I recently proposed as an alternative (put processing
instructions in a comment in the body).

MIME parameters tend to get lost when the MIME bodies are
pushed through most file systems. MIME parameters are hard
to set up for HTTP servers; it's difficult to configure
them to emit widely variable processing instructions, e.g.,
if you were to have several different text/troff files,
each with different processing instructions.

If don't REALLY intend for the processing instructions to be
handled automatically, and you REALLY intend for humans to read
and interpret them, you're better off bundling them inside
the body anyway.

Larry
-- 
http://larry.masinter.net