[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIME implementation documentation
At 09:39 96.08.21 -0700, Ned Freed wrote:
>What John did not mention, however, is that the MIME specification itself
>provides detailed information on what MIME conformance and interoperability
>really mean. In the case of multipart/alternative, for example, a display agent
>is said to be MIME conformant if it is capable of displaying only the first
Let's lay aside the generating agent question for a bit (probably not long,
but I think I can say something more clearly if it doesn't intrude). Let's
also lay aside the letter of the rules and try to think a bit in terms of
(i) It is clear that the existing MIME documents contain a rule that says,
in essence, that a receiver can be conforming if it treats "multipart/Frob",
for substantially any "Frob", as "multipart/Mixed". I've heard no one
(ii) One of the implications of (i) is that we don't have to include _any_
of those frob-instances in the standard itself. The conformity rule is
satisfied with or without them.
That brings us to what I think is the first important question: "what should
the criteria be for singling out some 'frob' for inclusion in the standard"?
I think you have given one answer --an answer with which I'm about
half-satisfied-- i.e., that there is a useful distinction between "frob" and
"mixed" (for "frob" = "parallel" in this case).
(iii) But we don't write IETF standards on the basis of theoretically useful
distinctions. We write them (or at least advance them) on the basis of
demonstrated utility, demonstrated in running code. I'm pushing on this
one because, if the distinction is useful in running/operational practice,
then I would expect to see implementations that treat "parallel" (or any
other "frob" proposed for standardization) as actually distinct from
"mixed", i.e., that take advantage of the distinction.
That desire has nothing to do with whether an implementation conforms or
not. It has to do with whether or not the feature is exercised to a
sufficient extent that we can determine, by examining the experiments/
* the feature (or the distinction which it implies) is, indeed, useful
* it is adequately defined, and useful in the form in which it is defined
If all, or even most, of the implementations of "parallel" treat it as
"mixed", then perhaps the message is that the implementors don't think
"parallel", as defined, is worth the trouble. We are, I believe, obligated
to at least examine that hypothesis.
(iv) Given the way the conformity rules are written, an important capability
of a conforming MIME implementation is that it be able to treat any
unrecognized variant on multipart (e.g., "multipart/frob", as above) as if
it were "/mixed". I will happily stipulate that feature of the standard to
have been more than adequately demonstrated in independent, interoperable
implementations. But that says a lot about "multipart/frob", and almost
nothing about "multipart/parallel".
(v) Finally, part of what makes this discussion important is that several
people in the community (I fear that I'm among them) have expressed doubts
that "/parallel" carries sufficient information that a receiver can do
something that is really what the sender intended in most important cases
(I'm not arguing that we should try to write a standard that specifies that
the receiver must do so, only that it should be possible for it to have
sufficient information available to do so if both sender and receiver want
that). Without adequate information passed across the protocol, what the
sender is saying to the receiver is "probably you might think about not
'displaying' these body parts serially, but now you get to guess what I
think your user should experience". I'm not convinced that level of
distinction is worth incorporating in a standard. Implementations and happy
users could easily convince me.
And I'm not coming in late on this: I think the archives will show that some
(or most) of these concerns were expressed when MIME was first being
defined, but that there was a rough consensus on letting the thing move
forward in the hope that we would learn enough from implementation
experience to either revise it and get it right, accept it as it was (i.e.,
better than we thought), or pull it. That type of conditional advancement
has to run out sometime; it is worth noting that it ran out on the
originally-standard "richtext" long ago.
The refutation for those concerns is, of course, running implementations
that demonstrate that "/parallel", as defined, is a useful distinction and
that it, indeed, conveys sufficient semantics of the right sort. What I'm
trying to avoid here is advancing the thing now and then having to deprecate
it at some point in the future when someone figures out the right way to do
what we both intend. If the thing isn't demonstrably solid today, I think
there is a strong case to be made for holding it back and letting it advance
under its own steam.
p.s. I'm not terribly opposed to the scenario you suggest for moving ahead.
My main concerns are that we not send misleading signals to implementors and
that we not move a feature that doesn't have _demonstrated_ usefulness and
interoperability when actually implemented into full standard. Given that,
while I'd personally rather see things cleared out now, I could certainly
live with not pulling it (or not) until we are ready to advance things to