The Standard Argument: Incorporating Internet Standards into the Design Process

Should your company have a Standards Czar? An argument can be made for both Yes and No.

Presumably, you want any software your company writes to be compliant with the “rules” of the Internet. These rules, governed by the IETF and called RFCs (RFC stands for “Request for Comment” even after the standard is finalized), define everything from the definition of HTML to the proper way for e-mail servers to correspond with one another. The motivation for compliance ranges from a belief in the sanctity of standards to the desire, sanctity be damned, to make the technology work.

But even with the best of intentions, intending to be compliant and actually being compliant can be very different things. There is, frankly, a lot of information to know, and few people are expert in any one area to recite an RFC by heart (or to be invited back to parties if they do).

That assumes, too, that an individual or company really does want to follow the standards carefully and explicitly. Some, in the name of innovation (or “embrace and extend”), blithely make their own rules, and they expect others to make do.

Why, yes, I’m talking about Microsoft. Are you surprised?

But before I point to Microsoft Exchange as the villain of this piece (and I assure you that I shall do so), I want to highlight a meta-question with no right or wrong answer: where in the software development process does “standards compliance” fall? Whether it’s Microsoft writing the next version of Exchange, or your own application development department creating a Web app that sends out e-mail notifications to users… whose job is it to stand at the white board, scribbling little RFC notations next to each action item?

I could argue that every company with a software development department should have a Standards Czar, whose job it is to ensure that every bit of code is as compliant as it should be. After all, Microsoft has a vice president of trustworthy computing who can order a product back to the drawing board if he finds a security problem. Is standards compliance no less important?

On the other hand, I could argue that standards, like security, have to be baked in from the start. Sure, you can and should test for standards-compliance during the QA process (though I worry that few companies actually do so). But if a Standards Czar is worrying about compliance after-the-fact, maybe it won’t be top of mind at design time, when you’re developing the software requirements. And some applications, such as e-mail servers, ought to be designed with a copy of the RFC as part of the application model.

I don’t know what the right answer is. I’m sure that you and I could quaff several beers in pursuit of the right answer. (Make mine a good IPA, please.) But I know what it looks like when that question isn’t addressed at all.

This blog post all started with a little “How ’bout that?!” that intrigued me. It blossomed into a long and detailed discussion about the, shall we say, less than admirable features of Microsoft’s Exchange Server, with several kind and knowledgeable e-mail administrators. And that led to the larger philosophical issue that I think bears discussion even if you could care less about e-mail RFCs (hard as that may be for me to imagine) or if your chief concern is the annoyances of Microsoft’s “embrace and extend” policy. (To which I can easily point you to concerns about Microsoft’s IE 8, not that I think you needed directions.)

But it doesn’t mean that I’m any less irritated by the original item.

Back in 2006, a kind end-user offered a solution to a reported bug in Microsoft Exchange, addressing how the mail server did not comply with one of the e-mail RFCs (a rather important one, if you ask techies). Somebody from Microsoft replied, saying, “We are considering adding such support in a future release.” In 2006. That’s two years ago. It’s still not fixed, even though they were handed a workaround.

At that point, I decided that I’d talk with Microsoft about it. But if I was going to contact them about RFC-compliance in Exchange, I might as well talk about how the company dealt with all sorts of Internet compliance issues. We might discuss what one e-mail admin told me: “I’d settle for it not rewriting error messages.”

Need an example? “501 Invalid hostname in HELO” and “421 Hostname in HELO does not resolve”—from the standard—are both rewritten to “550 no such user”, without the original error to give someone a clue. In less technical terms, Exchange replaces the carefully crafted rejection messages (which generally point at URLs identifying the source of the e-mail delivery problem and how to fix it) with bogus information that merely blames someone else. (And you know how I feel about software that assumes that an error is someone else’s fault. “Cranky” doesn’t begin to cover it.)

I’m no e-mail goddess, but I did manage to learn enough to write an introduction to e-mail technology and an intro to e-mail management. I fully expected that when I talked with the right dude or dudette at Microsoft, we’d talk about, say, how the company decides that their error message reporting is more effective. (Presumably they do.) I could imagine a discussion about the imperfection of the RFCs, because those too are constructed by error-prone humans. (As one e-mail admin explained to me, RFC821 doesn’t say what the MTA is supposed to do with 4xx/5xx errors after DATA termination—not in enough detail, anyhow. You can tell that I wouldn’t eject someone from a party because she recited RFCs as though they were poetry.)

Or, more generally, I thought, we might talk about SPF records and the features Exchange uses to fight spam. Or maybe we might discuss why some of the default settings in Exchange are, to be kind, not tuned for the poor schnook who is told he’s the postmaster even though he has no technical knowledge about e-mail.

Irresistable aside: Like Visual Basic, which was dangerous in the hands of novices simply because anything would be dangerous in the hands of novices, Exchange suffers from being a default choice for people who aren’t ready to get educated enough to make an informed one. But because Microsoft knows this (and they surely do), it makes them more responsible for creating useful installation defaults, providing “teach as you go” prompts rather than simple wizards, etc. If you know children will use your product, you should make them child-safe; Microsoft has entirely too many pieces that a baby can swallow. And everyone on the Internet suffers from those errors.

I was looking forward to it, honest.

But I never got to talk with anyone at Microsoft about it because, the well-meaning PR professional told me, “There is no single person responsible for managing all the RFCs so it would vary by group.” Apparently, after a week of asking-around, nobody from Microsoft’s Exchange group was comfortable talking about the company’s standards compliance. Now, doesn’t that make you feel good about using their software?

I could pick on this as a Microsoft issue, and obviously I have. Obviously, it is. But it also raises the philosophical question about where, in the software development and design process, one should expect to find a dog-eared printout of the RFCs, measured against the software project plan. Is it something that’s addressed at design time? when the QA team gears up? left to the individual developer? Would it help to have someone whose job it is to ensure that every bit that interacts with the Internet is following the rules?

So: should Microsoft have a Standards Czar? If they should… shouldn’t your shop, too?