Testing the waters for text/troff

[jas at extundo.com (Simon Josefsson)]

Bruce Lilly <[e-mail]> writes:

> ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt

One comment on the "versions" parameter. If it is only meant to be
humanly readable, why can it not be written as a comment?  MIME
parameters are presumably intended for use by software.  It seems
unnecessary to allocate a MIME parameter field for something that
isn't used by software.

The "process" parameter, as in:

   Content-Type: text/troff ;
    process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms"

makes me feel uneasy.  Are MUAs expected to parse the expression to
recognize dangerous commands?  Is this portable?

I looked at how Gnus implement troff files:

    (".man"   . "application/x-troff-man")
    (".me"    . "application/x-troff-me")
    (".ms"    . "application/x-troff-ms")
    (".tr"    . "application/x-troff")
    (".troff" . "application/x-troff")

This suggest that maybe the troff format should not be a considered a
separate MIME sub-type, but rather a set of languages.  Much like XML.

While I think the "+xml" for XML formats was a horrid idea, I can't
help but feel that we'd might have the same situation here, as in:

text/man+troff
text/ms+troff
text/mdoc+troff

That is, those types would be interpreted by loading the -man, -ms and
-mdoc macros, respectively, in troff.  That is, "troff -man", "troff
-ms", "troff -mdoc" respectively.  You could create new types for
dformat+pic data.

Thanks,
Simon