Possible directions for mailcap format

[Daniel Glazman <[e-mail]>]

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>