ICANN has been releasing new top level domain names for the last five years. So why are they treated with such distrust from web and mail apps alike?
Case in point, last summer, several registrants of .coop domains got in touch saying that all of a sudden their emails were being rejected as spam. It turns out that the latest update for their spam filter included a rule stating that all email addresses ending in .coop were invalid and should therefore be classed as spam and not released to the net. Initial attempts to phone the makers of said spam filter were met by staff on their not-so-helpful-desk who confirmed that said rule was correct. Being the technical manager for the .coop TLD registry, that was a tad irksome, and the next update for that filter removed the rule with apologies from the vendor.
The thing is though, why did this happen at all? Surely internet application developers pay attention to this kind of thing? It’s not like there are so many new TLDs released that they can’t keep up or at the very least train their helpdesk staff appropriately so mistakes like this aren’t made to begin with?
Is it a case of fear, uncertainty or doubt for anything newer than .com or.co.uk? Or just ill education? Take another example: the Co-operative bank in the UK still uses www.co-operativebank.co.uk as their main web address, which is fine. They also own www.co-operativebank.coop as well, but it’s a dead end; it doesn’t even redirect to the .co.uk site. Why? FUD? Judging by the fact it tells you that a .coop email address is invalid while you try and create an online account with them, maybe its doubt.
I’m ranting too much here, but my point remains. If you are writing applications that might be affected by the creation of new TLDs, try and add some flexibility into them. To take a case mentioned earlier, owners of .info, .aero, .name, .coop, .jobs, .museum, and .travel domains for instance would be greatly obliged if your email filter didn’t dismiss those email addresses ending in a sequence of more than three letters by default. Likewise, all web administrators should know how to add a header for an alternate domain name to a site that already exists.
It seems ironic that in an environment that publicly continues to evolve, some are unwilling, uncertain or simply don’t know what to do when one of the foundations of that environment offers new opportunities. Too busy looking forward to see behind? I sense a job switch to 3+ letter TLD publicity guru ahead.

[Update] For those interested, it’s worth noting that while ICANN said it was not their problem to begin with, they moved last year to address the problem.  There is a particular area (http://www.icann.org/topics/TLD-acceptance/) linked off their home page that addresses this issue and provides technical references as well as a list of all accepted TLDs for programmers to use in email verification.

Tim O’Reilly states that the C# book market is up 78%, ASP.NET up 61% and Javascript 171% thanks to AJAX. SQL Server books have also boosted sales recently thanks to the release of Yukon. While this is undeniably good and indicates that development budgets are stretching a bit further these days, I wonder exactly how sales still compare to the heyday of mid 2000. For those unaware of it, this is when the dotCom bubble burst, book sales halved in three months and companies like Apress and Wrox were forced to either shelter under the cover of a new owner or go bust. It does feel like there is a new optimism to it all at the moment.
What has been lacking recently is a way into tech book writing for those who are interested. Subject areas have been fixed for a while and there are only so many different ways to get started. However, the new influx of nascent technology - notably from Microsoft - and the introduction of CTP schemes does mean that there is a lot of scope for new authors to flex their literary muscles. There are also a lot of tech community sites like Code Project and Developer Fusion that welcome articles from first time authors who’d prefer to try something smaller to begin with.
In looking back at my experiences though, a few words of warning to those entering the dark waters of book writing.

• Know your subject. It sounds obvious but writing a book is hard enough without you having to learn everything as you go along.
• Know your audience. No-one knows as much about the subject you will write about as you. They will know more or know less. Define the level of knowledge for your target audience and stick to it. Don’t skip coverage on one subject because you think it’s too trivial or because you don’t like it. This is a book - not an option piece.
• Know what your editor will and won’t do for you. Time was that editors had the time to fix consistency of style across chapters, rewrite sections in better (American) English, test, debug and fix sample code and generally make authors seem even better than they were. This is not so much the case these days and it’s important to know what they will do for the book.
• Know the format style. Writing MSDN documentation is infinitely different to writing a book which is inifitely different to writing a script. Research the format you want to write. Figure out why you like it and what you want to do with it. Let your editors know and put it in your initial proposal so they know what you want to achieve.
• Know your language. Developers like things described unambiguously. It means that they can understand a concept, use it and move on. Putting a vague indecisive spin on things isn’t so great. It implies you don’t get something and that the developer will need to spend a couple of hours experimenting with code to determine a fact that they just bought your book to tell them.
• Write. Edit. Leave. Reread. Edit. The first draft of a chapter will make complete sense to you but not to others.
• It will take you longer than you think. Trust me - it will. And writer’s block is a pandemic. Everyone gets it for a bit. Don’t worry unduly.
• Thank your family in the credits for putting up with you being a hermit as you finish the book. This helps a lot. Or go one better, as Chris Sells did recently.

Book writing is a bit like cramming for an exam in some ways. The best way to produce cogent text is to be on top of the subject you’re covering and let it flow - in a structured way. Braindumping everything you know on a subject into a splurge and calling it a chapter isn’t as good. That’s what blogging is for.