"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
