RE: overdefining text/plain?

1) Outlook working with Exchange Server 5.0 (which converts the MIME
type to proprietary gunk in the MTA), correctly displayed text/paragraph
as text/plain.  Thus, Outlook's error with direct Internet access (for
which it decodes MIME itself) appears to be an inconsistency rather than
a direct design decision by Microsoft to go against the standard.

2) Let's not lose sight of the natural split inherent in text/* vs.
application/*.  The text/directory effort, for instance, was debating
last year the crux of the issue, which is whether uniterpreted
information should be displayed to the user or made available to save
(e.g., octet-stream).  We can argue over any specific subtype, like
text/html, but the dichotomy clearly makes sense and is an integral
feature of MIME.  Conformance to this dichotomy is essential to
continued growth of MIME , as shown in this situation.

3) I would like to heartily second Paul's idea for a MIME conformance
program.  I think the MIME conformance statement in RFC 2049 is an
important direction in Internet standards.  What is now needed is for an
independent and trusted third-party to start conformance testing.

                - dan

P.S.  I am probably missing someting obvious, but I don't see "interpret
unrecognized subtypes of text/ as text/plain" in the 10 conformance
requirements of RFC 2049.  This would seem worthwhile to add as MIME
moves to Standard.  When is that, BTW?



> -----Original Message-----
> From: Ned Freed 
> Sent: Tuesday, March 10, 1998 3:09 PM
> To:   Bill Janssen
> Cc:   ietf-822(_at_)imc(_dot_)org; Chris Newman; Paul Hoffman
> Subject:      Re: overdefining text/plain?
>
> > > The rule which
> > > requires MIME MUAs to treat unrecognized subtypes of text as
> "text/plain"
> > > is documented in both RFC 2046 and RFC 2049.  The fact that three
> MIME
> > > MUAs failed one of the most basic MIME requirements is
> unacceptable.
>
> > Isn't the problem here really that (1) customer demand trumps
> standards,
> > and (2) as Laurence pointed out, some folks are registering (and
> using!)
> > invalid subtypes of "text", like "text/html", "text/sgml", and
> > "text/rtf"?  MUA vendors don't want to put gibberish up on their
> > customer's screens, and there are registered subtypes of "text"
> which
> > look like gibberish to normal users when presented directly, so the
> only
> > sensible MUA rule for commercial vendors is to censor anything they
> > don't know to be correctly presentable.
> Perhaps, but the data from this survey doesn't support this
> conclusion.
> Specifically, we have three MUAs that have problems, but only one of
> them
> (Outlook) is a relatively recent design. At least one of the other two
> (ZMailer) was designed quite some time ago, considerably before such
> problems
> were readily evident. I also suspect that even with Outlook the issue
> is less
> one of "mustn't throw up unintelligible stuff" than it is one of "how
> we map an
> open-ended set of types into our internal typing system that's based
> on file
> extensions".
>
> There is also considerable evidence that when shoe is on the other
> foot, so to
> speak, and it is noncompliance with MIME that leads to bad displays
> full of
> garbage, this fact hasn't stopped MUAs from breaking the rules. For
> example, if
> you look at proper handling of the charset parameter, you'll find that
> many
> agents don't bother to check it even though MIME says you're supposed
> to. And
> similarly, if you look at compliance in the area of message/rfc822
> handling,
> you'll find that a fair number of agents didn't bother to do it until
> we raised
> the bar a bit. And failure to comply here often leads to screens full
> of
> base64.
>
> What I do think we have is evidence of something we've known from the
> start,
> which is "developers often implement things incorrectly and once
> implemented,
> things tend not to get fixed, even when users complain". Scarcely a
> major
> insight, to be sure, but about the only one I think can be had from
> the data.
>
> I also believe that text/html is actually legal and registered. The
> others
> aren't, but they are also fairly rare.
>
> > I remember raising this point during the original MIME discussions
> (when
> > some folks were proposing text/postscript :-).  The fact is, by
> allowing
> > arbitrary registration, we remove the ability to say anything in
> general
> > about the so-called top-level media types, because people are always
> > going to misuse them.  I'd suggest just facing that fact, and
> removing
> > any RFC requirements that are supposed to apply to all instances of
> any
> > top-level type.
> Actually, we do not allow arbitrary registrations and never have. The
> number of
> things that have been registered until text/ is actually quite small.
> And while
> you may argue that text/html was a mistake, it isn't like it wasn't
> discussed
> at considerable length. We have only ourselves to blame if it is a
> botch.
>
>                               Ned