ietf-822
[Top] [All Lists]

Re: MIME implementation documentation

1996-08-16 03:25:51
On Thu, 15 Aug 1996 23:01:25 -0700  Dave Crocker
<dcrocker(_at_)brandenburg(_dot_)com> wrote:
    Yes, we need to audit functions not implemented and remove them
from the spec.  do you have any candidates for removal?

Just a hunch, based on MUAs I've looked at recently, but
   multipart/alternative
and
   multipart/parallel
are good starters.  The only creation-implementations I know of
either require either hand-fussing (e.g., editing
proto-outgoing-messages from /mixed) or specialized assembly
macros that are not what we normally consider MUAs (e.g., the
process used to prepare the I-D announcements).

I'm sorry, but I do not buy the argument that inavailability to casual users of
mail user agents capable of directly building these things is in any way
meaningful. (I'm also pretty sure it isn't the case -- for example, we're now
providing facilities for people to complex objects of this sort in PMDF without
hand editing anything.) The fact remains that there are many agents out there
that build messages of this sort -- there are at least two, for example, that
post multipart/alternative objects to the IETF list on a regular basis. I see
nothing in the Poised requirements that says anything about ease of use, merely
that multiple implementations must exist and must be able to interoperate.

There are countless features and options in IETF standards intended for use
primarily, if not exclusively, in an automated fashion and not directly by
users. I view both multipart/alternative and multipart/parallel as features of
this sort -- they are absolutely not the sort of thing people create casually
-- but instead they are the sorts of things complex applications create
indirectly on behalf of users.

Frankly, I also see this emphasis on MUA implementation of MIME capabilities as
entirely misplaced. MIME exceeded its design goals and became a general data
structuring format before the first set of MIME RFCs were even out. There are
now a vast array of automated applications out there that construct and send
MIME objects (often not via email), receive MIME objects (often not via email),
and manipulate MIME objects in increasinly complex ways. Excluding these
applications from consideration as valid MIME implementations on the sending
side is, in my opinion, highly inappropriate.

However, I have no problem with requiring multiple MUAs that can receive and
process alternative and especially parallel objects, if for no other reason
than it is unclear to me what it means for an automated process to handle
parallel objects "correctly". But we have multiple interoperating
implementations of both of these before the MIME RFCs first came out, so this
at least is a complete non-issue for us at this time.

The problem here, obviously, is that coming up with an
implementation of these things in the sense of some prototype-
or demonstration-quality critter that can demonstrate the
ability to put the right format out on the wire and then read it
from the wire is trivial and uninteresting.  Implementing to a
level of quality needed to show actual utility -- that the
feature has the right syntax and semantics to actually serve
useful purpose as defined -- is, IMO, another matter and I'm not
convinced that we are there yet.

Perhaps we aren't, but it seems to me that you are reading an awful
lot into the proposed-->draft step of the process.

                                Ned