If we're going to keep "meta" in the Directory object (and I think we
should, at least for "terms-of-service", since otherwise you need to
round-trip sending a failed "reg" request to get it in a Link header),
then we might want to consider changing the JSON to something like:
{
"resources": {
"new-reg": "https://example.com/acme/new-reg";,
"new-authz": "https://example.com/acme/new-authz";,
"new-cert": "https://example.com/acme/new-cert";,
"revoke-cert": "https://example.com/acme/revoke-cert";
},
"meta": {
"terms-of-service": "https://example.com/acme/terms";,
"website": "https://www.example.com/";,
"caa-identities": ["example.com"]
}
}
That way it will always be clear exactly which fields are really
resources (which the first paragraph of 6.2 says all of them are)
and which are some non-resource extension that may be added in
a later revision.
Though if we do that, possibly we can drop "meta" and just make
the fields in it be non-resource parts of the top level object?
Either option would make this a bit more robust for any future
extension to the Directory content without implementations needing
to special case some field names as "not-resources".
Thoughts?
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
