Re: misconceptions about MIME [long]
Ned Freed (NED@sigurd.innosoft.com)
22 Oct 1992 22:39:33 -0700 (PDT)
Date: 22 Oct 1992 22:39:33 -0700 (PDT)
From: Ned Freed <NED@sigurd.innosoft.com>
Subject: Re: misconceptions about MIME [long]
To: nsb@thumper.bellcore.com
Cc: nsb@thumper.bellcore.com, masinter@parc.xerox.com,
Message-Id: <01GQ9KR9LCZ09D4EDD@SIGURD.INNOSOFT.COM>
Nathaniel was kind enough to forward your message to me.
> I recall being flamed rather severely by Ned Freed when I suggested
> that MIME was inadequate because the specification of format-types
> such as 'postscript' or 'gif' didn't specify enough about format
> versions, external resources used, etc.
The flaming, if you wish to call it that, was caused by what I saw as a
repeated failure on your part to read the words I was writing. I certainly did
not flame you because of this idea. It isn't a bad idea on the surface; it only
falls apart upon close examination.
> Many of his arguments were based on the practical difficulties of
> requiring any kind of additional standardization for document format
> versions in a distributed mail application.
My position regarding PostScript is based on three facts:
(1) Mechanisms already exist for imbedding all this information inside
PostScript objects. This format is readily understandable and easy to
process.
(2) Generation of this information if it isn't already in a given object isn't
just hard, it is totally and completely impossible. It is trivial to
demonstrate that this is equivalent to the halting problem. The notion
that something "close" the correct could be generated with a little work is
highly suspect, as are the advantages of producing external labelling that's
guaranteed to be inaccurate in some cases.
(3) When the external information <> internal information you have a silly
state. A guiding principle of the working group was to avoid silly
states whenever possible.
Modulo the notion in (2) these are all facts and not opinions. Based on these
facts I think external format labelling of PostScript is an extremely bad idea.
I am much less familiar with GIF and I have relied on other folks who are
more expert than I to deal with GIF issues.
> Now that MIME is out as a proposal for mail, I still believe that
> these problems should be addressed before MIME is appropriate for
> database, archival and retrieval applications.
As far as PostScript goes I think I have made my position clear. It has not
changed in any way since we last communicated. However, my position on
PostScript does not necessarily apply to other formats. Each format is a
separate beast and must be handled in a manner that matches its nature. Just
because I am opposed to external labelling of PostScript doesn't mean external
labelling of something else is inappropriate. It usually boils down to
examination of three issues:
(1) Is internal labelling feasible? If feasible do applications actually use it?
(2) How hard is it to derive external label information? There are basically
three possibilities: it is either something you just have to know (like
the character set), it is always part of the object (like WordPerfect
version numbers), or it can be produced from analysis of the input.
(3) Is there potential for conflict between internal and external labelling?
The interactions between these things is complex; I have never derived an
explicit cause-and-effect path from these to whether or not an external
label should be used.
> In addition, the current mechanism in MIME for external references suffers the
> same problem that other references mechanisms that are based on
> hostname/pathname have: files move, change in place, host names come and go
> over the years.
I certainly agree that this is a problem. I would love to see it solved, and I
would welcome the introduction of additional parameters to solve it.
However, I don't see any way to solve it without introducing at least one
additional level of indirection. This means some kind of directory service
would have to be deployed. Now, this may be a good idea, in fact it may be a
terrific idea, but it is somewhat beyond MIME's purview to define a directory
service for locating objects.
In other words, I believe the solution to this problem would at a minimum
involve the introduction of some kind of directory service (which could be
accessed via MIME messages but in practice would probably require a direct
protocol connection) and the definition of a new sort of external reference
with parameters appropriate for reaching this service. The difficult parts of
this are the methods you use in the directory to keep existing pointers valid
and the definition of the directory access protocol itself. The extensions to
MIME are the trivial part.
I would welcome further discussion on how we should work towards solving
these problems.
> Both these problems are not trival to solve, but I don't think they
> are unsolvable.
They are extremely difficult problems to solve. However, the first step towards
their solution is to focus on where the problems really are, and I don't think
that's MIME.
Ned