Dear MIME mailing list:
cc: Mfpa list, Printer working group list, Facsimile standards list:
I have been directed to raise some issues regarding the MIME documents, and
other IETF RFC's that relate to the registry of object types (AKA Media types).
First some background.
MFPA is the Multifunction Peripheral Association. We work on general
document processing, such as scanning, printing, copying, faxing, etc. One
of the issues that is a concern for transmitting files is the CONTENT TYPE,
referred to as MEDIA TYPES by MIME RFC's. The absence of a registry for such
types has been a problem in the past, and we have looked to EMA, ISO, and
others for a solution to this problem. The MIME MEDIA TYPE registry may be
at least a partial solution.
Now for some issues.
1) It is not always clear from the current registry exactly how to determine
what the MEDIA TYPE actually is. For example g3fax is a curious type, which
implies that you are using ITU-T (CCITT) T.4 encoding of the file, plus
perhaps some other stuff that is usually transmitted in other parts of the
g3 fax session. Many times, this "other stuff" is expressed by TIFF
attributes in a TIFF file, and indeed, this "other stuff" is one of the
primary reasons for the TIFF file. So, how does one determine what the
format is for a given MIME type?
We toyed with the idea of the "recipe" structure, which is much akin to the
structure proposed in the MIME registry, i.e. components separated by
separators. In MIME the separators are periods. We chose the vertical bar,
since it was rarely used, and the resulting string is generically:
registry|manufacturer|model|version|serial-number| (etc).
This is if the item is a "part" or a device. It is a similar "GeneralID" if
the item is a format or protocol specified by some standard or other document:
registry|definingbody|specname|version|revision| (etc).
- The proposed MIME scheme is not general in that the registry is not shown
in the type. It would be preferred to include "mime" as the root of all types.
- The proposed scheme is not extensible to as many levels as necessary, at
least from what I have seen.
- The current registry does not show the exact nature of the format, etc.
which would be required if people are going to be able to pass these things
around. I am not complaining about the truly vendor-specific formats, but
certainly to things such as g3fax, where even the facsimile standards people
don't know what it is.
- The current registry certainly has some historical "baggage", which I
don't have a problem with. But we need to have an upgrade path toward the
systematic approach. For example the media type application/postscript is a
vendor-defined type, in the same way that HP-PCL is, but it has a basal
application/postscript type. Now, this should probably propagate to
vnd.adobe.postscript. Also, it needs a version specifier, which is part of
the postscript format, so it should be:
vnd.adobe.postscript.1
and
vnd.adobe.postscript.2
- It is difficult to specify things like "T.4" or "IEEE-xxx.xxx" because you
have reserved the period as the separator. How is this to be handled in a
general way for future mapping of these strings as a guide for the registry
maintenance crew? Do we use the Underscore, minus or what?
2) There is yet another part of the IANA registry which specifies printer
file formats. As an example, Postscript is also in that list, as well as
many other formats that are of interest to MFP (multifunction peripheral)
manufacturers. These two lists are in no way harmonized at this point.
- I would like to see a MIME type at least called out by the printer
language list, when appropriate, so that the two lists are linked. This has
been proposed to the printer working group that was responsible for
RFC-1759, the printer MIB. I don't think this was actually approved yet.
- A better solution may be to use the MIME list as the single registry for
these "file types" rather than have scattered and redundant registries. Such
a trend drastically reduces the usefulness of a registry if we must have
conversion lists between registries.
===
Please note that these comments DO NOT reflect directly on the functionality
of the MIME extensions, but rather on the extended use of the MIME types in
other applications. We see this as an excellent opportunity to leverage the
good work done on the MIME registry for other uses which may need to
interoperate with MIME and internet email.
Thanks for your attention.
-Raymond Lutz
/***********************************************************************
** Raymond Lutz Voice: 619-447-3246
** Director R & D, Cognisys, Inc. Fax: 619-447-6872
** MFPA EC Chair BBS: 619-447-2223
** 1010 Old Chase Ave., Suite B EMail:
raylutz(_at_)cognisys(_dot_)com
** El Cajon (San Diego Co.), CA 92020 USA MFPA: 1-800-603-MFPA
** WWW: http://www.cognisys.com http://www.mfpa.org
***********************************************************************/