On Mon, Aug 08, 2016 at 09:53:07AM -0700, Richard Barnes wrote: > On Sun, Aug 7, 2016 at 8:29 PM, Martin Thomson <[email protected]> > wrote: > > > On 8 August 2016 at 12:39, Richard Barnes <[email protected]> wrote: > > > So I'm honestly not that convinced that we need versioning at all here. > > > Maybe we could get away with just versioning the directory? (As I think > > the > > > original issue proposed :) ) > > > > > > I believe that it was PHB who requested this originally, the rationale > > being that you might create a new version of the same resource/request > > that looked similar, but had different semantics. Rather than rely on > > having us (in all our possible future incarnations) not doing that, a > > version indicator would make signatures invalid. > > > > If that is a requirement that you accept, then a much simpler scheme > > than the one you wrote up is possible. Versioning the directory isn't > > sufficient to achieve that goal though. The first part of your PR > > would work though: include a version, and require that it be checked. > > > > Looking at the minutes from Berlin... > > "RLB: do we need both server and client versions? MT: sure" > > :) > > I'm not sure we can get away without any server versioning. The server > needs some way to signal support, even if it's only in an error message. > > Again, I'm not totally convinced that semantic mismatches are that big a > deal. The "url" parameter already scopes the signed object to a specific > resource, so the only risk would be if that specific resource accepts > different object formats that are confusable with one another. You need > some signal to disambiguate, but it's not clear to me that having one big > version is the best solution.
FWIW, we did have that situation when the "delete":true flag was added to the -02 "resource":"reg" object - in that Boulder 'successfully' did something quite different by not implementing that flag if a client tried to use it ... But I do agree that sort of thing can be mitigated with some careful thought about whether we can safely ever extend objects like that or not. And if we can't, by implementing a new object or resource that does have the desired semantics. This is JSON, we can trivially rename things in expressive ways if needed. Unlike a bit-starved binary format where you could only spare a few bits for a 'version number' to tell you that the otherwise unlabelled byte 4 still means what you previously thought it did. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
