I-D ACTION:draft-lilly-text-troff-00.txt

[blilly at erols.com (Bruce Lilly)]

On Mon December 6 2004 23:09, Tony Hansen wrote:
> I have a serious problem with this parameter:
> 
>        process
>           Lists a recommended command pipeline for formatting.  The
>           parameter value may need to be quoted or encoded as provided
>           for by [RFC2045] as amended by [RFC2231] and [errata].
> 
> I'd hate to see someone actually implement a mechanism to automatically 
> execute the pipeline. I think this is just ASKING for someone to do so.

The draft registration text specifically addresses that issue
under Security considerations.  While I agree that *automatic*
execution of a pipeline should be avoided, I see no reason
why the suggested pipeline should not be presented to a user
for confirmation prior to execution (that would achieve the
same thing as manual rekeyboarding of the command
pipeline, but with less potential for typographical errors), if
the user initiated some action that would normally be
associated with execution.

> Now, the information provided in the pipeline IS useful; it provides the 
> list of the preprocessors that are needed to properly process the troff 
> souce. So instead, I'd recommend that there be a parameter that provides 
> just THAT information:
> 
>        preprocessors
> 	Lists the preprocessors that need to be invoked to properly
> 	process the troff input. The names of the preprocessors are
> 	comma separated. The parameter value may need to be quoted or
> 	encoded as provided for by [RFC2045] as amended by [RFC2231]
> 	and [errata].

But it isn't a mere "list of preprocessors"; it's an *ordered* list of
preprocessors, formatter, and postprocessors *with option flags*
and environment variable settings.  Invoking preprocessors in
the wrong order (e.g. running pic before grap) isn't useful, nor
is omitting option flags (e.g. macro packages).  And environment
variables can have a profound effect on operation (try the
latest version of groff's "nroff" w/o GROFF_NO_SGR to format
an I-D or RFC using ms macros NH or SH , for example). Finally,
a comma might well appear in the name of a preprocessor,
formatter, or postprocessor (nothing forbids that, as comma is
not a command interpreter (a.k.a. shell) metacharacter), so
that would require some additional escape or quoting mechanism.

Obfuscating a command pipeline by substituting commas for
vertical bars isn't going to prevent a wayward programmer
bent on automatic execution from making the reverse
translation.  Nor will it prevent careless users from doing the
same.

> In addition, there is one more MAJOR parameter that doesn't appear to be 
> specified anywhere: the macro package that was used in the troff 
> document, such as man, mm, ms, me, etc. So, I'd like to see this 
> optional parameter added:
> 
>       macro package
> 	Lists the macro package that needs to be used with the troff
> 	document. Examples of macro package names are man, mm, ms and
> 	me.

That's specified as an option flag to the formatter. It's also
theoretically possible to have multiple macro packages, though
major ones would almost certainly clash (however I have used
additional macros with -man to handle tables in man pages).
And one cannot have a parameter attribute name with an
embedded space character.