Re: #255 eviction for substitution

On 10/10/2013 5:13 a.m., RUELLAN Herve wrote:
> I understand that some implementations will have a static header table that should not exceed its maximum size, even temporally. That's why I put the "logically" : that makes the spec easier to write and understand, but it's fully possible to optimize the header table handling. For example, an implementation may first make room available for the new entry, then add it to the table, keeping the table size bounded.

Is that not a MUST ? otherwise recipients with restricted table bounds 
who evict-then-substitute would not be strictly in sync with senders who 
substitute-then-evict in all the cases where eviction point overlaps 
with substitution point. It either becomes very long-winded to explain 
the logics around why the substituted entry #0 was not evicted or an 
interoperability nightmare when bad implementations evict the wrong entries.

Amos

Received on Thursday, 10 October 2013 06:23:59 UTC