Thanks for pointing this out! On 12/01/2017 04:06 AM, Sophie Herold wrote: > camelCase > > - newKey > - keyAuthorization > - notBefore > - notAfter > > kebab-case > > - (all directory fields) > - terms-of-service-agreed > - only-return-existing > - external-account-binding
You forgot to include the field names in the directory object, which are currently all kebab case. I think changing those to camelCase would make it dramatically harder for clients to share code between their current implementation and their v2 implementation. So I'm definitely opposed to switching to camelCase. We could in theory switch newKey and keyAuthorization to kebabs, if that's an exhaustive list (nothing currently uses notBefore and notAfter). However, I just finished changing one client so it can support either the old "uri" field in challenges, or the new "url" field, and it was a surprisingly large hassle. I'd rather not impose the additional hassle of dual-classing more field names. Keep in mind that while Let's Encrypt / Boulder is visible, we've heard from a handful of other CAs who have implemented "Certbot compatible" ACME endpoints privately. We should expect that there will be a transition period where most clients will want to support either the older spec version implemented by Certbot / Boulder, OR the final RFC version. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
