Testing the waters for text/troff

[Bruce Lilly]

On Mon December 6 2004 15:59, Simon Josefsson wrote:
> 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 versions parameter is intended to be human-readable.
"A comment" is somewhat nebulous (support for comments,
as well as specific syntax, may differ in some contexts). Also,
there is no expectation that comments will be preserved
during transport and processing, whereas there is no reason
to believe that any parameter would be discarded.  I see
nothing in RFCs 2045, 2048 that indicate that parameters
are intended solely for machine use.  The purpose of labeling
some content as a particular media type is presumably to
provide some useful metadata about the content, regardless
of whether that metadata is used by a human or by a
machine.

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

I would say that MUAs may ignore the parameter, or they may
offer to run commands subject to user approval.  Under no
circumstances should execution of general-purpose processing
programs be performed by MUAs without user consent -- see
RFC 2046 discussion of application/postscript.  In this case,
similar considerations apply (e.g. while it may be safe for a UA
to process this content via deroff, there should be no
automatic processing of the originator-specified command
pipeline.  I believe the issues are discussed in the Security
considerations section of the registration template.

Bear in mind the fact that the optional process parameter is
provided as a means of conveying formatting process
information associated with the media; such processing is
not necessary to read the *text* in the media (similar to
text/sgml).

> Is this portable? 

Portability issues are addressed in the Interoperability
considerations section of the registration template, and
via the versions parameter.
 
> 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.

IMO that way lies madness.  Such details do not affect the
ability to read *text* in the media.  Moreover, there are so many
possibilities that the number of media sub-sub-subtypes would
be daunting -- I don't need and wouldn't want a
text/dformat+chem+grap+pic+eqn+tbl+mm+4014
media type, or a
text/dformat+chem+grap+pic+tbl+eqn+mm+4014
media type (depending on whether or not equations appear
within tables).   Now that might (or might not) make
sense for an *application* subtype scheme, but it is
uncalled for for the purpose of a *text* media type.  I
thought I had addressed that issue in section 3 of the
draft (Scope of Specification), but I can reword that
section more forcefully if necessary.