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

Graham Klyne <gk@ninebynine.org> Wed, 20 May 2015 10:13 UTC

Return-Path: <gk@ninebynine.org>
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 DF93E1B35D5 for <apps-discuss@ietfa.amsl.com>; Wed, 20 May 2015 03:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] 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 zvoYT9dRp8YV for <apps-discuss@ietfa.amsl.com>; Wed, 20 May 2015 03:13:37 -0700 (PDT)
Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 18B0A1B35C2 for <apps-discuss@ietf.org>; Wed, 20 May 2015 03:13:37 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1Yv10J-0005O6-s6; Wed, 20 May 2015 11:13:35 +0100
Received: from oerc-dynamic-205.oerc.ox.ac.uk ([129.67.194.205]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1Yv10J-00083u-F9; Wed, 20 May 2015 11:13:35 +0100
Message-ID: <555C5E56.3010202@ninebynine.org>
Date: Wed, 20 May 2015 11:13:42 +0100
From: Graham Klyne <gk@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Erik Wilde <dret@berkeley.edu>, IETF Apps Discuss <apps-discuss@ietf.org>
References: <555C284E.1030208@berkeley.edu> <555C5451.5060804@ninebynine.org> <555C58DC.7010309@berkeley.edu>
In-Reply-To: <555C58DC.7010309@berkeley.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/YdSzlbguFLn3HC7HPuCryG6imks>
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 10:13:39 -0000


On 20/05/2015 10:50, Erik Wilde wrote:
> 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:
>>      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.
>
> 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.

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