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

[blilly at erols.com (Bruce Lilly)]

Larry,

Thanks for your comments.

On Mon April 18 2005 15:06, Larry Masinter wrote:
> How about removing the "process" parameter and instead suggesting that
> instructions be included in the source document, in a comment,
> explaining how to process the document, including possible
> recommended command lines, environment variables, preprocessors,
> warnings.

The draft does note that it is possible to include such information
in comments, and cautions against conflicting information.

> Make it explicit that there is no standard format for such
> instructions,

That's one of the problems for authors and recipients.

> and that receivers of text/troff documents should 
> not attempt to try to automatically interpret such instructions
> because instructions might vary widely in format, language,
> and syntax, or contain preconditions or warnings or other
> information.

The more important reason to avoid automatic interpretation is that
is is unsafe to do so.

> It would even be reasonable to suggest, to the creators
> of text/troff content, the complete set of information
> that would be required in such instructions, and even
> some useful guidelines about how to write them in a way
> that others will have good luck interpreting them.
> But by not creating a standard syntax, you will avoid
> encouraging writers of receivers to build automatic
> launch information.

One problem with not having standard syntax is that it may be
impossible for a recipient to understand prose instructions
(would you be able to comprehend instructions in Arabic or
Chinese, for example?).  Of course, a standard or convention
could be used for embedding processing comments in the content,
but that requires having the content available (would you want to
download a 10 MB file only to find out that you cannot use it?).
A Content-Type field parameter is available when the media
itself is not (via HTTP negotiation, via message/external-body,
etc., and can be used to make decisions about retrieval).
Information in the Content-Type field provides metadata for the
media content, and can be stored in a database entry for the
media content (some computer operating systems have such a
facility for storing metadata for files).  The specific parameters
defined for this specific media type constitute such metadata
which can be stored and retrieved by that general mechanism.
>From [e-mail]  Tue Apr 19 18:30:37 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 18:30:50 2005
Subject: regarding your comments on proposed media type text/troff'
	toInformational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

Larry,

Thanks for your comments.

On Mon April 18 2005 15:06, Larry Masinter wrote:
> How about removing the "process" parameter and instead suggesting that
> instructions be included in the source document, in a comment,
> explaining how to process the document, including possible
> recommended command lines, environment variables, preprocessors,
> warnings.

The draft does note that it is possible to include such information
in comments, and cautions against conflicting information.

> Make it explicit that there is no standard format for such
> instructions,

That's one of the problems for authors and recipients.

> and that receivers of text/troff documents should 
> not attempt to try to automatically interpret such instructions
> because instructions might vary widely in format, language,
> and syntax, or contain preconditions or warnings or other
> information.

The more important reason to avoid automatic interpretation is that
is is unsafe to do so.

> It would even be reasonable to suggest, to the creators
> of text/troff content, the complete set of information
> that would be required in such instructions, and even
> some useful guidelines about how to write them in a way
> that others will have good luck interpreting them.
> But by not creating a standard syntax, you will avoid
> encouraging writers of receivers to build automatic
> launch information.

One problem with not having standard syntax is that it may be
impossible for a recipient to understand prose instructions
(would you be able to comprehend instructions in Arabic or
Chinese, for example?).  Of course, a standard or convention
could be used for embedding processing comments in the content,
but that requires having the content available (would you want to
download a 10 MB file only to find out that you cannot use it?).
A Content-Type field parameter is available when the media
itself is not (via HTTP negotiation, via message/external-body,
etc., and can be used to make decisions about retrieval).
Information in the Content-Type field provides metadata for the
media content, and can be stored in a database entry for the
media content (some computer operating systems have such a
facility for storing metadata for files).  The specific parameters
defined for this specific media type constitute such metadata
which can be stored and retrieved by that general mechanism.
>From [e-mail]  Tue Apr 19 19:13:11 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Apr 19 19:13:18 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]>
	<[e-mail]>
Message-ID: <[e-mail]>

Bruce,

I've already cited the relevant text, and given you several reasons why
this proposal is not acceptable.  Other people have also objected to
the proposal for the same reasons.  

The process parameter as you have defined it is not an essential part 
of this content-type.  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.   Nor is the parameter as you have defined
it portable to different implementations of troff that have different 
options.  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.