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

[Erik Wilde <[e-mail]>]

hello mark.

On 2015-05-20 08:50, Mark Nottingham wrote:
> On 20 May 2015, at 4:23 pm, Erik Wilde <[e-mail]> wrote:
>> 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).

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 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.

>> - 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.

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.

-- 
erik wilde | mailto:[e-mail]  -  tel:[phone] |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |