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

[Bruce Lilly]

On Tue April 19 2005 23:22, Larry Masinter wrote:

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

I believe that I did not say "automatically".  I meant that a
human recipient could decide whether or not to retrieve content
based on information supplied.
 
> > 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.

Due to copyright issues, policy issues, economics, etc., a user might
be unable to install some resource.
 
> 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.

Surely you're not suggesting that a "filename" parameter should be
used in a purely automated manner (i.e. w/o at minimum user veto
power)?

> In general, users 
> *don't* have a file system with multiple text/plain files
> which differ by charset.

I can't speak for the general case, but most files that I generate are
in US-ASCII, a few in iso-8859-1, and a smaller number in other
charsets.  Those that I have in my file systems as obtained from other
sources are in a wide variety of charsets (utf-8, euc-kr, GB2312, utf-7,
etc.).