OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [security-services] the "NotOnOrAfter" issue


> dateTime allows arbitrary sub-second precision and arbitrary 
> timezones 
> expressed as hh:mm offsets from UTC. 
> 
> 
> I suggest subclassing xsd:dateTime to: disallow fractional 
> seconds and 
> timezones other than UTC. 
> 

Rich, I think we just cross-posted on this, so let me ask you this:

Since dateTime does uniquely identify a time what is the value of
requiring dateTime to be expressed in strict UTC?

It seems to me that the only benefit here is that SAML-processors need a
little less code (i.e. the code that transforms a local+UTC offset into
UTC).

That argument strikes me as pretty soft, since it seems to me that the
majority of systems won't be coding from a scratch--they'll be built on
top of some level of Schema-aware libraries that should handle this.

I do agree with Stephen that we need to make some explicit statement
about fractional seconds, but I don't think we need to disallow them.
Adding a note to the effect that all unreported sub-second precision
digits in a given time are zero, with the standard time comparison rules
in effect, should handle any ambiguities without removing any potential
utility in fractional second precision.

C.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC