On Sun, Aug 7, 2016 at 7:28 PM, Martin Thomson <[email protected]> wrote:
> On 7 August 2016 at 03:46, Jacob Hoffman-Andrews <[email protected]> wrote: > >> #162 - Add a protocol version > >> https://github.com/ietf-wg-acme/acme/pull/162 > > > > Still thinking about this one. Seems sound at first glance, but I'm > thinking > > about TLS version intolerance and > > https://www.imperialviolet.org/2016/05/16/agility.html. > > For similar reasons, I think that this change might be a little > overwrought. It's certainly a non-trivial amount of added complexity. > Overwrought, indeed. It certainly felt that way while writing it, but that's where the line of thinking seemed to lead me. Maybe it's worthwhile stepping back and asking what sorts of changes we might want to make, and how those should be done. Within the framework we have right now, you can already add new functionality by adding resources or fields on objects. If you want to require the new functionality, you can add error codes to cleanly fail old clients. And if you want to do something totally different, you can change the directory URL. 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 :) ) --Richard > > Would it be acceptable to have a much simpler scheme that included the > version (a simple string that has to match) in the payload of all > messages? That keeps this as a sanity check that you aren't > transporting things between incompatible versions. The server can > provide new endpoints if it wants to support new (incompatible) > versions. >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
