Re: [Acme] Post-IETF-96 PRs

[Ron <[e-mail]>]

On Mon, Aug 08, 2016 at 09:53:07AM -0700, Richard Barnes wrote:
> On Sun, Aug 7, 2016 at 8:29 PM, Martin Thomson <[e-mail]>
> wrote:
> 
> > On 8 August 2016 at 12:39, Richard Barnes <[e-mail]> 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.