On 5 October 2012 10:42, James M Snell <jasnell@xxxxxxxxx> wrote: > I could drop the Date header recommendation altogether and stress in the > text that good clock synchronization and predictable latency is required for > the wait preference to be used effectively. The feature is useful, I agree. The problem is that - as defined - the server needs to guess something about the times on the client in order to implement this reliably. Relying on clock synchronization is not realistic. Even in controlled environments, errors are commonplace. Even the simple case shows a problem: a: client sends request b: server receives request c: time passes d: server responds to request e: client receives response You require that the time be a measure of a->e. The server has no way to determine what that time is. An alternative would be to make the requirement apply to b->d. That is something that the server has direct control over. The client then gains a little extra work, but at least they are in a position to measure a->b + d->e. In any case, with low or predictable latency, I doubt that the addition of a->b + d->e will have any significant impact on whether the information is useful to the client. Especially given that times are expressed in seconds, not microseconds.