Re: Removing dropped entry from ref set

The responsibility is on the encoder. There's no room for decision on the
decoding side. The encoder could even encode it as a literal etc.

On Monday, September 23, 2013, Mike Bishop wrote:

>  Yes, that’s a reasonable interpretation.  While the spec could be
> clearer, I think that’s the correct reading.  That still leaves open the
> question about correct behavior, though.  You said “You'll need to take the
> appropriate action when an entry in the reference set gets dropped, which
> is most likely explicitly emitting it before it gets dropped.”  Is this
> appropriate action on the part of the compressor, or the decompressor?
>
>  If the compressor, what action is that -- does it need to notice that an
> entry it cares about is going to be dropped and immediately encode two
> indexed references to it, forcing it to be emitted before it’s dropped?  Or
> is it an appropriate action on the decompressor’s part, which means the
> compressor needs to ensure that nothing in the reference set it wishes to
> remove falls off the list before it gets removed?
>
>  Sent from Windows Mail
>
>   *From:* Fred Akalin <javascript:_e({}, 'cvml', 'akalin@google.com');>
> *Sent:* ‎Monday‎, ‎September‎ ‎23‎, ‎2013 ‎1‎:‎51‎ ‎PM
> *To:* Mike Bishop <javascript:_e({}, 'cvml',
> 'Michael.Bishop@microsoft.com');>
> *Cc:* ietf-http-wg@w3.org <javascript:_e({}, 'cvml',
> 'ietf-http-wg@w3.org');>
>
>   On Mon, Sep 23, 2013 at 1:37 PM, Mike Bishop <
> Michael.Bishop@microsoft.com> wrote:
>
>  Found a corner case that I’m not sure HPACK handles, or if it does I’m
> not finding it and we might want to clarify….
>
>  Sequence of events:
>
>    - Header X is present in reference set and header table.
>    - Some other addition to the header table causes header X to be
>    dropped.  (This could be a header that causes X to be dropped, or a
>    substitution operation that replaces X.)
>
>
>    - Now the compressor wishes to remove X from the reference set.  How
>    does it do so?
>
>
>  Per 3.2.1, the only operation that has the effect of removing an entry
> from the reference set is an indexed representation of a header already in
> the reference set.  But you can’t send the indexed representation of a
> header no longer in the header table.
>
>
>  From 3.1.3: "A reference set is defined as an unordered set of references
> to entries of the header table." I interpret this to mean that when an
> entry is removed from the header table, it's removed from the reference set
> also.
>
>
>   To address it, we could say:
>
>    -  *Replacing X with another entry in the header table also replaces X
>    in the reference set.*  This makes perfect sense, but needs to be
>    stated.
>    -  *Dropping X from the header table also drops it from the reference
>    set.*  This is more problematic, because the compressor can’t just
>    pass over headers it wants to communicate which are already in the
>    reference set.  Instead, it needs to leave them until the end, then check
>    if they’re all still in the reference set.  If not, it needs to take
>    another action to emit one or more, then check t
>
>