RE: #445: Transfer-codings

See my comments in-line below...

On Friday,04 April 2014 04:39, Matthew Kerwin wrote:
>
> Encoding: A 16 bit identifier which describes the encoding ...

I agree with what others have said - 16 bits is overkill.  I suggest one byte.

>
> SETTINGS_ACCEPT_DATA_ENCODING (5): ...
>
> The Value field is further divided into two sub-fields, an unsigned 16 bit encoding
> identifier and an unsigned 16-bit rank.
>


> On Friday,04 April 2014 06:34, Martin Thomson wrote (emphasis added):

>>  Settings have a single value. ... you will need to explain how values are processed,

>>  and how an implementation is able to limit the storage it dedicates to storage of this new setting.

I still think you didn't catch Martin's point. Theoretically a client has to store 64K x 4B of SETTINGS_ACCEPT_DATA_ENCODING values.

I suggest a simpler approach.  Only allow a single value sub-divided into 4 bytes to announce support for up to 4 distinct encodings.  A new value received for this setting replaces the current setting.  This would allow the setting to remain a single 32-bit value. I also suggest you ditch the rank. The endpoint generating the compression should be allowed to decide the best compression scheme, if any, given the context.

In other words, I would suggest something like...

<<<<<<<
 The Value field is further divided into four sub-fields, each representing
 an unsigned 8 bit encoding identifier.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Encoding1 (8) | Encoding2 (8) | Encoding3 (8) | Encoding4 (8) |
  +-------------------------------+-------------------------------+

An endpoint may advertise support for up to four encodings at any
given time. Sending a new value for SETTINGS_ACCEPT_DATA_ENCODING
replaces the previous value. An encoding value of 0 means "unused".
>>>>>>>

(If you really wanted to keep the concept of rank, you could use the ordering of the four bytes as the rank.)

If an endpoint decides mid-connection they don't want to support compression any more for whatever reason (e.g. under heavy CPU load), it simply has to send a NULL value for this setting.


-keith


This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.