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

Re: Transient content negotiation

From: Larry Masinter <masinter@parc.xerox.com>
Date: Fri, 20 Jun 1997 03:56:42 PDT
Message-Id: <33AA61EA.297A@parc.xerox.com>
To: Graham Klyne <GK@acm.org>
Cc: http-wg@cuckoo.hpl.hp.com, ietf-fax@imc.org
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3558
>  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).

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

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

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.


response to a request 
Received on Friday, 20 June 1997 16:04:05 UTC

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