Subject: [apps-discuss] HTTP header field for "URI lifetime"

From: Erik Wilde <[email-masked]>
Date: Wed, 20 May 2015 08:23:10 +0200

hello.

we had some discussions at www2015 about a possible HTTP header for 
exposing a URI's "lifetime". please do not get hung up on any 
terminology, but the scenarios we discussed included:

- a service entering the sunset period and wanting to expose the fact 
that it is going to stop operating at some point in time.

- a service doing archiving and wanting to expose that resources will 
only be kept until a certain time, and then disposed.

- a service that might want to encourage users to check back regularly 
so that they might implement some strategy to check back periodically 
and see if the resource is still available or not.

we could not think of an exiting HTTP header field for exposing this 
kind of information. i have two questions:

- is there such a header field?

- if not, is that something that people find interesting and possibly 
useful, or do people think that's not needed or even a bad idea?

thanks a lot and cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 May 2015 16:50:57 +1000

On 20 May 2015, at 4:23 pm, Erik Wilde <[email-masked]> wrote:
> 
> hello.
> 
> we had some discussions at www2015 about a possible HTTP header for exposing a URI's "lifetime". please do not get hung up on any terminology, but the scenarios we discussed included:

Hm. It's come up before, and there's a legitimate distinction between this (which is about the resource) and Expires (which is about a specific representation).

However, I'm having trouble seeing how it would be useful to clients — can you illustrate the use cases a little more fully?

E.g., 

> - a service entering the sunset period and wanting to expose the fact that it is going to stop operating at some point in time.

What will a client do with that information? 

Given that this necessarily requires someone to predict the future and make some level of commitment to that, it may be that the information it conveys is of very limited use — i.e., people won't trust it :)

> - a service doing archiving and wanting to expose that resources will only be kept until a certain time, and then disposed.

This seems somewhat related to Memento; CC:ing Herbert for his comment / information.

Cheers,

> - a service that might want to encourage users to check back regularly so that they might implement some strategy to check back periodically and see if the resource is still available or not.
> 
> we could not think of an exiting HTTP header field for exposing this kind of information. i have two questions:
> 
> - if not, is that something that people find interesting and possibly useful, or do people think that's not needed or even a bad idea?
> 
> thanks a lot and cheers,
> 
> dret.
> 
> -- 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   https://www.mnot.net/

---

From: Karl Dubost <[email-masked]>
Date: Wed, 20 May 2015 10:08:24 +0200

Hi,

> Hm. It's come up before, and there's a legitimate distinction between this (which is about the resource) and Expires (which is about a specific representation).

Maybe Mark is referring to the discussion (one among probably others):

`Until:` HTTP header when the representation will disappear in the future [1]

It seems very similar.

[1]: https://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/thread.html#msg1030

--
Karl Dubost 🐄
http://www.la-grange.net/karl/

---

From: Erik Wilde <[email-masked]>
Date: Wed, 20 May 2015 10:32:45 +0200

hello mark.

> Hm. It's come up before, and there's a legitimate distinction between this (which is about the resource) and Expires (which is about a specific representation).

we were specifically not interested in the caching mechanisms, because 
like you say, these are about the "lifetime of the resource state", and 
not about the resource as such.

> However, I'm having trouble seeing how it would be useful to clients — can you illustrate the use cases a little more fully?

so, one thing from my own experience is retention in content management: 
there are many scenarios where some data needs to be kept around for 
regulatory reasons for a certain period of time, and then it can and 
maybe will be removed. that's a fairly large category of scenarios.

another one was decommissioning of services: at some point, a decision 
may be made to take down a service at some point in time. if this could 
be made visible in the uniform interface, then clients having awareness 
of this would have an easier time to maybe alert users. for some time, 
these services may still operate but redirect, and that at some time 
they may disappear completely.

> What will a client do with that information?

that depends on the client. services might simply raise alarms that some 
of the resources they are using are about to disappear. clients such as 
browsers may alert users that bookmarks are going to expire and 
encourage users to maybe check for redirects, or archive the page before 
it disappears.

> Given that this necessarily requires someone to predict the future and make some level of commitment to that, it may be that the information it conveys is of very limited use — i.e., people won't t…

retention and decommissioning are relatively reliable ways to predict 
the future, but of course in many other cases there is no such 
mechanism. and of course this is more a hint than anything else, but it 
may be a hint worth having in the uniform interface.

> This seems somewhat related to Memento; CC:ing Herbert for his comment / information.

yes, we did talk about memento. this just seemed to be way more than 
what we were discussing, and mostly revolve around the scenario of how 
to expose archived information ("looking into the past"), and not so 
much about just looking, as you said it, "into the future",

thanks and cheers,

dret.

---

From: Erik Wilde <[email-masked]>
Date: Wed, 20 May 2015 10:43:58 +0200

hello karl.

> [1]: https://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/thread.html#msg1030

yes, that's pretty much exactly what we were discussing. it seems like 
this wasn't going anywhere, but i am sure that the idea has popped up in 
a variety of forums at some point in time. and we were simply debating 
whether there was some mechanism, and i said i couldn't think of any.

maybe it would be good if there was one for those services that can 
"predict the future", and for those clients willing to have some faith 
in that prediction. maybe a human readable text, and/or a link to an 
"explanation resource" might help with that.

cheers,

dret.

---

From: Graham Klyne <[email-masked]>
Date: Wed, 20 May 2015 10:30:57 +0100

On 20/05/2015 07:23, Erik Wilde wrote:
> hello.
>
> we had some discussions at www2015 about a possible HTTP header for exposing a
> URI's "lifetime". please do not get hung up on any terminology, but the
> scenarios we discussed included:
>
> - a service entering the sunset period and wanting to expose the fact that it is
> going to stop operating at some point in time.
>
> - a service doing archiving and wanting to expose that resources will only be
> kept until a certain time, and then disposed.
>
> - a service that might want to encourage users to check back regularly so that
> they might implement some strategy to check back periodically and see if the
> resource is still available or not.
>
> - if not, is that something that people find interesting and possibly useful, or
> do people think that's not needed or even a bad idea?

Following the subsequent couple of messages, this seems like the goals might be 
somewhat experimental.  For such purposes, I think the desired effect *could* be 
achieved using a Link: header with a URI link relation; e.g., something like:

     Link: <http://example.org/RetentionInformation>;
           rel=http://linktype.example.org/retentionPolicy/

(If you don't want to store the retention information separately, maybe a data: 
URI?)

I see an advantage of such an approach is that you could experiment with 
different kinds of retention information by changing the link relation URI, and 
the approach might play nicely with a wider linked data infrastructure.

Just a thought.

#g
--

---

From: Erik Wilde <[email-masked]>
Date: Wed, 20 May 2015 11:50:20 +0200

hello graham.

On 2015-05-20 11:30, Graham Klyne wrote:
> Following the subsequent couple of messages, this seems like the goals
> might be somewhat experimental.  For such purposes, I think the desired
> effect *could* be achieved using a Link: header with a URI link
> relation; e.g., something like:
> (If you don't want to store the retention information separately, maybe
> a data: URI?)
> different kinds of retention information by changing the link relation
> URI, and the approach might play nicely with a wider linked data
> infrastructure. Just a thought.

interesting idea. however, this shifts the problem from the header field 
to a well-known link relation *and* and well-known representation to 
even get the date. the reason why we were discussing a header field was 
also that it would be very clear to find in the uniform interface and 
very easy to process, and by default, no link would need to be 
dereferenced to get to the most important piece of information. so the 
potential header field might look something like this:

Sunset: "Mon, 06 Jul 2015 09:00:00 GMT", reason = "We're shutting down 
for good", reasonURI = http://example.com/goodbye.html

and both the human-readable label and the link to the sunset information 
resource would be optional. this seems to be a bit more explicit than 
what you're suggesting, but i do agree that in the end, both approaches 
are representing (almost) the same information.

cheers,

dret.

---

From: Graham Klyne <[email-masked]>
Date: Wed, 20 May 2015 11:13:42 +0100

On 20/05/2015 10:50, Erik Wilde wrote:
> interesting idea. however, this shifts the problem from the header field to a
> well-known link relation *and* and well-known representation to even get the
> date. the reason why we were discussing a header field was also that it would be
> very clear to find in the uniform interface and very easy to process, and by
> default, no link would need to be dereferenced to get to the most important
> piece of information. so the potential header field might look something like this:
>
> Sunset: "Mon, 06 Jul 2015 09:00:00 GMT", reason = "We're shutting down for
> good", reasonURI = http://example.com/goodbye.html
>
> resource would be optional. this seems to be a bit more explicit than what
> you're suggesting, but i do agree that in the end, both approaches are
> representing (almost) the same information.

Fair enough.  I thought it might be interesting to see how close to this one 
might get with a Link: header:

  Link: 
<data:,2015-07-06T09:00:00Z,reason=%22We're%20shutting%20down%20for%20good%22,reasonURI=http://example.com/goodbye.html>,rel=http://linktype.example.com/sunset

It's clearly not as pretty, but I can't tell how important that might be.

#g
--

---

From: Herbert Van de Sompel <[email-masked]>
Date: Wed, 20 May 2015 08:42:39 -0600

hi,

(Thanks for cc-ing me)

Rather interesting. Indeed, it is not directly related to Memento; the
Memento-Datetime header is for expressing that a resource has been
"frozen" at the datetime that is conveyed as the header value, i.e. it
entails a promise that the resource will not change beyond the
expressed datetime. The way I understand what you are discussing, this
is about a header that indicates that a URI will no longer be existent
starting at a certain date, ie past that date one can expect a 404 or
similar bad news.

But there is a relation with a possible web archiving use case: if a
web archiving client comes across a URI-R that indicates its
extinction datetime, then the client could make it a priority to crawl
that URI-R and archive its representation at URI-M in a web archive.
Using Memento, URI-M would then have a HTTP link with relation type
"original" pointing at URI-R. Even when URI-R is gone, using Memento,
URI-R could still be used to access archived snapshots of URI-R such
as URI-M. Magic :-)

I am thinking that this could be particularly useful for shortened
URIs, many of which - as we know - aren't long lasting and the minters
of those URIs are very much aware of that. If these minters would
convey their short term URI retention strategy using a header, then
applications that consume/mine tweets and resources linked in tweets
(there's a lot of research in this realm) could optimize their data
collecting strategy by taking the URI expiration date into account.

Cheers

Herbert

On Wed, May 20, 2015 at 2:32 AM, Erik Wilde <[email-masked]> wrote:
>>> exposing a URI's "lifetime". please do not get hung up on any terminology,
>>> but the scenarios we discussed included:
>>
>> Hm. It's come up before, and there's a legitimate distinction between this
>> (which is about the resource) and Expires (which is about a specific
>> representation).
>
>
> we were specifically not interested in the caching mechanisms, because like
> you say, these are about the "lifetime of the resource state", and not about
> the resource as such.
>
>> However, I'm having trouble seeing how it would be useful to clients — can
>> you illustrate the use cases a little more fully?
>
>
> regulatory reasons for a certain period of time, and then it can and maybe
> will be removed. that's a fairly large category of scenarios.
>
> another one was decommissioning of services: at some point, a decision may
> be made to take down a service at some point in time. if this could be made
> visible in the uniform interface, then clients having awareness of this
> would have an easier time to maybe alert users. for some time, these
> services may still operate but redirect, and that at some time they may
> disappear completely.
>
> that depends on the client. services might simply raise alarms that some of
> the resources they are using are about to disappear. clients such as
> browsers may alert users that bookmarks are going to expire and encourage
> users to maybe check for redirects, or archive the page before it
> disappears.
>
>> Given that this necessarily requires someone to predict the future and
>> make some level of commitment to that, it may be that the information it
>> conveys is of very limited use — i.e., people won't trust it :)
>
>
> retention and decommissioning are relatively reliable ways to predict the
> future, but of course in many other cases there is no such mechanism. and of
> course this is more a hint than anything else, but it may be a hint worth
> having in the uniform interface.
>
> yes, we did talk about memento. this just seemed to be way more than what we
> were discussing, and mostly revolve around the scenario of how to expose
> archived information ("looking into the past"), and not so much about just
> looking, as you said it, "into the future",
>
> thanks and cheers,
>
>
> dret.
>
> --

-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/

==