Phill,
I know I promised to shut up, but I'll buy you a beer sometime instead:-)
> 1) Steve proposes that we have a fixed resolution of a second to match
> X.509.
Nope, 'twas for simplicity, nothin' to do with wanting to match X.509.
It just turns out that X.509 has evolved to those settings too.
> I think that tying the protocol to a particular resolution is an
> unnecessary restriction.
IMO we should either fix, or specify a finest-granularity, for the
resolution. Otherwise we get unintended behaviour. I don't mind
which (fixed or finest-grained), but I imagine that all xml parsers
will be able to handle 1s values input to them, hence my suggestion
of fixed.
> 2) Matching the semantics of X.509. I am none too happy with the argument
> that we should match the X.509 semantics because it took so long to get the
> implementations to interoperate.
The interop problems weren't caused by "<" vs. "<=", 'twas mostly to do
with the presence or absence of "00" seconds (hey, isn't that resolution:-)
and repeated en/decode cycles buggering up hashes. Look back at the PKIX
archives or Peter G's style guide [1].
> The X.509 semantics map precisely to the
> NotOnOrAfter semantics by adding a second.
Therefore they're as easy to implement? My point was not that one's harder,
but that gratuitous change is a bad idea. That remains my point.
> It is very easy to get the X.509
> semantics wrong, it is much harder to get notonorafter wrong.
Blatent assertion, no more.
> 3) The UTC issue. I have no problems with stating that all times must be in
> UTC.
If you'd stopped there, we'd be fine!
> I am somewhat less sure as to the best way to manage the timezone
> issue. One way is to state that all times MUST be expressed in GMT, i.e. the
> timezone offset is zero. Another is to allow the use of local timezone
> offsets so that the local and GMT time are both known.
>
> The concern is what to do if an application inserts a local timezone. Should
> it be permissively accepted or definitively rejected. I think that we should
> either insist on GMT and require processors to reject timezone offsets or
> allow explicit to allow numeric timezone offsets. Named timezones are
> obviously right out.
That's not clear to me. Are you saying you want UTC (Z), GMT (same really) or
numeric-offsets from UTC, or unspecified timezones?
Stephen.
[1] http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 881 6716
39 Parkgate Street, fax: +353 1 881 7000
Dublin 8. mailto:
Ireland http://www.baltimore.com
