Well, it is controversial whether rev="canonical" is the right thing to be used. Furthermore the rev attribute has been removed from HTML5.

See http://annevankesteren.nl/2009/04/rev-canonical for some details.

A rebuttal: http://erikvold.com/blog/index.cfm/2009/4/21/rev_canonical_g...

I've disagreed with the rev attribute being removed from html5 since I read about it. The draft isn't final though, so time will tell...

But back to html4... Google, Yahoo and MS all support (or have announced support for) rev="canonical". The only "standards" that matter are the ones that are used. :)

> the only "standards" that matter are the ones that are used

Right, like upper case html tags and the iframe tag...

It's a difficult time for the web, and real standards are hard to come by.

The 'standards that matter are the ones that are used' attitude is exactly what got us into this mess in the first place (Microsoft up front with their 'extensions').

I'm all for waiting for the dust to settle and then refactoring using whatever the standards body decides, even if that would be against my personal preference.

Using something on purpose to try to subvert the process to me smacks of driving on the left hand side when the standard behaviour is to drive on the right. It creates a lot of trouble for no good reason other than to prove that 'you can'.

Of course you can. But do you really want to aggravate others just to show that you can ?

There is plenty of stuff in the current html standard that goes against my personal preference but I won't let that get in the way of at least trying to comply.

The 'standards that matter are the ones that are used' attitude is exactly what got us into this mess in the first place (Microsoft up front with their 'extensions').

The "standards will be written as they will be implemented by the browser manufacturers" is exactly the approach that the whatwg has taken on html5:

  After an inordinate amount of discussions, both in public and privately, 
  on the situation regarding codecs for <video> and <audio> in HTML5, I have 
  reluctantly come to the conclusion that there is no suitable codec that 
  all vendors are willing to implement and ship.

I'm all for waiting for the dust to settle and then refactoring using whatever the standards body decides, even if that would be against my personal preference.

Which is exactly the approach i said I was taking. And despite the tone of the tone of your post, I dont seem to recall saying that I was going to continue using rev in html5 even though it was removed from the (draft) spec. I will continue to use it with html4, though.

Ah, ok. Apologies then!

This was done before that with HTTP 302.

rev="canonical" doesn't compare to HTTP 302. HTTP 302 doesn't allow a user to discover a shortened url provided by the publisher. It's just a temporary redirect.

Who cares if its a short URL or not? An URL is an URL. If you want to "discover" what is behind a link, do something like

  $ curl -I http://faux.com/XiSk
  HTTP/1.1 302 Moved Temporarily
  Server: nginx/0.6.35
  Date: Mon, 17 Aug 2009 09:47:11 GMT
  Content-Type: text/html
  Transfer-Encoding: chunked
  Connection: keep-alive
  Location: http://www.faux.com/the/realz/resource

And HTTP 302 is more than just a redirect. 302 says, "Hey, the resource is over here, but check back with me next time before you request that same resource because it might change" whereas a HTTP 301 says, "Don't worry about checking back here next time you want the resource, its really over there".

Maybe URL shortners should be throwing 301's around instead of all of this rel nonsense.

I think you're missing the purpose of this thing. rel=-hortlink / rev=canonical answer the following question:

"I'm on a page with a really long URL. Is there a preferred shorter URL for this page?"

In the context of URL shorteners, 302 redirects usually take you from a short URL to a longer one. rel=shortlink is about discovering the preferred short URL when all you have is the long URL.