Hello,
I tried some days ago to initiate a debate about mailcap format but
it seems that everyone is a bit overloaded right now. I wrote a little
document, as a basis for a discussion, that puts some ideas black on
white. Let me just tell you that I successfully implemented some of them.
The result is visible at http://lara0.exp.edf.fr/glazman/meufmotif.html
I am waiting for your comments (or flames ;-).
Regards from Paris, France.
</D.Glazman>
--
We absolutely need to make the difference between two areas of
standardization: the first one implies the extension of the mailcap format
itself, that means at least a semi-independance to material contingences,
and the use of the mailcap format, which is directly linked to
system-dependant problems and communication processes.
Even if the mailcap format tried to remain strictly independant to
applications, the integration of MIME in different protocols and under
different computing systems makes managing a unique mailcap for all purposes
a real challenge to system administrators.
It is then suggested to build a new standard based on the following points :
Mailcap format
1.1 Improve mailcap format in order to
1. declare in a mailcap file the version of mailcap format it is
conformant to
@Mailcap-Version 2
2. be able to declare conditions and select mailcap entries depending
on external variables (client, client_version, system,
system_version for instance, [know what ? Thinking aloud...])
@if (client == "meuf" && client_version >= 2)
@append("http://meuf.edf.fr/media-types/mailcap";);
@endif
3. be able to build a media-types table from the contents of an
original (and possibly remote) mailcap file that can access to
other mailcap (and possibly remote) mailcap files.
@append(URL)
@replace(URL)
...
4. add parameters' definitions to each mailcap entry and be able to
discriminate composition command, view command, and so on in
function of parameters' values
parameter = charset ENUM {"us-ascii"|"iso-8859-1"};
parameter = boundary RANDOM "meuf_bnd_%s";
parameter = site STRING "ftp.edf.fr";
...
1.2 add new functionalities to mailcap format :
1. split the view command, which is not a field in RFC 1524 mailcap
format like other commands attached to an entry, in different
fields (unique choice) :
view = blabla %s;
which means that the client has to call this external view command
in order to visualize such a bodypart
copiousoutput;
which means that the user agent knows how to visualize such a
bodypart type by itself without external help
The absence of both choices means that no visualization process is
currently attached to this mailcap entry.
2. add a new field that contains a command line to be called before
bodypart visualization as a format translator. The user agent
should use its standard output, if any, as result.
preprocessor = vn7to8 %s;
This example will allow a VISCII compliant user agent, having
correct fonts for vietnamese text edition, to render properly a
text composed in 7bit VIQR. Used in conjunction with copiousoutput
field, it can give users opportunity to move from a 7bit
old-fashioned e_mail system to a MIME internationalized system.
3. as a RFC 1524 conformant user agent can call, for a given
mediatype, an external viewer or use its embedded functionalities,
a user agent should be able to compose a bodypart using an
external composer OR its internal functionnalities. It is then
suggested to add two new fields to standard mailcap format,
exclusive to compose field.
inlineinput;
which means that user agent knows how to compose that kind of
bodypart and that this composition is not made through a file
selector.
fileselection;
which means that user should not really compose such a media-type
but only choose a local file.
Absence of all choices means that media-type is not composeable.
4. a postprocessor shoud be called when a user agent has capacities
to compose a coded or "light" version of a bodypart and capacities
to visualize the full version of the bodypart but not the ability
to compose it...
postprocessor = vn7to8 %s;
This would allow a UA to compose a vietnamese text in VIQR and
send it in 8bit VISCII...
5. specify the default transfer encoding for the media-type :
default-transfer-encoding = quoted-printable;
6. specify the default content-disposition to be used when composing
such a media-type or to be used when visualizing a message
partially or fully non conformant to RFC 1866
image/gif; \
...
default-disposition = inline;
...
7. extend the x11-bitmap definition. This field should be renamed
icon. Used in conjunction with conditional cases (@if), it can be
used under all computing systems.
icon = /usr/local/faces/etc/text/face.xbm;
icon = c:\images\text.bmp;
Its type should be included in a new field icontype. The value of
this field is a MIME media-type.
icontype = image/gif;
icontype = image/cgm;
Mailcap Use
2.1 Define more precisely how new media types should be submitted to IANA
and registered by IANA. Think about automatic distribution of the registered
entry by electronic means.
type/subtype
description = ...
paramater = ...
parameter = ...
default-transfer-encoding = ...
default-disposition = ...
2.2 Create a new media-type (application/mailcap for instance [just thinking
aloud]) that would allow a mailcap file to be distributed by MIME conformant
protocols, ie e_mail and HTTP. Give correct parameters to this media-type in
order to be able to act in all normal ways on a remote mailcap file (append,
replace, ...).
application/mailcap
description = MIME mailcap entry
parameter = action ENUM {"append"|"override"|"announce"}
default-transfer-encoding = 7bit
default-disposition = attachment
2.3 If security considerations are not too important, define a new multipart
media type (multipart/self-supporting for instance [still thinking aloud])
made of a bodypart and its associated application/mailcap.
2.4 Extend the standard locations of a mailcap file as defined in RFC 1524
to a default URL location (http://mailhost/mailcap for instance, where
mailhost is defined in the local DNS). In decreasing order of priority :
1. user specific location; possibly defined under Unix as
~user/.mailcap (see RFC 1524 appendix A)
2. host specific location; see also RFC 1524 appendix A
3. site specific location; proposal : http://mailhost/mailcap
---------------------------------
</Daniel>