- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 6 Feb 2013 08:56:45 +1100
- To: James M Snell <jasnell@gmail.com>
- Cc: Roberto Peon <grmocg@gmail.com>, Eliot Lear <lear@cisco.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
... and looking at Browser Hints (or at least the cut-down revision that I haven't submitted yet), there's not an obvious win (yet). How about we punt on this aspect of the record for now? Maybe leave an opaque blob in the record for (potential) later use? Cheers, On 06/02/2013, at 8:33 AM, James M Snell <jasnell@gmail.com> wrote: > I suspect that several of the settings (compression state, flow control, etc) are simply going to be too dynamic for us to rely on DNS. > > > On Tue, Feb 5, 2013 at 1:17 PM, Roberto Peon <grmocg@gmail.com> wrote: > It will in certain use-cases, e.g. restarting a browser with many open tabs, using a webapp or native application accessing a remote site, or when a service is experiencing heavy load (it may decrease the max compression state size), etc. > -=R > > > On Tue, Feb 5, 2013 at 1:14 PM, Eliot Lear <lear@cisco.com> wrote: > > On 2/5/13 10:06 PM, Roberto Peon wrote: >> I don't remember BDP being one of these, though we did have discussion that talked about BDP in relation to some of the settings. >> These were more along the lines of max-concurrent-streams, max-compressor-state-size, and various other HTTP/2 specific settings that the client should know about/respect. > > Ok, next question: given that we're mandating a settings frame as part of connection initialization (at least I think we agreed on that), does putting this stuff in DNS save anything? > > Eliot > > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 5 February 2013 21:57:16 UTC