Testing the waters for text/troff

[Al Costanzo]

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 at extundo.com>
To: <ietf-types at alvestrand.no>
Sent: Monday, December 06, 2004 3:59 PM
Subject: Re: Testing the waters for text/troff


> 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
>
>