I disagree. I see no reason why you cannot allocate a param as a comment and I support it. Al ----- Original Message ----- From: "Simon Josefsson" <jas@extundo.com> To: <ietf-types@alvestrand.no> Sent: Monday, December 06, 2004 3:59 PM Subject: Re: Testing the waters for text/troff
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