Bruce Lilly <blilly@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