After an exhausting week's reading, I found that I had reached half-way through the book, but only a week of action had taken place. Actually, that's not quite true, as there's plenty of words spent on background information, including one particularly awkward flashback to fill in the back-story of a newly introduced character. Not that the passage itself isn't enjoyable, but since we don't meet the character in the present tense until we know her entire history, it feels a bit like Stephenson is saying "oh, sorry, there's something I meant to mention earlier; don't worry, I'll get back to the action in a minute, you'll see".

And in a sense, that is this book's main flaw: there are simply too many stories and ideas crammed together, which might have been better left to stand on their own merits. The online world of T'Rain, for instance, is a brilliant piece of SF invention, and the politics surrounding it would have made an intriguing novel – but this is not that novel, so Stephenson hurriedly tidies the sub-plot away to make room for the real action.

And what action! I've never read a book involving so many guns (or at least, so many guns given such prominent and specific descriptions &emdash; Stephenson jokingly acknowledges one Deric Ruhl as "ballistics copy editor"), but nor have I read another book which concludes with a chase involving a woman being chased by a bunch of jihadists, being chased by an IT entrepreneur and a Chinese peasant, being chased by the rearguard of the jihadists, being chased by a secret service agent, being chased by a mountain lion. The action scenes, and the tangled webs which bring together its motley cast, are the real focus of this book, and they work brilliantly.

Apart from the sheer quantity of prose, there are other signs that this book is not as carefully edited as it could be. I read recently that Jasper Fforde uses the scrollbar and find facility on his word processor to check that he hasn't left key concepts or characters unmentioned for too long; had Stephenson used the same technique, I wouldn't have been nearly as lost when he suddenly reintroduced the nickname "Dodge" after consistently referring to the character as Richard for about 800 pages. A similar slip has a character recognised as "Olivia" after making great play, some 200 pages earlier, of her refusal to give out that name.

My final criticism would be that having introduced a deliberately diverse range of characters, thrown together by fate in the strangest combinations, Stephenson insists on arranging them neatly into romantic pairs. A bit of sexual tension, and some romantic motivation, help drive the story along, and maybe I'm just being cynical, but having nearly every character end up with a love interest seemed more unbelievable &emdash; and unnecesary &emdash; than all the other coincidences in the novel.

But these are minor niggles, and are almost forcibly overwhelmed by the twisting drama. If you start the book expecting a novel about near-future cyberspace politics, you'll enjoy the first couple of hundred pages, then find yourself lost; if you expect an action-packed thriller, it will be the other way around. Maybe, if you're a die-hard thriller reader, you'll find it fails to live up to that genre. But maybe, like me, you'll find it an immensely enjoyable romp, but reach the end feeling that the parts of the mixture are not quite blended.

In theory, this makes perfect sense, but in practice, it causes web developers like me a lot of pain, because nothing "permanent" is actually that permanent. I'm not saying no browser should ever cache a redirect, but I do have a few suggestions of ways they could be a little more helpful about it.

The Technology

Let's be clear what we're talking about - the HTTP/1.1 specification defines a class of status codes grouped as "Redirection" statuses, in the range 3xx. The main candidate for browser caching is status code 301, which the specification labels "Moved Permanently". The specification specifically states that "this response is cacheable unless indicated otherwise" - that is, unless the response also includes headers specifically relating to cache control, a User Agent can assume that it's OK to cache this response and not re-request the original URL. It doesn't go into any more detail, and neither this nor the next sentence (about "clients with link editing capabilities") is couched in the standard RFC form of "User Agents MAY ..." (let alone "SHOULD"), but the clear message is "this old URI is irrelevant, just use the new one".

So, newer versions of Firefox, Chrome, and Internet Explorer have all started "obeying" this part of the standard, and opting to cache all HTTP 301 responses if not told otherwise.

The Problem

So, what's the big problem? Well, the fact that a "resource has been assigned a new permanent URI" doesn't mean that there won't be some point in time where someone wants to use the old URI for something else. Worse, people have an unhelpful habit of changing their decisions later.

Consider this scenario:

1. A  company has a product called a "Thingummy™", with a description at http://example.com/thingummy/
2. They decide that the name is too unwieldy, so re-brand it as "Widget™". Knowing that cool URIs don't change, the developers permanently redirect the old URL to the new page about the same product, at http://example.com/widget/ Old links remain valid, and direct customers to the information they were looking for.
3. A couple of years down the line, the company decides to boost sales by releasing a "classic" version of the Widget™ under the old Thingummy™ brand. They put up a new page at http://example.com/thingummy/ Sadly, some customers continue being redirected to http://example.com/widget/ by their browsers' cache.
4. With Thingummies™ massively out-selling Widgets™, the company comes full circle, and abandons the new brand. The developers put in a redirect that permanently points http://example.com/widget/ back to http://example.com/thingummy/. At this point, all hell breaks loose. Well, maybe not, but customers trying to access the product page find mysterious messages on their screen about "infinite redirects". Management are not impressed.

Escaping the Trap

The first hurdle for developers is that it's not obvious what the hell is going on, even when they're just testing out a few different URL schemes in their development copy. I think whatever unacceptable language this developer used on MozillaZine probably sums up the feeling most of us had when first encountering this invisible magic.

But even once you've figured it out, it's not that obvious what to do about it - do you do a deep clean of the browser's cache every time something's not quite right? I see a sledgehammer approaching a nut. And if you've released your mistake to a non-technical user, perhaps on a preview version of the site, you're going to have to talk them through this process as well.

Caching is a pain sometimes, but it's been around for a long time, and we have UIs for dealing with it. The most common of these is the "hard refresh" - hold down Ctrl, or Shift, and hit the reload button or keyboard shortcut, and the cache is by-passed completely and content is reloaded. Brilliant. Oh, but it only reloads the page you're looking at, not the URI you originally requested, so it's useless for cached redirects.

→ Suggestion 3: Make a "hard refresh" request the original URI navigated to, not the one currently being viewed.

→ Filed as Mozilla Bugzilla RFE 696650

Doing the Right Thing

Apparently, what we're all doing wrong, as developers, is not sending appropriate cache headers along with the 301 status code. If you're writing, say, a PHP script, and using header('Location: foo'), you should probably be doing it in some kind of wrapper function, so you can make up your own default expiry, and make sure you send a whole bunch of control headers whenever you redirect.

But a lot of redirects are not written in a rich server-side scripting language, they use specific tools built into the web server, like Apache's incredibly powerful mod_rewrite. I just checked, and there is no function in the latest version of mod_rewrite that lets you control caching, or send arbitrary HTTP headers, when it generates a 301 response. I'm sure there are ways of stringing together a whole bunch of Apache directives to achieve the desired effect, but it would take me a while to come up with the right combination, and it would look a mess.

→ Suggestion 4: Web server redirect functions, such as mod_rewrite, should build in control over caching headers.

→ Posted to Apache HTTPD dev list

Inconsistent Behaviour

Finally, let's assume we're using a tool for our redirects that lets us control the cache headers, and we don't have any old immortal redirects to avoid infinite loops with. All is fine, and the browsers will do the right thing and save us some network traffic, right?

Well, according to this test result table from someone who is in favour of redirect caching, probably not. Like everything out there in web land, you have to deal with every browser handling things just a little bit differently. Combinations which should work might or might not actually be reliable across browsers.

Even client-side caching of standard resources is, as one comment I just came upon puts it "a bit of a black art"

→ Suggestion 5: Somebody needs to work out what the most common scenarios for redirect caching actually are, and how to achieve them.

Conclusion

My gut instinct the first, second, and twelfth times I ran up against redirect caching was that it was stupid, and the browser developers should take it out immediately. But I do see that it makes sense, and could save a lot of unnecessary network traffic and server load. So instead, all I ask is that people don't brush the problems off with "oh, well, you should have known what permanent means", and look at how to make redirect caching work in the real world.

When I was little, I used to like choosing things like digital watches, or my parents' new fridge or washing machine. I would go round all the shops, making notes on the candidates to be bought - I found some of them when I was clearing out a cupboard recently. I think it was my attempt to introduce a kind of scientific order into the chaos that is modern shopping - I guess you could call it the "Money Supermarket" method.

My least favourite kind of shopping is shoe shopping, closely followed by clothes shopping, both of which utterly defy this "scientific" analysis - other than price, there aren't any variables you can line up in a comparison grid. A pair of shoes either fits or not, as does a pair of trousers (judging by the stock in the shops, I must be the skinniest man in Eastbourne...); the rest is down to personal opinion - the problem being that my opinion when looking at a t-shirt in a shop is generally "oh, look, it's a t-shirt", which doesn't get me very far.

I have managed by a series of flukes never to buy a mobile phone, and consequently baffle my friends by always having out-dated and under-powered phones; and what kind of a geek uses his netbook as his only PC for 7 months simply because he hasn't got round to buying or building a replacement desktop? For one thing, there are simply too many variables to analyse, and I don't have the enthusiasm I had when I was 13 to sit there tabulating them all. But on top of that, the sheer quantity of hype and advertising around mobile phones makes me want to run away - the very idea of walking into Phones4U gives me the shudders, such is the unintended effect of their relentless marketing.

I have a general theory that everything in life is ultimately about compromise (well, probably not quite everything; I'm willing to compromise on that point...), and modern shopping is no exception. Generally, unless you are the richest person in the world, you will not be able to order something tailor-made to your exact requirements; but (in the Western / Developed World at least) you'll probably have a fair few options to choose from. But that means there's going to be pros and cons to weigh up, and ultimately you have to decide which compromise you like best or hate least.

Trying to turn all that hype, and all those compromises into a quantifiable, logical system - which is, most of the time, how my mind works - is tiring, and ultimately futile: eventually, you just have to plump for something, and live with it. Which is why I still haven't bought a smartphone.

And yet, some people seem to do their utmost to make all the hyperlinks in their documents entirely useless. Here are my Top 10 Things Not To Do with Links...

Cleggocracy

Firstly, let's summarise this cartoon: "Cleggocracy" is depicted as a Frankenstein's monster, with Cameron, Milliband, and someone I don't recognise in the pocket of a giant Nick Clegg. The message is that if we say Yes to AV, you'll get messy, unpopular, Lib Dem coalition governments; if we say No, our proud democratic traditions will survive, and next time we'll be sensible and vote the Tories in properly. At least, I think that's what it's trying to say...

Student Fee Rises are Clegg's Fault

This is what first caught my eye: among the discarded sheets of paper (why are they discarded and torn anyway?) representing the policies the "Cleggocracy" of AV will bring in is "More Student Fees Rises". So, according to this cartoon a strong Tory government would not have raised fees - that's Clegg's fault for forcing a coalition on them, and something we can expect more of under AV. Correct me if I'm wrong, but isn't that exactly the opposite of true?

Parliamentary Democracy requires a Strong Government

The next thing I found myself questioning was the gravestone, which is labelled "Parliamentary Democracy R.I.P. 2011". Now, the rest of the cartoon appears to be arguing that what this country needs is a strong, Tory, government, and none of this namby-pamby coalition guff. So why is Parliamentary Democracy, which surely implies consensus and compromise, being mourned? Presumably, this has slipped in from a different cartoon, about the perils of electing a government by Proportional Representation - a very different question, and not one being asked by this referendum.

Ramsay Who?

The piece of paper that makes least sense to me is the one on the far right, which is headed "Ramsay MacDonald Supported AV, 1931 - THAT SAYS IT ALL!" Does it? Personally, I know nothing about Ramsay MacDonald, or the politics of 1931 - like most voters, I wasn't born at the time - and I'm not sure I need or want to.

Of course, the cheap tit for tat response would be "Nick Griffin Opposes AV - That Says It All!". Oh, and Mussolini made the trains run on time. Sorry, what were we talking about again?

Loathed Lib Dems

The Nick Clegg monster in the cartoon is holding a book titled "Policies the British People Loathe" - clearly everyone reading the cartoon is assumed to vote Tory, and loathe the Lib Dems. This leaflet was distributed in Eastbourne, which has indeed had Tory MPs for 98 of the last 100 years; and the County Council is under Conservative control.

But at the 2010 general election, the Lib Dem candidate took the seat, with 47% of the vote. And the Borough Council ward of Old Town, to which this leaflet was targeted, is currently represented entirely by Lib Dem councillors, and has been even under Conservative majorities. So who exactly are the staunch Tory-supporting Lib Dem-loathing voters being targeted here?

Can you have a Positive No Campaign?

This cartoon may not be as disingenuous as the notorious "vote no or the baby gets it" posters, but it doesn't stand up to much scrutiny. In the software world, companies like Microsoft are often accused of using "FUD" to discredit their competitors - not outright lies, nothing that could easily be called libellous, but enough to spread Fear, Uncertainty, & Doubt. Notably, FUD works best if you are trying to maintain the status quo, as people's natural fear of change acts in your favour. But it does rather suggest a lack of confidence in your own advantages.

So, philosophical question time: Is negative campaigning inevitable if you are campaigning for a No vote in a referendum?

PS: Somebody posted this cartoon of a filled-out AV ballot paper on Twitter. It makes no sense, because you don't have to rank every candidate. So in reality, it would look more like this (with and without AV). Either the person that made that cartoon didn't understand how AV works, or it's more FUD.

So, it's Goodbye Burgess Hill!

• Goodbye to the 07:57 Southern Service to London Victoria — and goodbye to the crowded 08:18 when I missed it!
• Goodbye to "the delayed 18:09 service" home, and the confusing service to Seaford, Eastbourne, and Ore
• Goodbye "customers for Glynde, Berwick, Cooksbridge, or Plumpton", who weren't always travelling in the correct part of the train.
• Goodbye to Wivelsfield station, and the steep walk into town.
• Goodbye to the young families of Noel Rise, who greeted me each morning — and who grew up before my eyes!
• Goodbye to the headless eagle, the milk depot, and the dewy spider-webs on the fence — but goodbye too to the constant digging of the road!
• Goodbye to the Martletts, and Market Place
• Goodbye to the sandwich shops, the greengrocer's stall, and the 50p bookshop
• Goodbye to the Post Office, and churchyard
• Goodbye to the park, with its abstract modern sculpture, its muddy fields, and its basketball hoop
• Goodbye to the Railway, the Jacob's, & the Potter's
• Goodbye Disco Carpets, and hairdressers downstairs
• Goodbye to you all - maybe I'll come and visit someday. But then again, maybe not. ;)

Good Riddance

The internet was originally designed to have an address for everything that was connected to it - if you ask a remote server for something, it sends the response back to your address; if you want to make something available, you advertise your address, and so on. But that didn't scale very well, so a whole host of protocols and programs have sprung up for sharing one public address between maybe dozens of computers, and handling the connections going in and out. This is fiddly, and it could get even worse - the pessimists predict that instead of IPv6, we'll end up with ISPs sharing IP adresses between multiple broadband connections, using yet more NAT. Not only will your Skype client be asking your router for a "pinhole" for incoming data, your router will have to ask your ISP for a pinhole through to the "real" internet.

Firewall on a Chip

So, giving everything an IPv6 address will make everything easier, right?

Well... it turns out, the very things that make NAT a nuisance have a rather handy side-effect: ne'er-do-wells can't send random data to your laptop trying to hack in and steal that text file you store all your passwords in. Your router has to look at packets to determine which computer they're for anyway, so it ends up acting like a simple firewall without really trying. And when we connect to a trusted network, we expect it to provide this basic insulation from the wider internet.

Wi-fi has already made this assumption out of date - devices like smartphones, netbooks, and tablets are more or less designed to connect to untrusted networks; even if you never use public hotspots, you don't know how well the office network you've just borrowed the WPA key for is secured. So this is probably a good time to stop trusting routers to protect us.

The alternative is that every computer runs a "personal firewall" - a program that checks all traffic on the machine, both inbound and outbound. At the moment, this means an application you install, which clogs up your CPU and memory, slowing down your machine. So maybe the next generation of devices won't just have a simple network controller, they'll have a fully flexible Network Processing Unit (NPU) - a firewall on a chip, with its own memory, perhaps a bit of solid state storage for accumulated rules, and so on. The CPU won't be taken up with traffic analysis; the OS authors won't have to implement an entire firewall, just drivers for communicating with the NPU; and yet you'll be carrying your own firewall whatever network you connect to.

Splinternet

Now if every device (eventually) has an NPU, what other assumptions can we challenge? First up is that other hallmark of the "trusted" network, the notion of "local" resources. In future, rather than relying on topology ("it's on the same router therefore it's local") trust decisions will have to be made explicitly - the VPN will be more important than the LAN. If you bring your laptop to a meeting, you'll only be granted access to the internet, and maybe to send jobs to a nearby printer; but you'll still have access to your shared server back at HQ (if it's not all "in the cloud" anyway). The devices in question will each have some authentication that knows whether you should be allowed in or not.

The key thing about this is that it is de-centralized - devices would be able to talk to each other in all sorts of ways, using central servers only as brokers for authentication. Devices could share - or even trade - spare resources such as bandwidth, or even CPU. A laptop in a neighbouring room might be able to access a wi-fi hotspot that's out of your range, or be physically closer to a file server than you. (Just make sure you're encrypting all your traffic - another job for the NPU perhaps?)

HTTP over BitTorrent

Now at this point anyone who actually knows how all this works will no doubt be champing at the bit to tell me why everything I've written is outrageous nonsense (and everyone else will have got bored and stopped reading), so I'll just mention one last crazy idea.

Connecting your smartphone to your next-door neighbour's laptop is all very well, but it's hardly going to be a fast connection is it? On the other hand, what if you're both trying to access the same content - wouldn't it be great if you could somehow access each other's cached data?

Obviously you've got to know that the data is kosher, but imagine an HTTP/2.0 response of "333 Use This P2P Hash", or handing your browser a .torrent file. This wouldn't have to be limited to huge files, either - the common resources of a website (JS, CSS, "chrome" images, etc) could be bundled up into one torrent, like the episodes of a series, for you to grab and extract what you need.

Maybe all this is a bit far-fetched, but unless people start working on this next generation of "super-distributed internet" soon, we're going to be stuck in the "IPv6 is more pain than gain" loop for some time to come...

The Installer

The first screen of the Windows installer for OpenOffice.org asks a question which most users won't know how to answer, and gives them the wrong default.

It asks the user where to unpack the temporary files needed by the installer - files which the user should never need to see - and defaults to unpacking them on the user's desktop.

There are several things wrong with this dialog:

1. It doesn't tell you why you'd ever change it. The way the dialog is worded, it sounds like the product itself will live in the selected location. But in actual fact, the only situations I can think of where you would need to change it are if you have limitted space on a particular disk partition, or an unusual permission setup. The default wording should reflect this:

   "The LibreOffice installer needs to unpack some temporary files to proceed. This will require roughly XMB of space. If the location shown below is not appropriate, please specify an alternative location."

2. The desktop is not a temp folder. The "desktop cleanup wizard" is one of those bits of Windows that should never have been necessary, and it is abuses like this that mean it is. Quite simply, the default location for temporary installation files should be the temp directory provided by Windows.
3. More subtly, these files aren't actually cleaned up. This is possibly the reason (or, excuse) for unpacking to the desktop rather than a temp folder: a successful installation of OpenOffice.org currently leaves a folder of unpacked installation files lying around, and it's up to the user to notice and delete these. I can only imagine that there are some problems with the installation executable deleting itself, but surely a stub could be placed in the permanent install directory to clean up the files once everything else has finished?

The Help Assistant

The OpenOffice.org Help Assistant cunningly implements the least popular part of Microsoft's infamous "Office Assistant" feature - the cutesy cartoon graphic that pops up while you're working - without implementing its actual purpose - showing context-sensitive tips with a minimum of user interaction, and without using up too much screen space.

If the light-bulb graphic pops up while you're typing in a Writer document, you know that the help system is trying to tell you something. But you know absolutely nothing else - there is no polite speech bubble, no hint if you mouse over the icon, nothing at all until you click the icon at which point a full-size help window appears (and, in my experience, appears slowly). This is, frankly, worse than useless.

The simplest solution to this, frankly, is just to remove the feature. But if they really want this feature, then there is a small change that would change it from completely pointless to actually quite helpful: show a one-line summary of what the tip is actually about, before you click the graphic!

Conditional Formatting in Spreadsheets

This one isn't such a big deal, really, but it's one of those little details that puts people off switching from, ahem, rival applications. It's also one of those cases where a bit of pragmatism is required.

Basically, if you want to have the formatting of cells in a spreadsheet in OpenOffice.org, you have to specify a named style for each rule.

Now, don't get me wrong, the style manager is one of the things I really like about OpenOffice.org when I'm working in Writer - to me, it makes all the difference between a "rich text editor" and a "word processor", and is much better than the versions of MS Word I've used. I can also see the reasoning behind allowing any styling to be applied by the conditional formatting, and the interface makes it easy to add a new style if you need to.

But 99% of the time, people will want to change two aspects of the matched cells: the text colour and the background colour. This is all most spreadsheet applications allow you to change, but they allow you to change them really easily. So, I'm happy for a new style to be created behind the scenes, but can I please have two little boxes labelled "Text colour" and "Background colour"?

Yeah, I know...

It's open source, I should

1. Check the issue tracker for previous discussion of these issues.
2. Download the source code and fix them myself.

But, y'know, I have to go and make some dinner now. Nobody's perfect, eh?

O Romeo, Romeo!
Wherefore art thou Romeo?

Undoubtedly one of the most quoted lines of Shakespeare's Romeo & Juliet. But what's the right answer? If you said "I'm over here!" then you're wrong - not because of where Romeo may or may not be right now, but because that's quite simply not what "wherefore" means.

wherefore (interrogaive adverb) - for what reason
- The Concise Oxford English Dictionary

Juliet is not looking around to find her lover, she's despairing that she should have fallen in love with one of her family's sworn enemies: of all the people in all the world, why did he have to turn out to be Romeo Montague?

What's in a name? That which we call a rose
By any other name would smell as sweet

So a better answer would be "just because!" or - the answer implied by Shakespeare - "by a mere accident of birth, a whim of the gods".

So wherefore does everyone get it wrong?

There must be plenty of people who do know what "wherefore" means, but evidently there are plenty more who don't, and simply guess that "wherefore" is a long-winded way of saying "where". And it's not that illogical a guess, given Shakespeare's use of thoroughly over-the-top words - like "incarnadine", meaning "turn red". If it turned out that "art" or "thou" were being used wrong as well, I guess we shohuldn't be surprised, as it is more or less the same guesswork that lets us understand those.

We'll tak a cup of kindness yet,
For auld lang syne!

When Richard Dawkins was first pondering the idea of "memes" - self-replicating ideas subject to the same evolutionary forces he had just described in The Selfish Gene - he used the line above as an example. There is no line which says "for the sake of auld lang syne", but people continue to sing it. He points out that the sound of people singing "the sake of" drowns out those going straight on to the "auld", meaning the "sake of" meme is dominant, and propogates, while the more correct version cannot compete.

O Romeo, Romeo!
Wherefore art thou Romeo?

Perhaps there is something similar going on with the Shakespeare line. If you put the stress on the last "Romeo", you can highlight the question of identity; but it's somehow not as satisfying a rhythm as stressing the "art", which is then more open to the where = wherefore misinterpretation. And if - as is generally the case - you are quoting the line out of context, the satisfying rhythm is the one that will stick in your mind.

Indeed, considering how few people seem to realise what it means, the line is incredibly widely quoted, suggesting that there is a catchy rhythm to it. It is, in other words, a highly successful meme, but one which has, in order to spread, abandoned its original meaning. It has become so prevalent as a 'snowclone' that "wherefore art thou?" could almost be considered to have gained the meaning of "where are you?"

It still annoys me whenever I hear people getting it wrong, though!

The idea, as I originally came upon it, appealed: "you already have identities you can prove are yours, in the form of URLs - why not use them as a universal sign-on?" And obviously, the main URL I control is this one - http://rwec.co.uk - and OpenID allows me to use that identity without having to run my own identity server. This is called delegation, and lets you "delegate" your own URL to another identity (that is, another URL), on a server that's set up to do the OpenID negotiation.

To me, delegation is the single most appealing feature of OpenID - if this is to be my "one identity to rule them all", I don't want it vulnerable to supplier lock-in, and the fact that http://rwec.co.uk is my property guarantees me continued control. But when I started looking into the details earlier, I was confused, then dismayed, at how much of a poor relation delegation has become in the OpenID world.

Now, the "get an OpenID" page boasts that lots of my existing accounts can be used as OpenID - including Yahoo!, Google, and LiveJournal. "Brilliant,", I thought, "I'm always logged in to Yahoo!, to use Flickr, I can delegate to that."

So, how do you implement delegation? "It's simple," I'm repeatedly told, "you just add 2 link tags to your HTML head!" The get an OpenID page gives a very brief mention of delegation, as a nice little side-line you might want to play with, and links to this ancient tutorial telling you what link types you need to add. There are two problems with this blog post:

1. An immediate unanswered question is "what do you put in the value of those 2 tags?" - one is evidently the URL you are delegating to, but the other - no clues given.
2. Less obvious, but even more serious, is that the post is out of date - it describes the tags for OpenID version 1.1, but most services now implement OpenID 2.0, which uses different tags (although the values, it turns out, are much the same).

Next, I found a nifty little site called Delegatid, which lets you enter an existing OpenID, and generates the HTML for delegating to it. Perfect! Except that when I entered my LiveJournal account, it generated a seemingly invalid http-equiv="X-XRDS-Location" header, and only the OpenID 2.0 links, even though LiveJournal supports OpenID 1.1. Not sure why, not sure who to tell.

But here's the real kicker, if I delegate to my Yahoo! ID, it doesn't actually delegate - the headers work fine, I authenticate myself with Yahoo!, and then I'm logged into the site I'm trying to access (the "Relying Party" in the jargon). But I'm logged in with my Yahoo! ID, not my nice, permanent, lock-in proof URL. It turns out that in OpenID 2.0, Providers don't have to support delegation - they accept the request, but return the ID they have for you, and the delegation acts as nothing more than a URL forwarding system. This is all tied up with the handy way you can enter "yahoo.com" in an OpenID login box, and it will authenticate you - obviously, you're not claiming to own yahoo.com, just that they can negotiate an ID for you.

So it turns out that both my Yahoo! and Google IDs support OpenID 2.0 only (sorry, early adopters, no logins for you!), and don't support delegation; I have to sign up for an account with a random OpenID provider. Of which there are, um, lots, around - I can't find any kind of matrix with even such basic details as "supports OpenID 1.1, supports OpenID 2.0, supports delegation"; there's an OpenID Directory, but it feels more like an SEO exercise than an actual resource to help me choose. The Spread OpenID Provider Comparison would be promising, but it was formally abandoned in January. Nor will the Delegatid tool give me any warning that the delegation I'm setting up is no more use than a 302 redirect - I guess the auto-discovery protocol doesn't handle this either.

And of course, I won't be able to use it instead of my Google account, or my Yahoo! account - they don't accept OpenID, they just provide it, with no delegation, so for them it's just another way of taking over your online life. No thanks.