I've raised a small PR[1] which should cover this, however I think there
is some other considerations that may belong in a separate PR:
* What happens when a service receives a token with a timestamp which
points to a time in the future? Should this just be accepted, or treated
as an error?
* Is there a way we can remove the requirement for having time_t as the
timestamp value and instead use a linear incrementing value relative to
the server and service that is independent of other timescales?
- J
1: https://github.com/quicwg/load-balancers/pull/100
On 11-03-2021 22:48, Watson Ladd wrote:
Dear QUIC WG,
First a moment of unforgivable pedantry. Universal time is
unfortunately not the right name for UTC, which is slightly different.
It could also mean UT1 or some other variations It's also not clear
what the future of computer timekeeping is and I know several places
don't synchronize to UTC internally. I think the best way to handle
this is to say something like "synchronized" and leave open as to
exactly how that is done.
I agree with the comments that there are too many options and should
be fewer. Other then that I didn't see any problems but I'm probably
too sleepy right now to spot them.
Sincerely,
Watson Ladd
