W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: Transient content negotiation

From: Graham Klyne <GK@acm.org>
Date: Sun, 22 Jun 1997 23:23:41 +0100
Message-Id: <>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg@cuckoo.hpl.hp.com, ietf-fax@imc.org
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3562
At 03:56 AM 6/20/97 PDT, Larry Masinter wrote:
>>  But I believe that the distinction between 'online' messaging
>> (like HTTP) and s/f messaging is more one of degree than fundamental
>> difference, and mechanisms good for one may be applicable to the other.
>I'm warming up to the idea of using HTTP-like caching for
>caching recipient capabilities.
>A response can identify the request which caused it
>to be generated, either by directly including it (for
>small requests, like GET or CAPS) or by reference (e.g.,
>by link or message-ID).

I would be more inclined to include or reference the *attributes* of the
request rather than a specific instance of a request.  As I understand it,
the Holtman/Mutz proposal does this.

> A response must contain the date
>of the response, and should also contain a time when the 
>response is likely to become stale.

Ditto request?

>Recipient capabilities/preferences/characteristics 
>are treated as if they are a response to a request for the

I take that as a "yes" to the above question.

All of this supersedes my earlier suggestion of a 'transient' flag for
negotiable attributes.  A 'max-age'/'TTL' or equivalent is much more flexible.

>So you can use HTTP-like caching for saving recipient capabilities.
>If the information has expired, you can ask for it again,
>or you can, if you must, use stale data, but report that
>the data is stale. The sender of a fax confronted with a known-stale
>signal of recipient capabilities can choose to send any of
>a number of items: alternatives, least common denominator, ask
>for capabilities again, or use the stale information and hope
>for the best.

And the presence of a time-to-live or equivalent in a capability list can
provide intermediate systems with a basis for deciding whether the values
are (still) 'authoritative'.


Graham Klyne
Received on Sunday, 22 June 1997 15:27:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC