expires or max-age

[Jxck]

https://github.com/WICG/compression-dictionary-transport/blob/main/README.md?plain=1#L137

expires - Expiration time in seconds for the dictionary.

in Cookie, Cache-Control etc, expire is date format and max-age is time in seconds. so it seems bit strange for me to have time in seconds for expires. how about make it max-age ?

[pmeenan]

I'm getting ready to draft an rfc where I'm assuming we'll bikeshed on the actual names. max-age has a specific connotation as it relates to the current age so it's not an exact match either. Something like ttl for time to live is probably most appropriate.

[Jxck]

for example, ttl=100day and proxy stores it for 80day. when browser will delete it ? in 80 day ? or 20 day ? In cache-control, age header tells 80days passed on proxy, but if it's not depends on cache-control, there are no hint to know it.

in that case, it seems better for me to shorten ttl and control response via cache-control on deployment.

cache-control will also be short time, and fetch new dictionary compressed with old dictionary frequently with content update / deploy codebase etc.

[pmeenan]

The actual serving and caching of the response is expected to still use cache-control. The dictionary ttl is how long the client can expect to be able to use it as a dictionary for. Generally, if the resource is updated frequently you'll want a relatively short ttl to minimize variants in the Vary cache keys but if it is updated very rarely, there is no harm in a long ttl (even beyond the cache control age if you want to use it to update expired versions at the same URL).

If a client tries to use a dictionary that the server-end no longer recognizes, there is no harm either (other than another Vary permutation being stored). The server just sends back the full resource as it would have without the available dictionary.

[pmeenan]

Closing this out since the dictionary-specific expiration has been removed and it now uses the freshness of the dictionary resource itself.