RE: SETTINGS_HEADER_TABLE_SIZE and ACK

We should definitely clarify this further in the spec, since it is causing
confusion.

How about an implementation considerations section where we talk about how
implementations might leverage the spec in various scenarios?
On Oct 18, 2013 9:06 AM, "RUELLAN Herve" <Herve.Ruellan@crf.canon.fr> wrote:

> The sender can use only a part of the header table.
> For example, with a SETTINGS_HEADER_TABLE_SIZE of 4k, it may use only 2k
> for storing entries.
> The receiver will have a 4k table, storing more entries than the sender.
> These entries stored only by the receiver are not a problem, as the sender
> will never refer to them, but only to those it has in its table.
> There is a difficulty to access the entries from the static table: to know
> the index of the first entry in the static table, the sender needs to know
> how many entries are present in the whole table of the receiver. It can
> manage this by tracking the size of the entries in the part it doesn't use:
> this allows it to evict entries from the table as would the receiver, and
> therefore to know how many entries are in the header table.
>
>
> Hervé.
>
> > -----Original Message-----
> > From: Tatsuhiro Tsujikawa [mailto:tatsuhiro.t@gmail.com]
> > Sent: vendredi 18 octobre 2013 14:31
> > To: ietf-http-wg@w3.org
> > Subject: SETTINGS_HEADER_TABLE_SIZE and ACK
> >
> > SETTINGS_HEADER_TABLE_SIZE is used to inform the size of header table to
> > the other endpoint. Since the size of header table of the decoder side
> has to
> > be matched to the one in the encoder side (otherwise, header table
> out-of-
> > sync on eviction or out-of-bound index), the received peer may not want
> to
> > accept the larger buffer size due to whatever reason (e.g., resource
> > constraints or variable buffer size is not implemented, etc).
> >
> > The HPACK-03 has a text to allow the receiver to choose smaller values
> in the
> > acknowledgement, but now SETTINGS with ACK flags must not have any
> > settings value, the peer is forced to accept the offer.
> >
> > The SETTINGS_HEADER_TABLE_SIZE is special among the other settings. The
> > others affect the receiver's capability, but it can regulate itself not
> to use
> > more resources it wants (e.g., SETTINGS_MAX_CONCURRENT_STREAMS is
> > informed as 500, but the receiver only uses 100). For
> > SETTINGS_HEADER_TABLE_SIZE, there is no way but to just obey the
> > informed value.
> >
> > Best regards,
> > Tatsuhiro Tsujikawa
>
>
>