| Date: | December 21, 2004 / year-entry #430 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041221-00/?p=36933 |
| Comments: | 50 |
| Summary: | Your average computer user wouldn't recognize a standards document if they were hit in the face with it. I'm reminded of a beta bug report back in 1996 regarding how Outlook Express (then called "Microsoft Internet Mail and News") handled percent signs in email addresses (I think). The way Outlook Express did it was standards-conformant,... |
Your average computer user wouldn't recognize a standards document if they were hit in the face with it. I'm reminded of a beta bug report back in 1996 regarding how Outlook Express (then called "Microsoft Internet Mail and News") handled percent signs in email addresses (I think). The way Outlook Express did it was standards-conformant, and I sent the relevant portion of the RFC to the person who reported the bug. Here's what I got back:
That first sentence pretty much captures the reaction most of the world has to standards documents: They are meaningless. If Outlook Express doesn't behave the same way as Netscape, then it's a bug in Outlook Express, regardless of what the standards documents say. There are many "strangenesses" in the way Internet Explorer handles certain aspects of HTML when you don't run it in strict mode. For example, did you notice that the font you set via CSS for your BODY tag doesn't apply to tables? Or that invoking the submit method on a form does not fire the onsubmit event? That's because Netscape didn't do it either, and Internet Explorer had to be bug-for-bug compatible with Netscape because web sites relied on this behavior. The last paragraph in the response is particularly amusing. The person is using the word "RFC" as a magic word, not knowing what it means. Apparently if you want to say that something doesn't work as you expect, you say that it doesn't conform to the RFC. Whether your expectation agrees with the RFC is irrelevant. (By his own admission, the person who filed the bug didn't even read the RFC.) |
Comments (50)
Comments are closed. |
If there was ever an argument that people like documentation but never read it, look no further than your friendly neighborhood RFC. I find it amusing that the person hasn’t read the RFC but implicitly states he is an expert on said RFC! Further more, there is no reference to the specific section of the RFC the bug is supposedly violating. I think this post can be summarized by saying "Perception is reality."
I think it is more important that this user pointed out a flaw in the RFC they didnt read. It seems that the RFC should be revised so that % were handled gracefully and in a manner which provided the best user experience. This seems to be what Netscape had done.
Back in 1996 Netscape had a much larger market share and IE was looked upon as the bad guy. Still today Firefox et. al. are setting the standards. So yeah if a feature (bug or not) works in the more popular or sometimes the "not Microsoft" product, then Microsoft will have to match due to user demand.
Microsoft does a great job at this and I think that is one of the reasons they are so successful. If it works and users love it- make it happen. I cant wait for the next version of IE which I am sure will incorporate all of the FF et al features.
Great blog.
These people are the slaves of appearance…
If, for compatibility purposes, people continually program bugs into "better" or "newer" software in order to maintain a bug in a competitor, how does software evolve? IE is currently evolving to some extent because its competitors chose not to implement all the buggy features of IE.
By the way, RFCs are not standards; they are merely requests for comments. If they are in the standards track, that is when they are standards. HTTP 1.1 is not a standard, for example. It is a draft standard.
It would be really nice if Internet Explorer had a "pedantic" option that stopped it from attempting to render anything but 100% perfect HTML / XML / CSS and displayed an error message instead. This would be really handy for web development in the same way a standards compliant compiler forces users to write syntactically correct code. Obviously it wouldn’t be that much fun for day to day use but it help spot errors a lot more quickly when you are trying to develop correct web pages.
Speaking of having to be compatible with buggy software, at a company I used to work for, when you installed our app (which also installed the DCOM redist) on Win 95, we had some weird problem that only arose if you also had the AOL software on the box.
We worked out that AOL was doing something totally wrong with their DCOM stuff (I wasn’t on the group that researched it, so I don’t know the details). But by sheer luck, no other DCOM-using software seemed to mind except ours. But since sizeof(AOL) was much much larger than sizeof(us), we had to work around them.
This is called "standart defakto".
If some popular software do something which is not part of standart (it could be bug OR extension) then all should respect this. It’s pity but the live is so :)
Now lot’s of FRE for Mozilla are – "please make it do …. same way as IE" ;)
Do you counsider extending of standart is as bad as bugs in implementation of standart? ;) ("document.all" e.g)
Funny you should write this article. Just last week I coded a TFTP server after reading the RFCs (yes, I DO read RFCs). To test it I replaced the TFTP server that comes with Microsoft RIS with my own. After first it didn’t work, so I downloaded several other freeware TFTP servers and tried them, nothing worked with Microsoft. My first thought was Microsoft is going against the standard for some reason. But after using a packet sniffer and closely rereading the RFC, I found my bug. All along Microsoft was perfectly following the standard, and these other TFTP servers, some of which are demo versions of retail software, were not correctly following the standards.
Hey! There is "URL" field!!! But why it auto-appends "http://" and "/" to my "mailto:name@host" url??? This is not standart-complained!!! ;)))))
You should write "website" there instead ;)
Or "comply with RFC" :-p
;)
Someone e-mail the RFC for English to our friend Nekto2 here. Mark the sections on why excessive use of smileys and question marks is best avoided.
I think the bug poster may have meant:
"MS Internet Mail and News DO NOT HANDLE PERCENT SIGNS, like the RFC says."
If only we could get people to use commas :)
Some things never change…
Back when I was writing compilers (in a pervious life) at a mainframe computer company, I had to implement compiler "extensions" that actually went against the ANSI standard.
People who had code written code to certain other company’s non-standard compliant compilers (and were moving to our computers) expected to get the same results with our compiler, regardless if it followed the ANSI standard or not.
These programs were known as "dusty decks" (referring to the original punch card decks they were first written on), and nobody at these companies wanted to go back and correct their code. Instead, they wanted us to "fix" our compiler.
It’s interesting in that this is the kind of the thing that Raymond talks about all the time with Windows… that Windows XP must emulate certain "buggy" or undocumented behaviors of earlier versions of Windows because certain programs took advantage of them, and it’s unlikely that a vendor is going to change their 10-year-old program.
This is classic. The only thing I can add is that this behavior is not limited to the computer field. I’ve seen the same thing in engineering. One company makes a popular gizmo that isn’t covered by an ANSI/ASME standard and others are forced to deviate from the standard to work with this gizmo.
I think the key idea here is that if the program the user does not use does not work in the same way as the program they like to use, the new program is "broken". It doesn’t matter if it’s made by MS or OSS or IBM. You’ll find users who will say that Firefox is "broken" because it doesn’t render sites the same way that IE does or that Thunderbird doesn’t display email the same way that OE does so Thunderbird is broken.
RFCs? Those are like manuals, right?
Same thing in building, architect sends out the blueprints and then the contractor says, "Blueprints, what blueprints?"
At least the typical RFC reads better than an EULA.
"It would be really nice if Internet Explorer had a "pedantic" option."
I alluded to this in my article when I wrote, "when you don’t run it in strict mode". More explicitly:
http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp
I agree, it would be nice to be able to switch between strict and loose modes — strict for those of us who like that, loose by default.
I disagree that we should ignore RFCs just because the average user does not like the way things work. If they find ‘%’ "does not work" in Outlook, then a bunch of advertising should be done to indicate how cool Outlook is because it’s doing the Right Thing.
If I went up to a structural engineer and said "No, don’t use that metal; use this red one instead. I saw a building with it and it looked cool!", the engineer would laugh in my face.
Why should we be any different?
Because we are not structural engineer. Software as an engineering disciple is a strong metaphore, but here it breaks.
And then what if you add, "Well then fine, I’ll fire you and hire XYZ Engineering Company because they’ll let me use red metal." Would the engineer change his mind?
I suspect that an ad campaign that says "Outlook can’t send mail to your grandkids and that’s a feature" is unlikely to be successful.
Thanks Raymond, I didn’t know about that strict option (I’m not a web dev, but I do bits of it sometimes). Very cool.
IIRC, the full Outlook interprets the semicolon as a comma in the To field even though the semicolon has a different meaning in the RFC 822.
Based on <a href="http://www.google.com/search?q=outlook+semicolon+comma+rfc+822">a brief googling</a>, the only legal use for a semicolon is to terminate a group of addresses of the following form:
"label: a@b.c, b@c.d;"
Hmmph.
You’re confusing the UI with the SMTP header. As far as I am aware, Outlook generates RFC-compliant SMTP headers.
After all, you can type Chinese characters into the "Subject" edit box even though that is not permitted according to the RFC. Outlook converts it to MIME for you. Is it a violation of the standard, then, that Outlook lets you type Chinese characters? (Should it require you to enter the "=?Big5?B?" subject line instead?)
I suppose subsequent emails from that fella were auto-routed to the Trash folder.
"Well then fine, I’ll fire you and hire XYZ Engineering Company because they’ll let me use red metal."
Then fine, let XYZ be hit with the lawsuits, or shunned.
I agree: in practice it will not work for software developers. But that’s only because 98% of the developers out there are willing to stab you in the back and not stick to standards. It would take a concerted effort by a large number of developers to force the situation.
If you’ve done cross-browser web development you probably know what a pain it is — either you spend most of your time remembering esoteric details or you spend it developing or refining large cross-browser facades. It’s a perfect example of "standards? what, me worry?".
I think that part of the problem is that RFC’s are sometimes vague. So, what they say is open to interpretation.
It would simplify implementers lives a lot, if RFC’s used more formal specification languages, instead of plain old english. For eg, if the protocol contains state machine, it would aid implementation and understanding if the state machine was specified exactly (either as a state-machine diagram, state-table etc) rather than a set of prose with MUST,MAY and MUST_NOT constructs.
A lot of people use the word "RFC" to mean "what we do", or possibly to foist responsibility on someone else.
We had a problem with an email server rejecting our messages because of the way we formed the sender address. I looked up the RFC, and it specifically said that our format was valid, but when I spoke to the admin of the mail server, the first words out of his mouth were "Oh, we’re just following the RFCs – you are sending invalid email".
Of course, as soon as I mentioned I was looking right at the RFC in question and it supported our format, he backpedalled and found a new excuse… anything to avoid having to make a change at his end.
Jonathan: Under limited circumstances you can get some of what you’re asking for with other browsers, including Mozilla. If you write XHTML *and* serve it as application/xhtml+xml, XHTML-aware browsers will stop processing if they encounter an error in the document. I haven’t yet seen a browser that will do that for CSS or HTML though. Of course, non-XHTML browsers such as IE will simply refuse to process the document if you do that.
I find it much more practical to just run all of my pages through the W3C HTML and CSS validators when I think I’m done.
Thiery:
Because we are not structural engineer. Software as an engineering disciple is a strong metaphore, but here it breaks.
IMO, it’s not a metaphore at all. And it doesn’t even break in this scenario. It just so happens that the application is not mission critical (doesn’t threaten anyone’s life). The situation is however that of a home owner who insists to the contracter building his house that the hot water faucet should be on the right because he saw a friend of his who has a house where hot water faucets are on the right. Now doesn’t that sound much more similar?
To illustrate the other edge of the spectrum, people would hold the programmer or company (such as Microsoft) squarely responsible if a system containing health or financial information was breached due to improper coding.
Just a quick note about RFCs which most people tend to forget. RFCs are Request For Comments. When they’re standards, they become Standards, or STDs. Of course this doesn’t stop us all assuming RFCs are standards when no standard exists, but to say RFCs are the letter of the law is misnomer.
My only comment is:
Too bad we couldn’t have put a menu item in IE that says "Netscape Buggy Mode" and have it checked by default. And unchecking it would make it standards compliant.
Too many reasons why not. Still…*dreamy sigh*.
Two things.
—-
I. RFC 2812 is one of five RFCs (1459, 2810, 2811, 2812, 2813) describing the operation of IRC. Among things it defines are "server numerics", which describe the replies to common requests, such as /whois and /list. One such server numeric as 005, RPL_BOUNCE, which according to the RFC is used to make the client disconnect from the current server and instead connect to a different one.
That’s not what it does.
If you connect to any modern server, you will find that 005 is used instead for RPL_ISUPPORT, which describes succinctly the options that the server supports. No IRC clients use 005 as RPL_BOUNCE.
—–
II. CSS has some really, really bizarre parsing things – to the extent that even the demonstration file they offer to test whether your CSS parser does it right… does not follow the standard. Or was, last time I had to do that sort of madness.
Vorn
Percent signs were used as a hack to work around some problems with network topologies and mail servers before Mosaic existed, let alone before Netscape existed. Netscape provided backwards compatibility with a hack that had already become obsolete. Outlook Express … um, wait a minute, one time Microsoft prioritized standards conformance over backwards compatibility, and Mr. Chen didn’t scream bloody murder?
I once hacked a server to put two at signs in a From field because I didn’t have time to hack it to put in a percent sign and later an at sign. This was never intended to be either a standard or a common hack, it was just a quick and dirty simple hack so that recipients could still work out how to contact the sender if they wished[*]. A few years after forgetting all about that, I saw someone assert that two at signs were supposed to be acceptable. Gads.
[* Once upon a time real e-mail outnumbered spams and the posters of news articles didn’t mind receiving real replies to them. Yeah I know, that’s unimaginable today.]
RFCs are good when you write the initial protocol, or when it’s created by a joint group.
RFCs are bad if a single company writes one to update an existing protocol to their proprietary version.
RFCs 2810-2813 are a case in point. They were written to detail the features of ircd2.10. The problem is, ircd2.10 is used by exactly one IRC Network: IRCNet, which split off from EFNet in 1996. IRCNet is currently the last member of the Big Four IRC Networks, taking Dalnet’s place after the DDoSes in past years. However, in the year those RFCs were written, it wasn’t. EFNet, Undernet, and Dalnet were the big 3.
When irc2.10 was created, the big three networks were already using different ircds. Efnet was using hybrid (based on ircd2.8), Undernet was using ircu (based on ircd2.7), and Dalnet was using dreamforge (based on ircd2.8). Undernet and Dalnet had already implemented 005 as RPL_PROTOCTL way back in 1997… dalnet’s dreamforge changelog shows records of it in August 1997. This was later renamed to RPL_ISUPPORT.
Incidently, later versions of ircd2.10 moved RPL_BOUNCE to numeric 010 to correspond with other networks RPL_REDIR numeric.
WS: Then I would suggest you to read some netiquet guides. That is why smiles exist in first place and why they are specially applicable to Inet talk. /fun/
Actually that is another standart. For me is Inet-style, for you – pure English. So "Be strict in what you generate and forgiving in what you accept".
Raymond Chen: There is an icon in IE which shows up when you have errors in JScript. Why not to make same icons for errors in CSS/HTML? It will not break anything, but will allow webmasters to see something is wrong. Same – to indicate if rendering in strict mode or not.
(gone to submit same rfe for mozilla ;)
Mozilla 1.8a5 now lists CSS errors of all kinds in the JS console, so half of that RFE already exists.
Standards mode in IE6 is nice (and long overdue), but I agree, there should be (in IE and Moz both) a mode that is set by the client, not the developer, where errors or just bad practice (such as not closing tags, even though some of them allow it) in the HTML or the CSS are pointed out. A built-in linter.
Nekto2: Sorry, my parser can’t read your message. Could you convert it to ISO English and repost? ;)
Seriously though, sloppy writing does not equate "Inet[sic] style" writing. It’s just an excuse for poor English skills and/or laziness.
Quoting my favourite netiquette guide:
"We’ve found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking […] Spend the extra effort to polish your language. […] Spell, punctuate, and capitalize correctly."
MS Internet Mail and News DO NOT HANDLE PERCENT SIGNS like the RFC says.
–>
MS Internet Mail and News DO NOT HANDLE PERCENT SIGNS, like the RFC says.
Interpreting some English flavours can be a challenge.:) User seemed just to be saying that it worked as the RFC says and doesn’t handle percent signs as expected. That is, that the RFC didn’t reflect reality in service.
"We’ve found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking"
I don’t agree with this – I would suggest the reason for sloppy writing (from personal experience :)) is due to respect – i.e: lack of it – to the discussion group.
This doesn’t indicate the poster is stupid or careless in other aspects but that they merely don’t give the group enough respect to construct proper sentences. This is appropriate in some circumstances.
Also – someone previously mentioned RFC’s are vauge – I couldn’t disagree more.
I implemented the "lanman http handshake" (I forget it’s formal name…) RFC sometime ago (for various reasons) and all I needed was the RFC – no interpretation required on my part.
michaels,
–>
This doesn’t indicate the poster is stupid or careless in other aspects but that they merely don’t give the group enough respect to construct proper sentences. This is appropriate in some circumstances.
–>
dAMN sTRAihgt!! :p
WS: Please replace a parser and press any key to continue! :)
So you are right – I have poor English skills. It is not my first language and I have not trained it enough. :(
Still you argument on spell is not good either.
That is common knowledge that "if you have no argument left then you begin to comment on opponents self and his spell skills". :)
And genius thinkers are not very pedantic to check for pureness of some standart (language etc). So that thing is not right.
michaels: I would comment regarding "respect". It is normal to answer messages you are interested in. If you are not (or think it is not written with full respect to you) then just skip it. Me and you will be both pleased. Same way HTML parsers will skip unknown or misspelled tags. ;)
"Respect to all" is too generous term. You have information to tell only your own opinion. And owner have ability to delete this :) Please, do not artificially increase you opinion by pointing to "all". ;)
//processed with ispell. Sorry for father mistakes.
nekto2: I think you misunderstood me, I wasn’t saying you were being disrespectful, no-one can critise a non-english speaker for constructing imperfect sentences – i was merely saying that the fact that someone doesn’t spell correctly doesn’t indicate their intelligence :)
Dorks. :p
>>
Also – someone previously mentioned RFC’s are vauge – I couldn’t disagree more.
I implemented the "lanman http handshake" (I forget it’s formal name…) RFC sometime ago (for various reasons) and all I needed was the RFC – no interpretation required on my part.
<<
The problem is that there’s no central editing committee for RFCs, in particular, there’s no requirement that someone has to implement an RFC based on the RFC alone. Which leads to uneven quality across the spectrum, from the rock-solid (kerberos v5, http) to the high-level, vendor-secific, incomplete, and vague, particularly when they involve complex algorithms.
You also have some RFCs that are long outdated but were replaced by non-RFC documents, like HTML.
It’s a good resource, but definitely has to be tempered with testing and outside research.
michaels: ok :)
Norman Diamond: that was my mistake. I have corrected ispell.
foxyshadis: but one would expect from software to specify if it "RFC xxxx compatible" or not.
Raymond> You’re confusing the UI with the SMTP header
You’re right. However there are also "standards" for how programs like OE "should" behave. http://www.google.co.uk/search?hl=en&q=GNKSA&meta= (I’ve no idea whether it applies to this case, I am merely writing to inform)
In 2001 I did a SGML validity test on 2.5 million webpages from the Open directory and the result were rather appaling; Only 0,7% of all webpages were valid.
It is very interesting to see how the drive for compability and edge over other browsers have caused this problem.
See http://elsewhat.com/thesis/pages/?nr=81 for statistics on the different errors (I am currently converting the thesis to a wiki text at http://wiki.elsewhat.com/How_to_cope_with_invalid_html)
i would love to have a version of Windows the way the developers want it. No hacks, no compatibility fixes, no legacy API’s, no depricated API’s.
i don’t think i would be able to run anything on it, including Explorer or ie. But it would be nice to have a version of Windows to develop to. If my app crashes, it’s because i’m doing something wrong.
Plus i wonder how much smaller and faster it would be. Or maybe i just want to run XP Embedded (ala Barts PE).
Even if you had such a version your app could still get away with doing things wrong. For example, if you accessed memory after freeing it, you probably would get away with it most of the time.
As I noted earlier, you can use the application verifier to run under a stricter set of conditions.