Subject: Managing Obsolete Information

From: Karl Dubost <[email-masked]>
Date: Wed, 5 Sep 2012 13:03:10 -0400

Maybe yet another silly question.

Summary: How to manage the memory shoebox?
         (or managing future obsolete information.)

Not a proposal/question for HTTP/1.1, but for future version.

It is a question which pops up often in between people on managing URIs on a site.

Scenario: 
— Paul: "This documentation article is giving outdated information. Let's kill it."
— Jane: "This information might have an historical interest. Let's not kill it."

Then discussions start on the different ways to handle that. Some of the suggestions involve:

* 410 Gone. Kill the content and ask clients to forget it.
* 301 Permanent Redirect. Kill the "previous" content and the previous "URI", to the new content and new URI.
* 301 Permanent Redirect. Move it to an archive.example.org web site and keep the old content.
* 200 OK for browsers and personal user agent, but send a 410 Gone or 403 to search engines (Involving user agent sniffing). So the information is accessible but not indexable to avoid to pollute search results.
* 200 OK with noindex in the markup works only for HTML
* robots.txt for blocking certains URIs (with all the issues which go with robots.txt)

I'm not sure if there is a right solution and maybe it's fine as it is. I would imagine sometimes a code in 2xx series could be sent back ala

2xx Obsolete or 2xx Archived

It is different from Gone. It just says the information at this URI is here we can give it to you but note that it is not meant as something fresh. The clients coming to the site know their goals such as archiving bots for example. Some bots which are more focused on the new new shining things might decide to ignore this URI because it is obsolete and prefer to spend time indexing good fresh stuff. Bookmarks of people fond of old stuff will still be working.   

Note that there could be even a Location: sent along with the new fresh stuff is there. You may decide to go or stay here.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software

---

From: Joe Mason <[email-masked]>
Date: Wed, 5 Sep 2012 17:19:16 +0000

> From: Karl Dubost [[email-masked]]
>
> I'm not sure if there is a right solution and maybe it's fine as it is. I 
> would imagine sometimes a code in 2xx series could be sent back ala
> 
> It is different from Gone. It just says the information at this URI is here we
>  can give it to you but note that it is not meant as something fresh. The 
> clients coming to the site know their goals such as archiving bots for 
> example. Some bots which are more focused on the new new shining things might 
> decide to ignore this URI because it is obsolete and prefer to spend time 
> indexing good fresh stuff. Bookmarks of people fond of old stuff will still be
>  working.
> 
> Note that there could be even a Location: sent along with the new fresh stuff 
> is there. You may decide to go or stay here.

I think this would be better as a 3xx code.  (3xx Supplanted, perhaps - I was going to say Superseded but it's too hard to spell.) 

Joe
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Zhong Yu <[email-masked]>
Date: Wed, 5 Sep 2012 12:42:46 -0500

How about a new header

    HTTP/1.1 200 OK
    Obsoleted-By: /foo-v2.0

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 05 Sep 2012 18:07:20 +0000

In message <CACuKZqFBeCu2T5Tv5KyJCzsEfWC2=[email-masked]>
, Zhong Yu writes:

>> It is different from Gone. It just says the information at this URI is here
>>we can give it to you but note that it is not meant as something fresh.

With "active computer-archeologist in datamuseum.dk" hat on, that sounds
genuinely useful.

With my "old jaded IT-professional" hat on, I think it is a narrow
semantic detail which will be instantly lost and forgotten by all
but the most dilligent and RFC-militant Web-masters.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 5 Sep 2012 12:47:08 -0700

It isn't an HTTP response status because the information that was requested
is still being supplied.  The semantics you desire are orthogonal.

We defined the link relation "obsoleted-by" ages ago to serve exactly
that purpose.  It can be provided in a Link header field in HTTP and/or a
<link> element in HTML.

....Roy

---

From: Karl Dubost <[email-masked]>
Date: Wed, 5 Sep 2012 15:58:23 -0400

> that purpose.  It can be provided in a Link header field in HTTP and/or a

Sweet!
ok not in the RFC5988
http://tools.ietf.org/html/rfc5988#section-6.2.2

Do you have a pointer? Or a hint on where it could be defined.

There is a 'successor-version' (but not exactly the same)
http://tools.ietf.org/html/rfc5829#section-3.6

To note: An obsolete or archived document doesn't necessary have a successor or new version. It might just be the document by itself.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 5 Sep 2012 13:21:51 -0700

> Do you have a pointer? Or a hint on where it could be defined.

One of the old W3C mailing list archives for HTML or Links.  See

http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt

I am pretty sure there was an update somewhere that changed it
to "obsoleted-by" instead of "obsoletes", but it was a long time ago.

....Roy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 06 Sep 2012 09:57:37 +0900

What about pages/information that is partly outdated, but partly still 
up to speed? What about pages that are not exactly up-to-date, but also 
not completely outdated (i.e. better than nothing)? HTTP has the q 
parameter that may be able to deal with such gradations, but it's not 
exactly easy to use (which is not the q parameter's fault).

As for search engines, they try to use all kinds of hints to figure out 
whether a page is still up to speed, so there may not be such a big need 
from them for this (also because the chance that such information will 
be missing/wrong is high).

Regards,   Martin.