On Tue, Sep 13, 2016 at 11:56 AM, Jacob Hoffman-Andrews <[email protected]> wrote:
> > > Anything that isn't tested Will be broken. We can't fix that in the > > protocol, but we can fix it by adding tests :) > We can also fix it by deleting unnecessary things, which is the best and > most reliable way to avoid bugs. That's why I think this is the right > approach. > Note that you can synthesize the "TOS-as-bool" case from the "TOS-as-string" case -- the bool just reflects whether the string has the right value. In that sense, having the string there would actually simplify the CA's job. So string or bool is just a question of whether you make the breaking-change case or the non-breaking-change case easier (where breaking == requires re-agreement). If it's a bool, then the server has to go unset it on all the accounts when it makes a breaking change (instead of just changing the string and breaking equality). If it's a string, then the sever has to update the strings whenever it makes a non-breaking change to the URL. Of course, these options are not mutually exclusive. You could have something like a "last agreed" URL field and an "agreement compatible with current TOS" field. Don't really think this is a good idea, just bringing it up :) Net/net, I'm a little sad to lose the "thing you last agreed to" information. But if it's not acceptable to the CA any more anyway, why does it matter? (The client can also keep a copy.) And it does seem like we should optimize for the non-breaking-change case. So I can live with just a bool. --Richard
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
