regarding your comments on proposed media type text/troff' to Informational RFC

[moore at cs.utk.edu (Keith Moore)]

Bruce,

bottom line - this parameter violates both the intent and the wording 
of the MIME spec.  it's simply unacceptable.
solve the problem in a different way.

Keith


On Apr 16, 2005, at 11:12 AM, Bruce Lilly wrote:

> On Fri April 15 2005 10:36, Keith Moore wrote:
>
>> And you dismissed the objections that other people raised about this
>> very issue on that list.
>
> No, wording of the draft was changed as a result.
>
>>> The "process" parameter is explicitly *NOT* "giving the sender a way
>>> to choose what program to run on the recipient's system".  It is a 
>>> way
>>> for the sender to suggest a recommended processing sequence to the
>>> human recipient.  N.B. "suggest", "recommended", and "human".
>>
>> It's a distinction without a practical difference.
>
> No, if some wayward implementer were to automatically execute programs
> contrary to the specification, said implementer can be informed that he
> is out of line.  That is a very real "practical difference" between the
> actual draft and your mischaracterization of what the draft says.  You
> seem to:
> a) want to remove any standardized mechanism for the author to convey
>    relevant information to the recipient
> b) believe that groff can magically determine preprocessors, an
>    appropriate ordering of preprocessors with appropriate arguments,
>    etc.
> Removal of the "process" parameter will not prevent a wayward 
> implementer
> from simply automatically invoking groff; removal of the parameter
> therefore will not address inappropriate use of the media type and
> metadata, and removal of discussion of inappropriate use of said 
> parameter
> along with its specification would leave no stick with which to educate
> such implementers.  It will, however, impair legitimate uses of the 
> media
> type and metadata.
>
>> There have been similar recommendations in every version of the MIME
>> spec. Guess what?  They were consistently ignored by major vendors.
>> Running code and hundreds of billions of dollars worth of damage due 
>> to
>> viruses  aptly demonstrates that even though the spec says "don't
>> present executable content" implementations will do it anyway.
>
> Don't blame me for inappropriate behavior of some unrelated vendor. If
> multiple recommendations haven't prevented inappropriate 
> implementations,
> what leads you to the conclusion that failing to make recommendations
> will improve matters?
>
>> The
>> process parameter is executable content.
>
> No, it's a human-writable, human-readable hint in a well-understood,
> precise, concise, standardized (e.g. POSIX) format.
>
>>> The intent is to specify the preprocessors and parameters which will
>>> produce the output that the author intended, not arbitrary progams/
>>> parameters.
>>
>> If the author wants to enclose a Makefile or build script as a 
>> separate
>> text/plain attachment, he's free to do so.
>
> You seem to be fixated on a niche application of media types, which are
> being separated from the mail environment.  In general, there is 
> nothing
> in which to "enclose" separate content, or to which to make an
> "attachment".  Consider, as an example of possible use outside of a 
> mail
> environment, a means of recording such metadata in some sort of 
> database
> with entries for files (e.g. similar to a MacOS "resource fork", or the
> comments field which can be set for files in recent versions of MS
> Windows).
>
> Moreover, a "build script" would fit into the category of "languages 
> for
> 'active' (computational) material", which is the application media 
> type,
> not text, and certainly not text/plain.  See
> draft-freed-media-type-reg-04.txt.
>
>> It's a lousy way to do that.  Parameters are typically not displayed 
>> to
>> the recipient.  They're either interpreted my the MUA or ignored.
>
> Again, you're fixated on a mail environment, which is not the only
> application for media types.
>
>> Let me get this straight.
>
> OK, I'll try to clarify the situation.
>
>> First you argue that the process parameter
>> isn't intended to be executed,
>
> Not intended to be automatically executed.  If the human recipient,
> after exercising due caution, wishes to follow the suggestion supplied
> by the content author, he is of course free to do so -- or he can
> execute some other, possibly similar set of processes, or he can choose
> not to format the content.
>
>> and then you argue that a different kind
>> of parameter that only specified the preprocessors to be used would
>> not be appropriate because _it_ couldn't be executed?
>
> No, the objections to a mere unordered list of preprocessors includes:
>
> 1. preprocessor order is critically important
> 2. preprocessor arguments are critically important
> 3. environment variables (e.g. GROFF_NO_SGR in recent groff versions)
>    may be critically important
> 4. formatter arguments are critically important
> 5. postprocessing may be required
>
> Your suggestion addresses none of those issues, all of which are
> accommodated by command-line syntax.  Moreover:
>
> I. command-line syntax is easy for an author to indicate, with 
> precision
>    and conciseness
> II. command-line syntax can be read, understood, modified if desired,
>    and used by recipients.
>
> A mere list lacks those characteristics.  Obfuscating processing steps
> by some sort of mechanical translation of easily-generated, easily-read
> syntax adds extra manual, error-prone steps for both author and 
> recipient,
> but will not slow down a wayward implementer who is determined to
> automatically pass content to a program; he'll simply automate the
> translation.  That would have precisely the opposite effect of the
> current wording of the draft; it would make legitimate use difficult
> while making automated misuse straightforward.
>
>> And then you're arguing that the purpose of the process parameter
>> isn't to specify arbitrary code to be executed,
>
> Correct.
>
>> but you also admit
>> that there's no clearly defined set of preprocessors for troff?
>
> No, at any given time, one can enumerate a set of preprocessors, as has
> been done in the registration template in the draft under discussion --
> but that set may change over time as new preprocessors are developed.
> One can clearly define a set of preprocessors as programs with the
> following characteristics:
>
> i. the program operates as a filter, accepting input and producing
>    output (as opposed to programs which do not do both, such as "ls",
>    etc.)
> ii. The input and output formats conform to troff format conventions as
>    specified in CSTR 54, e.g. directives intermixed with text, 
> directives
>    begin with dot, etc.
> iii. input is human-readable content describing some abstract format
>    which is translated into formatting directives or to another human-
>    readable format for further processing with the ultimate goal being
>    production of formatted output
> iv. the input to be preprocessed is delimited by specified directives,
>    and other input is passed to the output unaltered (so the programs
>    in the graphviz suite, which can generate pic output, do not
>    qualify as preprocessors because they do not accept/pass other
>    input).
>
>> If there's no clearly defined set, it's arbitrary.
>
> There is a clearly defined set; see above for a definition.
>
>>>> The Version 7
>>>> UNIX versions of these tools (circa 1979) described in the "CSTR 49"
>>>> document you cite had several limitations (many related to having to
>>>> run in 64k of code space on a pdp 11/70), that don't apply to modern
>>>> troff implementations.
>>>
>>> How is that relevant?  The CSTR documents have been updated.
>>
>> Some of the problems with ordering of preprocessors had to do with 
>> some
>> preprocessors running out of memory if earlier preprocessors generated
>> lots of output.
>
> While that might be relevant to a recipient with a particular legacy
> implementation, it is not relevant for the purpose of describing the
> preprocessors, their order, their arguments, and environment settings
> necessary for successful formatting of particular content.
>
>> So design a parameter that specifies ordering without specifying the
>> command-line.
>
> See above reasons why that would be harmful to the intended use for
> end-to-end, human-to-human communications intended for the parameter,
> and why it would not deter determined but wayward implementers.
>
>> The reality is that in practice troff isn't a single data format, it's
>> a lot of fairlly arbitrary variations on a format.
>
> Not arbitrary.
>
>> For this reason,
>> it doesn't lend itself to easy MIME typing.
>
> As mentioned in the draft, some specific instances of content might be
> more appropriately categorized under the image or application media
> types.  The draft explicitly does not address those cases.
>
>> So specifying a sane
>> MIME type for troff is a harder problem than it initially seems,
>> and you're running into that.
>
> No, there's no particular difficulty in specifying the format for
> text use.  Your complaints seem to boil down to implementers who
> ignore existing recommendations which are reinforced in the draft
> under discussion.  Nothing that can be said in this particular draft
> is likely to change that for this media type or any other -- idiotic
> implementers are what they are.  Making media types more difficult for
> legitimate, conscientious users to use on the groundless assumption
> that that will cause determined wayward implementers to see the light
> smacks of a "nanny" or "Big Brother is Watching You" approach.