Re: Transient content negotiation

At 09:31 PM 6/20/97 +0200, Koen Holtman wrote:
>Graham Klyne:
>>
>[...]
>>This suggests to me that it might be desirable to tag negotiable features
>>as 'transient' as a warning to intermediate systems to avoid caching these
>>(negotiable feature) values in an attempt to 'optimize' future
>>negotiations.
>
>Here is how caching of negotiation metadata is handled in HTTP
>transparent content negotiation:
>
> - information about the feature set of the browser, if it is sent
>   over the wire at all, is never cached (at least not under HTTP/1.1,
>   a future protocol extension may provide sticky header or
>   dictionary mechanisms which could cache such information for a
>   short while).

I grant that there is currently no mechanism for caching negotiable
features (negotiation metadata) of HTTP clients, but I am trying to suggest
a feature which might protect against this possibility in the future, or in
different protocols.  I am motivated more by possibilities which might
arise in a 'push' messaging system where I suspect the opportunities for
such cacheing might be greater.

But, even considering HTTP, if content negotiation becomes popular and
frequently used, it is quite possible to envisage situations where the
volume of negotiation metadata becomes quite large, and cacheing
mechansisms for this information might be desirable.  Especially (I
imagine) for a proxy server which might realistically cache negotiation
featutes for the clients which use it.

I observe that the original HTTP (as I understand it) did not have any
provision for cache control headers which in current times would be
regarded as essential.

So, my question is this: even if there is no current requirement for it in
HTTP, should a 'transient' attribute be recognized for negotiation metadata
so that future developments don't get spoiled by ad-hoc "cache-busting"
techniques?

Based on your earlier response to my comments on
'draft-ietf-http-negotiation-02.txt', I believe that the
'feature-extension' option in that draft might be used to convey such
information.

On the matter of cacheing server-side features subject to max-age headers,
I note that this is very specific to HTTP.  Which, you may legitimately
say, is fine.  I am motivated here by an interest in developing a
negotiation framework which is not unduly tied to any single protocol.

>So there is no cache control at the level of individual features.  I
>don't know whether such fine-grained caching would be useful in fax
>applications.

Neither do I :-)  Such fine-grain control was not my primary concern.

GK.
---

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

Received on Sunday, 22 June 1997 15:26:54 UTC