Ned,
I'm really not trying to have an argument here, just to raise a
question, following Harald's, about what various maturity steps
in the process mean in an applications context.
It seems to me that there are two positions at opposite ends of
some spectrum and that both are totally unreasonable. They are:
(i) An applications standard that specifies a format for the
transmission of information (which is basically all that MIME,
HTML, RFC 822, and, for that matter, MOSS in all of its
variations, do) has adequately demonstrated interoperability if
it is possible to demonstrate that it can be created somehow
(an intra-host matter that is of no interest to IETF), sent over
a TCP connection, and received without information loss (or with
no more information loss than is explicitly permitted by the
specification). There is no requirement that the receiving
system be able to interpret what is sent in the fashion the
sender intended (since that is another intra-host matter), only
that the bits arrive and, hence, the quality of the semantic
specification is almost irrelevant.
(ii) We don't have an interoperable specification unless
* each and every feature, and every option of every
feature, can be effectively created and exercised
by a totally clueless user sitting behind a
mindless point-and-shoot DWIM UI and that
* each and every intention of the sender with regard
to content, formatting, display options, etc., can
be accurately understood by a receiver (and
processed within a sensible, but narrow,
interpretation of the conformance rules) who is
equally clueless and sitting behind equally pretty
but mindless tools.
If we can agree that both of those positions are silly --and I
think we can-- then the question, at least for applications, is
about where the optimality point is in between them.
Personally, I'd like to see that optimality point include a
requirement for general-purpose MUA UIs that really support the
functionality specified, not just carefully-crafted
single-purpose templates into which things can be stuffed and
handed off for transport. I wouldn't try insist that those
things get down into every logical permutation of possible
functionality -- that gets a little too close to the second
extreme.
And, while I really don't have opinions about the answers --I'm
too confused by the many tradeoffs-- I think there are some
important questions about MIME features lurking here and that we
would serve ourselves and the community better by addressing
them now, rather than later (or, as we did with some questions
about 821 and 822, just ignoring the issues for 8 or 12 years).
The following are just examples:
(1) multipart/alternative: Logically speaking, it shouldn't be
hard to build a fairly simple MUA feature that could send out,
say, two or three forms of a document -- text, some revisable
markup or word processor format, and some print-ready page image
format -- with some defaults for the specific formats that could
be reconfigured by some process that might be
less-than-completely-easy. We haven't seen that happen (at
least where I've been looking). What we have seen instead is the
deployment of one or more (non-MIME) MUAs that rely on the idea
of maintaining a directory of known receipients and then having
the MUA decide which format to send each user based on the
directory information about what capabilities that user has
available. Now I personally think that the latter concept is
somewhere below brain-dead for more reasons than I care to
enumerate. But there are more copies of MUAs that do it that
way out there than there are copies of MIME MUAs who can
permit an equivalently-skilled user to construct the
multipart/alternative strategy instead. So, at best, we lack
good proof of the viability of our approach.
You will note that I haven't asked for anything of the
complexity of the I-D template output, nor to get nested objects
within alternatives, etc. I'm pretty happy to leave those to
specialized tools, since I don't think there is a requirement
that casual users be able to understand the features well enough
to utilize them sensibly.
I do think that, at this point, we need to ask ourselves why
MUAs with that sort of near-minimal capability of creating
multipart/alternative structures haven't been widely implemented
and deployed. Arguably, we ought to be able to _prove_ that the
reason isn't some latent defect in the definition of
multipart/alternative that makes it a lot less useful than we
think it ought to be.
(2) Multipart/alternative, part 2.
If we believe that demonstrating competence in receivers is more
important than demonstrating competence in senders -- that
receivers ought to be able to deal competently with things
for which senders may require specialized tools or user
sophistication, then we ought to be asking how many receiving
MUAs out there are really able to handle fairly complex and
nested multipart/alternative forms, where "handle" should mean
"do the right thing automatically after appropriate
configuration". Let's consider as examples the I-D form (we have
proof there that the form, if it can be processed, is a way to
organize useful information). Let's even go so far as to
consider the nested form in which a second layer of /alternative
structure is used to provide alternate sites from which to pick
up an external body part. Again, I suggest that we need to
examine that issue to determine whether the current definition
of /alternative provides a sufficient information path between
the sender and the recipient that the latter is able to the
right thing without excessive guesswork. I don't know, but the
number of widely-deployed implementations causes me to wonder if
we are sure.
(3) multipart/parallel. I think there is pretty strong evidence
at this point that we don't have enough parameter information to
make this feature useful -- if "useful" implies that the
recipient can figure out what the sender intended and, if it
wants to, to do that. If I'm wrong, and the feature is useful
as defined, why aren't we seeing more implementations of
/parallel rather than, e.g., (and if you are willing to admit
this as an example, which I'm not -- see below) HTML with
embedded image links?
(4) External body parts. One of the greatest hopes for external
body parts was not for delayed file transfers (of the I-D
announcement persuasion) but for referencing other messages that
would provide context so that, e.g., instead of forwarding a
message to you with comments, I could forward a pointer to that
message. Now supporting that --in principle rather simple--
functionality for casual users would require a type of database
and server infrastructure which goes well beyond the MIME
definition and which no one has implemented (and hooked up to
external body parts). So we have no demonstration that external
body parts, as defined, are adequate for that use and, in
particular, we have no worked examples to tell us that our
definition will prove adequate if/when those facilities become
available.
Are we obligated to demonstrate that the structure is right
for that type of application to prove utility and
interoperability of the feature? I think not if the highest use
of external body parts is the way we are using them in I-D
announcements. But I keep seeing MIME-ish mail messages with
embedded references, references that aren't external body parts
at all but simply embedded URLs. And I'm seeing several MUAs
out there that offer a "double click to retrieve on embedded
URL" capability -- MUAs that have not bothered to implement
external body part support. One hypothesis about his is that
the marketplace has demonstrated that external body parts are
either useless (at least OBE) or that they aren't specified in a
way to add value. The first of these possibilities is grounds
for elimination at full standard; the second is (or ought
to be) grounds from some fairly serious review of functionality
and intent at Draft.
(5) And, since I'm kicking the hornet's nest, I'll push a good
strawman out there: There is the whole question of the nested
body part structure. I'll argue strongly that it is a
good idea and important and that there are all sorts of
interesting things that one can't do without it. However,
practically all of the MUAs out there, especially the graphical
interface ones, are dealing with body parts through a
single-level "message and attachments" model. We could save the
community a lot of pain and suffering (especially in gateways to
products that operate in terms of "message and attachments" by
eliminating the nesting if it turned out that it had no value
that anyone wanted to expose to users. IMO, it is better to ask
that question now than later and, again, to examine why we
aren't seeing a lot of MUAs with metaphor switches to multiple,
potentially nested, body parts if that feature is as useful as
we think and MIME is as widely deployed as we think.
Just examples (and the last a not very good one)...
Finally, and almost independent of all of the above, it
seems to me that there is an element of "be careful what you
wish for" in some of these discussions. If we consider that
what HTTP transports is ultimately MIME-like but not necessarily
MIME, then things that get transported over HTTP can't get used
as proof of MIME implementation and deployment. Conversely, if
we claim that HTTP transport of things that look like MIME are
actually MIME implementations, then the recent flap on the
MHTML list about CRLF canonicalizations and their interactions
with MD5, and the web's use of Content-Encoding with rather
different implications from Content-transfer-encoding, rapidly
turn into worked examples of interoperability problems with
MIME. Whichever approach one prefers, it is pretty clear to me
that we can't have it both ways at the same time.
john