Without looking at them in context that seem pretty reasonable. Happy to review a PR.
On Wed, Aug 8, 2018, 21:03 Sean Turner <[email protected]> wrote: > These are all minor so I didn’t send them to [email protected]. Also, once > we settle on whether these are okay, I can submit a PR if you’d like (or > not if that’ll be faster). > > 0) abstract > > r/certificate authorities/certification authorities > > and then you can: > > r/certification authority (CA)/CA > > 1) s1 > > r/certificate authorities/certification authorities (CAs) > r/certificate authorities/CAs > r/CA web page/CA’s web page > r/confusion/frustration and confusion > r/infrastructural/infrastructure (?) > r/PKIX authentication/PKIX-based authentication (?) > r/WebPKI/Web PKI (? or should it go: r/Web PKI/WebPKI) > > 2) s3 > > r/TLS certificates/certificates for TLS > > 3) s4 > > r/in that certificate in order for > the CA to sign the requested certificate./ > in that request certificate in order for > the CA to issue the requested certificate. > > 4) s6.1 > > Add reference for Access-Control-Allow-Origin header. > > 4) s6.2 > > r/For newAccount requests, and for revokeCert requests authenticated by > certificate key, there MUST be a "jwk" field./ > For newAccount requests, and for revokeCert requests authenticated by > certified keys, there MUST be a "jwk" field. > > 5) s6.4 - since the previous section was JWS headers maybe: > > r/the Replay-Nonce header/the HTTP Replay-Nonce header > > 6) s6.4.1 - I assume it’s ABNF there, but based on RFC 7231 I guess it’s > worth a reference: > New header field values ***typically*** have their syntax defined using > ABNF ([RFC5234]) … > So maybe add the following right before the ABNF: > > The ABNF [RFC5234] for the Replay-Nonce header field follows: > > 7) s6.5: need references? > > r/"Retry-After” header/"Retry-After" header [RFC7231] > r/"Link” header/"Link" header [RFC8288] > > 8) s6.6: maybe the reference for the ACME URN namespace should be to > section 9.6? > > r/(within the > "urn:ietf:params:acme:error:" namespace):/ > (within the ACME URN namespace > "urn:ietf:params:acme:error:"): > > r/ACME URN [RFC3553] namespace/ACME URN namespace (see Section 9.6) > > 9) s7.1: add reference for REST? > > r/REST/REST [REST] > > [REST] Fielding, R., "Architectural Styles and the Design of > Network-based Software Architectures", 2000, > http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. > > 10) s7.1.1: Should the "URL in values” in the table match the examples > later in the section? i.e.,: > > r/New nonce/new-nonce > r/New account/new-account > > and so on? > > 11) s7.4.2: add reference for Accept Header? > > r/an Accept header/an Accept header {RFC7231] > > 12) s7.4.2: could also point to application/pkcs7-mime for PKCS7 > certs-only messages. > > 13) s7.6: If the revocation request fails, which error is returned? THe > draft often > > 14) s9.1: Was there any thought given to an optional parameter indicating > how many certs would be in the chain? > > 15) s9.3: Should the reference be: [this-RFC, Section 6.4.1] to match some > of the other entries in the registry? Or at least refer to [this-RFC]? > > Cheers, > > spt > > > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
