Re: Transient content negotiation

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

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

GK.
---

------------
Graham Klyne
GK@ACM.ORG