Re: RFC 1524

[Daniel Glazman <[e-mail]>]

Ok, let's discuss a little bit before my head explodes (and my wife
calls me for dinner ;-)...

The thing we need first in mailcap format, in my opinion, is a
discrimination by parameter's value for each entry.
As an example, the composition command of a text/plain may
seriously vary in function of charset's value. A "us-ascii"
text could use the builtin user interface widgets and a
"iso-8859-8" could use an external post-processor in order
to translate latinized (us-ascii) hebrew into hebraic characters
in the corresponding charset. I know that this can be managed by
view-commands, compose-commands, and so on but this is not easy
to use in a tool which does not want to count on external viewers/
composers. And my (maybe yours too ?-) goal is to build/use a really
wysiwyg mime MUA pluggable into a brand new computer with just OS
on it and nothing else.

I think that two main ways are possible  :

1) associate a mailcap entry to each parameter's variation. This can
   be the byte-greediest solution but I think it's the simplest to implement
   from the existing mailcap format.

2) integrate in each entry a way to switch (as a C statement) in
   function of a paremeter's value. This is nicer but also more
   complicated. 

Example case 1:

	text/plain; cat %s; \
		parameter=charset STRING "us-ascii"; \
		compose=bla-bla-something; \
		copiousoutput

	text/plain; heboutput %s; \
		parameter= charset STRING "iso-8859-8"; \
		bla-bla-bla

Example case 2 :

	message/external-body;
		parameter=access-type ENUM {"ftp", "anon-ftp", bla, bla }; \
		parameter=name STRING; \
		parameter=site STRING;\
		...
		case (access-type="ftp", bla-other, bla-conditions) \
			view=...;\
			compose=...;\
			end; \
		case (access-type="anon-ftp", bla-other, bla-conditions) \
			view=...;\
			compose=...;\
			end; \


Still thinking aloud and waiting for your reactions (I hate time shifts).
BTW, how will a tool make the difference between a "old format" mailcap and a
new one if any ?

</Daniel>