Subject: [Acme] Camel vs. kebab-case

From: Sophie Herold <[email-masked]>
Date: Fri, 1 Dec 2017 13:06:13 +0100

Hi,

while updating my client implementation I noted that there seems to be
an arbitrary mix in object key naming conventions:

camelCase

- newKey
- keyAuthorization
- notBefore
- notAfter

kebab-case

- (all directory fields)
- terms-of-service-agreed
- only-return-existing
- external-account-binding

In my opinion this makes the mapping of JSON objects to implementation
language objects/types unnecessarily complicated. I don't know if it is
to late to do something about that.

Best,
Sophie

---

From: Richard Barnes <[email-masked]>
Date: Fri, 1 Dec 2017 08:42:33 -0500

Good observation.  I would be OK moving everything to camelCase [1], since
it seems like that's a more natural fit for programming language bindings.

This also seems like a less disruptive change than some other things we've
been doing lately (finalization).  At best, it's a string change; at worst,
some variable renaming.

Want to submit a PR?

[1] I had not heard "kebab-case" before!  It seems like there should be
extra "-" characters on the ends, like "--new-order--" :)

On Fri, Dec 1, 2017 at 7:06 AM, Sophie Herold <[email-masked]>
wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Sophie Herold <[email-masked]>
Date: Fri, 1 Dec 2017 18:41:14 +0100

Hi,

PR is here

https://github.com/ietf-wg-acme/acme/pull/362

PR text:

> Using camelCase like @bifurcation suggested. There does not seem to be standard among RFCs containing JSON. JWE uses snake_case, but I don't see a reason why the payload should use the same convention.
> 
> - Renamed sub-problems to subproblems since this spelling seems to be more common.
> - Only changed the parts which refer to the keys. Phrases like "new-account request" are unchanged.
> - Changes done via a script. I can resubmit the PR with a different convention if required.

Best,
Sophie

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 1 Dec 2017 11:34:52 -0800

Thanks for pointing this out!

> - 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.

---

From: Sophie Herold <[email-masked]>
Date: Fri, 1 Dec 2017 20:51:43 +0100

I have posted a similar PR for kebab-case

https://github.com/ietf-wg-acme/acme/pull/363

Best,
Sophie

> You forgot to include the field names in the directory object