On Mon December 6 2004 15:59, Simon Josefsson wrote:
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 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.