One solution to this problem is to use a reverse proxy instead of a redirect.  We do this for our ARKs, so temporary URL is not shown to the end user at all.

This is not a general solution, especially for people who are redirecting externally and are concerned about the phishing scenario described in:

http://www.w3.org/TR/2001/NOTE-cuap-20010206#cp-temp-redir

I think the ideal solution would be to have the browser location bar show the original URL, with a conspicuous indication of redirection, which would provide access to the redirection chain and the final URL.  Bookmarking would default to the original URL, but provide the option of using the final URL instead.

-Esme
--
Esme Cowles <[log in to unmask]>

"Everybody knows that the boat is leaking,
 Everybody knows that the captain lied." -- Leonard Cohen, Everybody Knows

On Feb 24, 2010, at 5:10 PM, Erik Hetzner wrote:

> Hi -
> 
> This is an issue which is of great importance to persistent
> identifiers on the web, and one which I thought should be brought to
> the attention of the c4l community. It affects PURLs, ARKs, and in
> general any system that redirects a persistent or permanent URI to
> another, temporary URI. I did not, however, realize that there was
> active debate about it.
> 
> Briefly, from [1]:
> 
>  3.4 Do not treat HTTP temporary redirects as permanent redirects.
> 
>  The HTTP/1.1 specification [RFC2616] specifies several types of
>  redirects. The two most common are designated by the codes 301
>  (permanent) and 302 or 307 (temporary):
> 
>  * A 301 redirect means that the resource has been moved permanently
>    and the original requested URI is out-of-date.
> 
>  * A 302 or 307 redirect, on the other hand, means that the resource
>    has a temporary URI, and the original URI is still expected to
>    work in the future. The user should be able to bookmark, copy, or
>    link to the original (persistent) URI or the result of a temporary
>    redirect.
> 
>  Wrong: User agents usually show the user (in the user interface) the
>  URI that is the result of a temporary (302 or 307) redirect, as they
>  would do for a permanent (301) redirect.
> 
> There is more info at [2]. You can find the email thread at [3].
> 
> best,
> Erik Hetzner
> 
> 1. http://www.w3.org/TR/2001/NOTE-cuap-20010206#cp-temp-redir
> 2. http://www.w3.org/2001/tag/group/track/issues/57
> 3. [log in to unmask]" target="_blank">http:[log in to unmask]
> 
> 
> Resent-From: [log in to unmask]
> From: Jonathan Rees <[log in to unmask]>
> Date: February 23, 2010 5:00:11 PM EST
> To: [log in to unmask]
> Subject: ACTION-348 some draft text re redirection + address bar
> 
> 
> http://www.w3.org/2001/tag/2010/02/redirects-and-address-bar.txt
> 
> Written in the style of a blog post, and making use of
> state-of-the-art theory (such as it is) of http semantics.
> 
> If this gets review and approval of some kind (especially from TimBL,
> who has been the vocal campaigner on this question) I'll htmlify and
> post it and be done with this action. Not sure what else to do.
> 
> Jonathan
> 
> http://www.w3.org/2001/tag/2010/02/redirects-and-address-bar.txt
> 
> Written in the style of a blog post, and making use of
> state-of-the-art theory (such as it is) of http semantics.
> 
> If this gets review and approval of some kind (especially from TimBL,
> who has been the vocal campaigner on this question) I'll htmlify and
> post it and be done with this action. Not sure what else to do.
> 
> Jonathan
> 
> 
>