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

Mark Nottingham <mnot@mnot.net> Wed, 20 May 2015 06:51 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507781B357E for <apps-discuss@ietfa.amsl.com>; Tue, 19 May 2015 23:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level:
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSnhzhBySGLi for <apps-discuss@ietfa.amsl.com>; Tue, 19 May 2015 23:51:30 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4D11B35B2 for <apps-discuss@ietf.org>; Tue, 19 May 2015 23:51:03 -0700 (PDT)
Received: from [192.168.0.11] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9374522E200; Wed, 20 May 2015 02:50:59 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <555C284E.1030208@berkeley.edu>
Date: Wed, 20 May 2015 16:50:57 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <0AD556BB-614D-47D0-8509-C8670E01E82B@mnot.net>
References: <555C284E.1030208@berkeley.edu>
To: Erik Wilde <dret@berkeley.edu>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/RNZyiZOj0v_e-LJ3Beh2LCazUNU>
Cc: Herbert Van de Sompel <hvdsomp@gmail.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] HTTP header field for "URI lifetime"
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2015 06:51:33 -0000

On 20 May 2015, at 4:23 pm, Erik Wilde <dret@berkeley.edu> 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:
> 
> - 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:dret@berkeley.edu  -  tel:+1-510-2061079 |
>           | UC Berkeley  -  School of Information (ISchool) |
>           | http://dret.net/netdret http://twitter.com/dret |
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

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