Draft: draft-ietf-acme-acme

Commentary: Also fix an example date and fix an RFC reference to not be redundant . 
 Merging based on manual review , since CircleCI for PRs seems to be busted .
Paragraph (version A):
The order object returned by the server represents a promise that if
the client fulfills the server's requirements before the "expires"
time, then the server will issue the requested certificate.  In the
order object, any authorization referenced in the "authorizations"
array whose status is "pending" represents an authorization
transaction that the client must complete before the server will
issue the certificate (see identifier-authorization).  If the client
fails to complete the required actions before the "expires" time,
then the server SHOULD change the status of the order to "invalid"
and MAY delete the application resource.
Paragraph (version A):
The server MUST issue the requested certificate and update the order
resource with a URL for the certificate as soon as the client has
fulfilled the server's requirements.  If the client has already
satisfied the server's requirements at the time of this request
(e.g., by obtaining authorization for all of the identifiers in the
certificate in previous transactions), then the server MUST
proactively issue the requested certificate and provide a URL for it
in the "certificate" field of the order.  The server MUST, however,
still list the completed authorizations in the "authorizations"
array.
Paragraph (version B):
The order object returned by the server represents a promise that if
the client fulfills the server's requirements before the "expires"
time, then the server will issue the requested certificate.  In the
order object, any authorization referenced in the "authorizations"
array whose status is "pending" represents an authorization
transaction that the client must complete before the server will
issue the certificate (see identifier-authorization).  If the client
fails to complete the required actions before the "expires" time,
then the server SHOULD change the status of the order to "invalid"
and MAY delete the order resource.
Paragraph (version B):
The server MUST issue the requested certificate and update the order
resource with a URL for the certificate shortly after the client has
fulfilled the server's requirements.  If the client has already
satisfied the server's requirements at the time of this request
(e.g., by obtaining authorization for all of the identifiers in the
certificate in previous transactions), then the server MUST
proactively issue the requested certificate and provide a URL for it
in the "certificate" field of the order.  The server MUST, however,
still list the completed authorizations in the "authorizations"
array.
Paragraph (version A):
The order process described above presumes that authorization objects
are created reactively, in response to an application for issuance.
Some servers may also wish to enable clients to obtain authorization
for an identifier proactively, outside of the context of a specific
issuance.  For example, a client hosting virtual servers for a
collection of names might wish to obtain authorization before any
servers are created, and only create a certificate when a server
starts up.
Paragraph (version B):
The order process described above presumes that authorization objects
are created reactively, in response to a certificate order.  Some
servers may also wish to enable clients to obtain authorization for
an identifier proactively, outside of the context of a specific
issuance.  For example, a client hosting virtual servers for a
collection of names might wish to obtain authorization before any
servers are created, and only create a certificate when a server
starts up.
Paragraph (version A):
One of the revocation reasonCodes defined in RFC 5280 RFC5280
Section 5.3.1 to be used when generating OCSP responses and CRLs.
If this field is not set the server SHOULD use the unspecified (0)
reasonCode value when generating OCSP responses and CRLs.  The
server MAY disallow a subset of reasonCodes from being used by the
user.
Paragraph (version B):
One of the revocation reasonCodes defined in RFC5280 Section 5.3.1
to be used when generating OCSP responses and CRLs.  If this field
is not set the server SHOULD use the unspecified (0) reasonCode
value when generating OCSP responses and CRLs.  The server MAY
disallow a subset of reasonCodes from being used by the user.