On Thu, Apr 13, 2006 at 11:41:52PM -0400, Tony Hansen allegedly wrote:
Minor nit: #5 doesn't apply because it's explicitly required to use up
to 40 bits.
I'm actually a bit surprised that this is even talked about. As a
decimal representation, the relevance to 32bit unsigned integers is a
little tenuous.
It might be my bias as much of what I do doesn't fit into 32bits, but
at most I would expect non-normative text alerting implementors to the
fact that conversion to binary should be cognizant of the fact that
the value will likely exceed the capacity of a 32bit int.
In short, anyone who is still thinking 32bit in 2006 is somewhat
anti-diluvian.
5) Delete x=, time in seconds since 1970s invites 32 bit Y2K type issues
Well, the days may be numbered for x= anyway, but if some sort of
timestamp is needed in the future, then maybe make it millisecs or
decisecs since 1970 and force the >32bit issue?
Alternatively, if it's a fuzzy value, make it fractional: x=12345.678
to similarly force the issue.
Apropos the subject line; I think that's precisely the problem with x=
and t=. They're a solution looking for a problem as is obvious from
the variety of interpretations on how they *might* be used. Defining
the problem first should be apple pie.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html