[Top] [All Lists]

Re: draft-housley-binarytime-00.txt

2004-09-01 10:32:33


>The document states the rationale.  No conversion to operating system
>representation and it is smaller.  In what way do you find it limiting?

It doesn't go beyond 2038, whereas UTCTime at least goes to 2050.

Not so. A 4-octet value takes us to 2038. After that a 5-octet value is needed. Many operating systems already use a 64-bit value internally.

The proposal isn't so much limiting as... bizarre.  The ASN.1 time formats
have been around forever. everything supports them, and this proposal is for a
format that isn't even as "flexible" as the not-very-flexible UTCTime.  What
real problem is this addressing?  Why a time_t?  Why not a 64-bit time to keep
the Java guys happy?  Or the Windows nanoseconds-since-1600 time?  Or the
Macintosh seconds-since 1904?  You could make it a choice, so no-one would
feel left out, with at least one of the choices being an identified-by-OID
value so everyone could add their own favourite oddball format...

Any of these is possible, but a choice defeats the whole point, which is to avoid complex conversion.