>From the view point of Let's Encrypt/Boulder: Our original plan for major specification changes has been to provide multiple versioned API endpoints which implement different verions of ACME. Currently we only provide acme-v01.api.letsencrypt.org which implements an amalgam of the first four drafts (documented here: https://github.com/letsencrypt/boulder/blob/243832822a28e04e46dc26ab3554ac2062731cc6/docs/acme-divergences.md) but given the number of breaking/major flow changes in draft-03 we plan to make a second endpoint available (presumably acme-v02) which will be a strict implementation of the specification once it is finalized.
Assuming, given the recent discussion of entering WGLC, that the specification is in the process of stabilizing and that the largest server side implementer most likely won't implement large portions of the new spec until it is finalized adding fine grained versioning to the protocol seems like overkill. I'm not entirely convinced the specification itself needs to provide a versioning mechanism at all beyond perhaps indicating that if a server chooses to implement an older version of the specification it should do so on a distinct endpoint. On 08/08/2016 07:03 PM, Martin Thomson wrote: > On 9 August 2016 at 02:53, Richard Barnes <r...@ipv.sx> wrote: >> 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. > > Let's not overwork this one, I don't care that much either way on this > point. The suggestion seemed to have a low complexity cost for some > gain. That cost doesn't seem to be as low as first expected > (surprise!). Thus, I'm not willing to spend too much extra effort to > keep this. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
