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

[Larry Masinter]

> > I wish you would reply and say why you think your proposal
> > (put processing instructions in a parameter) is better than
> > what I recently proposed as an alternative (put processing
> > instructions in a comment in the body).

You give, as your justification for having a process
parameter for text/troff, the use case that the receiver
might automatically determine whether remote content
is processable, and avoid downloading content that it
couldn't process.

> See the issues regarding retrieval of sizable remote content.

However, this use case doesn't make any sense. If,
as you assert, the receiver isn't going to automatically
process the content anyway, but rely on a person to
type in the process parameter after somehow verifying
its safety, then there isn't generally a good ability
to determine processability. After all, the user, if
the user wants the content, may very will download
and install the appropriate macro or processing capabilities.

You're right that the problem with MIME parameters is
general. In general, I think it's a bad idea to put
information in MIME parameters that isn't absolutely
necessary for automatic processing. In general, users
*don't* have a file system with multiple text/plain files
which differ by charset.

Larry


Larry