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

[Keith Moore]

> On Thu April 14 2005 22:49, Keith Moore wrote:
> > [cc'ed to ietf-types list, which per RFC 2048 is where this document
> > should be reviewed.]
> 
> Pre-draft discussions and earlier drafts have been discussed on
> ietf-types; 

And you dismissed the objections that other people raised about this
very issue on that list.

> > I raise this concern both because this was something that was
> > discussed  extensively in the ietf-822 working group that created
> > MIME, and also  because we've seen far too many security holes
> > result from giving the  sender a way to choose what program to run
> > on the recipient's system 
> 
> The "process" parameter is explicitly *NOT* "giving the sender a way
> to choose what program to run on the recipient's system".  It is a way
> for the sender to suggest a recommended processing sequence to the
> human recipient.  N.B. "suggest", "recommended", and "human".

It's a distinction without a practical difference.


> > RFC 2046 (section 4.5.1) even includes the following language, which
> > 
> > also appeared in RFCs 1341 and 1521:
> > 
> > >    To reduce the danger of transmitting rogue programs, it is
> > >    strongly recommended that implementations NOT implement a
> > >    path-search mechanism whereby an arbitrary program named in the
> > >    Content-Type parameter (e.g., an "interpreter=" parameter) is
> > >    found and executed using the message body as input.
> 
> I fully agree that implementations should take suitable precautions. I
> would (and have in the draft) go farther and state that
> implementations (w.r.t. text/troff) should not automatically process
> content other than possibly stripping directives for presentation. 
> And there are some specific additional recommendations for safe
> presentation whether or not directives are stripped (e.g. precautions
> against control characters). 

There have been similar recommendations in every version of the MIME
spec. Guess what?  They were consistently ignored by major vendors. 
Running code and hundreds of billions of dollars worth of damage due to
viruses  aptly demonstrates that even though the spec says "don't
present executable content" implementations will do it anyway.  The
process parameter is executable content.

> > and to allow the sender to  
> > specify arbitrary preprocessing programs and arbitrary parameters to
> > those programs.
> 
> The intent is to specify the preprocessors and parameters which will
> produce the output that the author intended, not arbitrary progams/
> parameters.  

If the author wants to enclose a Makefile or build script as a separate
text/plain attachment, he's free to do so.  

> The nature of the text media type is that subtypes of that type are
> (supposed to be) presentable to a user w/o processing of any type (as
> discussed in some detail in the draft).  As with some other "rich"
> text subtypes, the proposed text/troff may also be processed for
> improved presentation (e.g. to produce hard copy).  The "process"
> parameter merely provides hints for the recipient to perform such
> processing *IF* the recipient decides to do so.

It's a lousy way to do that.  Parameters are typically not displayed to
the recipient.  They're either interpreted my the MUA or ignored.

> > Nor am I persuaded by the "sender must specify the order of 
> > preprocessing" argument, as groff has options to specify which of 
> > several preprocessors to use, and it seems to work fine.
> 
> At the risk of being repetitive, no, groff's limited facility is
> inadequate:
> 
> o groff is not installed everywhere
> 
> o there are different versions of groff; some have no support for the
>   grap preprocessor
> 
> o no version of groff up to the present one has support for either
>   chem or dformat preprocessors, or for preprocessors such as the 
>   one for handling ABNF
> 
> o groff uses fixed order of preprocessing, with eqn last.  That fails
>   miserably for documents with equations in graphs (CSTR 114) or with
>   equations in tables (CSTR 49) or both
> 
> o groff's fixed order does not accommodate tables in diagrams, which
>   is certainly possible.

Let me get this straight.  First you argue that the process parameter
isn't intended to be executed, and then you argue that a different kind
of parameter that only specified the preprocessors to be used would 
not be appropriate because _it_ couldn't be executed?

And then you're arguing that the purpose of the process parameter
isn't to specify arbitrary code to be executed, but you also admit
that there's no clearly defined set of preprocessors for troff?
If there's no clearly defined set, it's arbitrary.

> > The Version 7  
> > UNIX versions of these tools (circa 1979) described in the "CSTR 49"
> > document you cite had several limitations (many related to having to
> > run in 64k of code space on a pdp 11/70), that don't apply to modern
> > troff implementations.
> 
> How is that relevant?  The CSTR documents have been updated.  

Some of the problems with ordering of preprocessors had to do with some
preprocessors running out of memory if earlier preprocessors generated
lots of output.

> Moreover,
> the primary consideration is the order which is necessary to produce
> proper formatted output; the order that works for tables in diagrams
> is different from the order that works for diagrams in tables, in a
> mutually exclusive relationship (i.e. there is no order that will
> cover both cases).

So design a parameter that specifies ordering without specifying the
command-line.

The reality is that in practice troff isn't a single data format, it's 
a lot of fairlly arbitrary variations on a format.  For this reason, 
it doesn't lend itself to easy MIME typing.  So specifying a sane 
MIME type for troff is a harder problem than it initially seems, 
and you're running into that.

Keith