- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Fri, 4 Apr 2014 15:21:19 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CACweHNDK5V9LvqexBQ9DgKFhk=MKEC_3vMnDa2W-svibERWHsA@mail.gmail.com>
On 4 April 2014 14:34, Martin Thomson <martin.thomson@gmail.com> wrote: > On 3 April 2014 19:39, Matthew Kerwin <matthew@kerwin.net.au> wrote: > > SETTINGS_ACCEPT_DATA_ENCODING (5): Indicates the sender's ability and > > willingness to receive DATA frames that are encoded using the scheme > > identified in the Value. > > Settings have a single value. Is the intent here to change this, or > are you planning to have just a single valid acceptable encoding? > > I'm guessing the former, based on the existence of the rank part here. > In that case 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. > Yes, multiple values. I didn't think it would be necessary to tell implementors how to process or store the values. I guess I could add something to the following effect: Have a table of encodings you are able to transmit, with ranks initialised to 0. When you receive a this setting, if it's for one of the encodings in your table, update the rank in the table from the frame; if it's not, ignore it. You can use your table to help inform your decision of what encoding, if any, to apply to any DATA frames. Does that not count as an implementation detail? -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Friday, 4 April 2014 05:21:47 UTC