rfc9773v2.txt		rfc9773.txt
	skipping to change at line 267 ¶		skipping to change at line 267 ¶
	header and return to Step 1.		header and return to Step 1.
	In all cases, renewal attempts are subject to the client's existing		In all cases, renewal attempts are subject to the client's existing
	error backoff and retry intervals.		error backoff and retry intervals.
	In particular, cron-based clients may find they need to increase		In particular, cron-based clients may find they need to increase
	their run frequency to check ARI more frequently. Those clients will		their run frequency to check ARI more frequently. Those clients will
	need to store information about failures so that increasing their run		need to store information about failures so that increasing their run
	frequency doesn't lead to retrying failures without proper backoff.		frequency doesn't lead to retrying failures without proper backoff.
	Typical information stored should include: number of failures for a		Typical information stored should include: number of failures for a
	given order (defined by the set of names on the order) and time of		given order (defined by the set of identifiers on the order) and time
	the most recent failure.		of the most recent failure.
	A RenewalInfo object in which the end timestamp equals or precedes		A RenewalInfo object in which the end timestamp equals or precedes
	the start timestamp is invalid. Servers MUST NOT serve such a		the start timestamp is invalid. Servers MUST NOT serve such a
	response, and clients MUST treat one as though they failed to receive		response, and clients MUST treat one as though they failed to receive
	any response from the server (e.g., retry at an appropriate interval,		any response from the server (e.g., retry at an appropriate interval,
	renew on a fallback schedule, etc.).		renew on a fallback schedule, etc.).
	4.3. Schedule for Checking the RenewalInfo Resource		4.3. Schedule for Checking the RenewalInfo Resource
	Clients SHOULD fetch a certificate's RenewalInfo immediately after		Clients SHOULD fetch a certificate's RenewalInfo immediately after
	skipping to change at line 353 ¶		skipping to change at line 353 ¶
	5. Extensions to the Order Object		5. Extensions to the Order Object
	In order to convey information regarding which certificate requests		In order to convey information regarding which certificate requests
	represent renewals of previous certificates, a new field is added to		represent renewals of previous certificates, a new field is added to
	the Order object:		the Order object:
	replaces (string, optional):		replaces (string, optional):
	A string uniquely identifying a previously issued certificate that		A string uniquely identifying a previously issued certificate that
	this order is intended to replace. This unique identifier is		this order is intended to replace. This unique identifier is
	constructed in the same way as the path component for GET requests		constructed in the same way as the path component for GET requests
	described above.		described in Section 4.1.
	Clients SHOULD include this field in newOrder requests if there is a		Clients SHOULD include this field in newOrder requests if there is a
	clear predecessor certificate, as is the case for most certificate		clear predecessor certificate, as is the case for most certificate
	renewals. Clients SHOULD NOT include this field if the ACME server		renewals. Clients SHOULD NOT include this field if the ACME server
	has not indicated that it supports this protocol by advertising the		has not indicated that it supports this protocol by advertising the
	renewalInfo resource in its Directory.		renewalInfo resource in its Directory.
	POST /new-order HTTP/1.1		POST /new-order HTTP/1.1
	Host: acme.example.com		Host: acme.example.com
	Content-Type: application/jose+json		Content-Type: application/jose+json
End of changes. 2 change blocks.
	3 lines changed or deleted		3 lines changed or added
This html diff was produced by rfcdiff 1.48.