Re: Editorial Issue: Persisted Settings... when does the client need to return them?

The AP couldn't set anything w.r.t settings unless you connect to it
specifically and it has a cert that your browser trusts, at least assuming
the model where settings are persisted only for sessions using verified
certs (like what is done with SPDY today).
And then the browser (at least Chrome) will forget the setting upon the
change of network.
And of course, one could just set a cookie instead of doing SETTINGS, but
then we announce it everyone, even when not useful. bleh.

We'll talk about it later anyway.


On Fri, Apr 26, 2013 at 8:39 PM, James M Snell <jasnell@gmail.com> wrote:

> To be honest, the whole persistent settings thing gives me the
> willies, particularly given that SETTINGS as defined currently are
> generally specific to individual connections. If I'm on the road and
> on my phone connected temporarily to a free wifi access point, I don't
> necessarily want that access point being able to tell my phone to
> persistently store some piece of data that will never be used anywhere
> else... Not to mention the inherent privacy concerns...
>
> On Fri, Apr 26, 2013 at 8:06 PM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > Given that persisted settings are at risk, I think that we can defer
> > addressing this one.
> >
> > (I'd say that once is enough and that persisted settings need only be
> > returned at connection establishment time, but that's not the only
> > thing we need to address with persistent settings, I think.)
> >
> > On 26 April 2013 14:28, James M Snell <jasnell@gmail.com> wrote:
> >> One bit that's not clear in the current draft...
> >>
> >> When the server asks the client to persist a setting, is the client
> >> required to return that setting in EVERY subsequent SETTINGS frame it
> >> sends to the server until the setting is cleared or is it only
> >> required to send the persisted settings once when a new session is
> >> established (i.e. in the client session header?)
> >>
>
>