The semantics of the Retry-After header only give us half of what we want: it delays clients, but doesn't also tell them to retry as soon after that period is over as they can. We should come up with a mechanism (a polling period in the directory? as its own key, as part of the renewalInfo key, or as part of the meta object? or maybe directly in the renewalInfo response object instead?) to more clearly communicate when we suggest that a client recheck the renewalInfo.
The semantics of the
Retry-Afterheader only give us half of what we want: it delays clients, but doesn't also tell them to retry as soon after that period is over as they can. We should come up with a mechanism (a polling period in the directory? as its own key, as part of the renewalInfo key, or as part of the meta object? or maybe directly in the renewalInfo response object instead?) to more clearly communicate when we suggest that a client recheck the renewalInfo.