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
