Testing the waters for text/troff
Simon Josefsson
jas at extundo.com
Mon Dec 6 21:59:16 CET 2004
Bruce Lilly <blilly at erols.com> 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
More information about the Ietf-types
mailing list