Media Subtype Registration for Media Type text/troff
draft-lilly-text-troff-04

To be addressed during auth48 (last second comment from Tony Hansen ):

Can the examples be changed such that at least one of them (if not both) uses prose text in the process= parameter? I'd like it to made be even more clear that these are not executable statements. For example, instead of

process="pic -n | troff -ms"

how about

process="needs pic -n and troff -ms"

[Ballot comment]
Bruce has suggest some text to update this text


      A command line, such as may be suggested via the optional
      "process" parameter, is a powerful tool when used by a
      computer-literate person.  Individuals lacking basic security
      knowledge and/or common sense SHOULD NOT be given unsupervised
      access to a command line.  Users of this media type SHOULD
      carefully scrutinize the suggested command pipeline and media
      content before executing commands.


 
I'm fine with Bruce's text (sent in email), and Scott will hold the discuss until it
has popped out.

[Ballot comment]
I'm dubious of the claim that application/* and image/* should be used
for roff input that is pictorial or otherwise is not human
comprehensible.  I'm sure that's correct from a MIME purist standpoint
although it seems problematic to have multiple media types for the
same media.

[Ballot discuss]
The document currently says this:

      A command line, such as may be suggested via the optional
      "process" parameter, is a powerful tool when used by a
      computer-literate person.  Individuals lacking basic security
      knowledge and/or common sense SHOULD NOT be given unsupervised
      access to a command line.  Users of this media type SHOULD
      carefully scrutinize the suggested command pipeline and media
      content before executing commands.

I don't see who exactly we're tasking with this supervision.  I suggest
the following replacement:
 

    Users of this media type SHOULD carefully scrutinize suggested command
    pipelines associated with the process: parameter both for attempts at
    social engineering and for the affects of ill-considered values of the parameter.
    While some implementations may have "safe" modes, those using this parameter
    MUST NOT presume that they are available or active.

[Ballot comment]
(from Gen-ART review by Elwyn Davies)

...this document appears almost ready for publication.  Clearly troff, nroff and their many relations are still hale and hearty and are in regular use (as we know only too well for RFCs) so that this is a useful document and appears to cover the area satisfactorily. There is one item which seems to need improvement and a couple of minor quibbles.

Security Considerations:  The second (and last) sentence states:
"Additional considerations may apply in some contexts (e.g. MIME[I17.RFC2049])."
This is a vague catch-all which I think needs some refinement.  I also can't see the relevance of RFC2049.. maybe RFC2046 might be a better reference here?  I can't suggest new text because I am unsure what the author means by it.

A couple of quibbles:
The lists of formatters and format converters in 'Applications which use this media type' may not be complete.. I can think of at least one other that has (and may still be around - I am not a xroff user these days) - psroff.  Is this intended to be complete? or should it include something like '... and equivalent tools'?

Appendix B: we appreciate that the author has objections to some of the legalistic flights of fancy that are required features of I-Ds and RFCs, but I would venture to suggest that the irony is misplaced here, and may even have been overtaken by events... the boilerplate moves faster than the I-D production process?

Reference to RFC2048: The document should refer to and provide the relevant normative reference to RFC2048 which specifies the format of the registration form at the heart of the document.

The document has been updated to address the last call comments provided by Keith Moore, Tony Hansen, and Larry Masinter.  All have confirmed that they can live with the new text.

Last call comments from Keith Moore :

I recommend against publication of this document as an RFC,
unless and until it is revised to fix the following problem:

section 4:

the process parameter appears to be a security hole, as it would
allow the sender to specify commands to be executed on the recipient's
system.  while this is documented in the security considerations section,
it is unnecessary, and long experience with implementations that provide
similar capability (e.g. the ability to launch an arbitrary application
based on the file name suffix) indicates that significant harm can come
from allowing the sender of a message to specify actions to be taken
by the recipient's MUA. 

furthermore the process parameter is unlikely to be used by the recipient
_unless_ its handling is automated, because most MUAs do not make it easy
to see the content-type parameters associated with an attachment.  so
the parameter as defined is more likely to do harm than good, and
it would set a bad precedent for other content-type definitions.

if anything I would make the process parameter a list of keywords:
pic, eqn, tbl, etc.  the keywords should not be treated as commands
by the recipient's system (and certainly should not be looked up in the
recipient's PATH), but rather as flags to be passed to a processor such
as groff that knows where to find these programs and in what order they
should be run.

there is also a need to specify what macro package is used: e.g.
-ms, -me, etc.

actually the varied handling of troff (and TeX) documents is probably
the reason we never defined a content-type for either of these.  we
certainly considered doing so at the time the MIME documents were being
written, and we used these file formats as examples of content which,
when interpreted on a recipient's system, could cause security breaches.