Re: OBJECT Bugs or Features
"http-equiv" to me:
> <!--
>
> The headers of your example Email message quite
> clearly claim the message is multipart/alternative and the first
> part (with the "incomplete" OBJECT tag) is text/html. Thus,
> although the body of that MIME component is not a properly
> formed, complete HTML document, the MIME Content-Type: headers
> provide a fairly strong basis for the MUA treating that message
> component as HTML and displaying it accordingly.
>
> -->
>
> and the Outlook Express unique ability to still do the
> impossible unpatched after three years:
<<snip amusing example>>
Sure, and I know "http-equiv" understands the following, but lest
anyone else missed it, I do not condoen the sloppy programming and
design attitude behind projects that produce such results.
To digress slightly from the straight and narrow or the original topic,
the RFCs in general (apologies in advance for the three that the
following does not apply to) and most other "standards" that today's
most widely used programs are designed to implement support for, are
very badly written _if_ the intention is that they should define some
kind of program specification. There are many, many common
shortcomings here, but in general, they pay _far too little_ (usually
scantly more than "no") attention to failure modes and the issue of
what "compliant" implementations should do when faced with non-
compliant input.
Especially in the case of RFC'ed protocols, because of the
aforementioned "be lenient in what you accept" directive (which is
generally _misconceived_ as applying to all RFCs when, in fact, it was
apparently only originally intended for the very lowest-level protocols
while they ironed out the wrinkles, rather than as general advice for
implementing the later, higher-level "application" protocols), the
historical standard has been "accept it and do your best", leasing to
all manner of "compliant but utterly incompatible" shite being foisted
on the world _AND_ boatloads of otherwise really easily avoided dire
security vulnerabilities.
Quality of (Internet) software will only really start to improve if the
designers and implementors start to question the ambiguous twists in
the "standards" _AND_ refuse to implement any support for the "so badly
worded as to be ambiguous or unclear" parts of such "standards". If
the "security initiative" at Microsoft is to achieve anything useful,
that could well be one of the major lessons. And, being the "800lb
Gorilla", MS is rather uniquely placed to actually make a change for
the better _across the whole industry_ if it tackles this (except,
perhaps, in the quagmire of cr*ppily implemented protocols that is SMTP
where several generations of sendmail madness holds a probably
unassailable tyranny of now incorrectibly bad practice -- no worries
though, as the only "solution" to spam (if we ever have such) will see
the now long overdue death of this protocol).
Of course, I'm not holding my breath until any of this actually
happens...
Regards,
Nick FitzGerald