On 12/25/22 00:23, John C Klensin wrote:
Finally, while it is probably less important than those above, another issue has been raised and not addressed in the current draft (draft-billon-expires-08). It is related to the inherent ambiguity of future dates and times that are not explicitly defined to be in UTC. For future dates, that ambiguity is not only about the difficulty of inferring whether "+0000" (or, for that matter, "-0000") means "UTC", "a local time zone with a zero offset from UTC", or "just guessing; no time zone information was really available", but about what time zone a particular location will observing at some point in the future. I can think of several fairly easy ways to get around the problem, including being specific about those options and supplying more locale information, suggesting (or requiring) that expirations not be specified to more precision than dates, or clearly identifying the problem as one of concern. Ignoring it entirely does not seem to me to be good enough.
If other concerns about the document could be remedied (doubtful, but I did say IF), the ambiguity about time zones could presumably be fixed simply by saying that time zones in Expires: fields MUST be of the form -HHMM or +HHMM, with -0000 being preferred, in all cases being interpreted as an hours and minutes offset west (if "-") or east (if "+") from GMT.
Of course none of this is likely to be critical unless Expires is actually used to delete messages, which is where many of the hazards associated with this proposal lie. And even if it is used in that way with the recipient's explicit consent, the recipient might be wise to wait some delta-t (say 24-48 hours) before actually effecting message deletion, to accommodate various kinds of inconsistency between clocks and time zone interpretations.
Keith -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
