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 On 01/12/17 14:42, Richard Barnes wrote: > 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 <sophie_her...@hemio.de> > wrote: > >> 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 >> >> _______________________________________________ >> 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
