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

[Bruce Lilly]

On Wed April 20 2005 15:24, Tony Hansen wrote:
>  From a process point of view, can we declare consensus on removing the 
> process= parameter?
[...]
> Bruce, would you be willing to declare that the skirmish was lost, but 
> the battle won, and republish the document without the process= parameter?

Removal of the parameter would require additional changes; at minimum
to the security considerations and to the last paragraph of the
registration form.  More important, it would leave no means of content
negotiation (there are some mechanisms which use RFC 2506/2533/2534/2738,
but those mechanisms do not have provision for the sort of information
that needs to be conveyed, and require a separate registration
mechanism which would raise chicken-vs.-egg issues) or for indicating
processing steps in a language-independent manner separate from but
clearly related to the content (which may be sizable and remote) short
of providing truly executable content in a separate file; and that
approach has practical problems (for a start, it lacks a clear
relationship to the specific content) and raises several security
issues.

I can see no mechanism for making substantive revision to the definition
of a subtype's parameters (as opposed to adding commentary -- and that
doesn't seem to work particularly well); adding a parameter at some
later stage, even if possible, would raise issues about versioning of
the media subtype specification (as distinct from version information
regarding the defined content or the applications needed to process
that content). So it seems impractical to rush through a partial subtype
definition now in the hope that it could be fixed later.

I believe that the issues can be dealt with by revision to the parameter
definition; I'll propose some specific text later today.

If a suitable compromise can't be reached, it may be best to simply
withdraw the proposal; the universe has survived for several billion
years without such a subtype definition, and there are current products
which work around the lack of a suitable standards tree definition by
using unregistered, unregisterable types such as application/x-troff.