author: Robert Spychala (http://twitter.com/robspychala) - 4/1/2009
version 1.0.1 - added diagram 4/2/2009
version 1.0.2 - added second diagram 4/3/2009
version 1.0.3 - added Bookmarklet 4/6/2009
version 1.0.4 - fixed Bookmarklet
version 1.0.5 - fixed Bookmarklet (@amoebe's suggestion)
version 1.1.0 - removed to rel="alternate" from feedback (Sam Johnston) and case against rev=canonical (John Gruber) 4/12/2009
version 1.1.1 - reverted back to the original "shorturl" 4/13/2009
version 1.1.2 - http://metamark.net/ suggested to use redirect HTTP code 301 - 4/16/2009
version 1.1.3 - added http://shorturl.appjet.net/ - 4/16/2009
version 1.1.4 - modfied Bookmarklet to use shorurl.appjet.net API 4/29/2009
version 1.1.5 - appjet.net discontinued their service so I moved the bookmarklet to http://relshorturl.appspot.com/ - 7/26/2009
Short URL auto-discovery is a simple way to link a long URL with a short URL. The following code should be placed in the <head> section of the HTML page.
In most real-world situations, the short URL then redirects with an HTTP code 301 to the long URL, but that behavior is not covered by this RFC.
That's it! :) try it at: http://relshorturl.appspot.com/
why not use rel="alternate .... "
Sam Johnson pointed out alternate doesn't make sense since it implies a link to same content but different format like PDF for example
why not rel="shortcut"
Shortcut in the web context is not well understood nomenclature when referring to short URLs (fine to define shortcut icons with rel="shortcut icon" though and if we wanted to follow that model (adjective noun) we'd use rel="shortcut url", but that seems excessive)
Potential legacy code breakage as suggested by http://twitter.com/soypunk/status/1509403319
Also somehow shortcut seems like the wrong wording... implies a link that will bypass something ... a splash screen, etc.
why not rel="shorter" or rel="short"
Implies shorter version of the content
why not rev="canonical"
rev attribute is absent from HTML5, confusing with rel="canonical" and breaks Google's proposed definition of canonical for search purposes.
why not rel="shorturi"
Part of making a new RFC to describe a simple concept is simple naming. People know that a URL is what's in the location bar in their browser. Besides we'd never see a URI that's not an URL in this context.
why not rel="short_url"
The _ is ugly.
why not rel="shortlink"
nice, but not that much different from shorturl to warrant a change IMHO. shortaddress? shortlocation? there are tons of other options ex: tinylink? If consensus is that it's better i'll switch for sure. better to have one way to do a simple thing, but i just don't want to knee-jerk change it cause people already implemented rel="shorturl".
Over the past few years SEO efforts lent to longer and more descriptive canonical URLs for content pages. During this time URL shorteners such as tinyurl.com and others came in to help undo that trend and make URLs fit into limited 140 character situations for sites like twitter.com or SMS messages.
Unfortunately, URL shorteners lose link information. As a user it is valuable to know that a link you're clicking is going to a content site such as youtube.com, nytimes.com or a potentially harmful and malicious site.
Furthermore, the site that is represented by the shortened URL might have already been visited by you - and clicking on it again might not have been the intent of the user.