[Date Prev][Date Next]
Kurt Zeilenga schrieb:
> On May 1, 2010, at 12:31 PM, firstname.lastname@example.org wrote:
>> The patch can be downloaded here:
>> - removed extensible matching rules strictly associated with
>> dedicated syntaxes
>> - added two universal matching rules instead:
>> - nowMach (equality matching rule)
>> - nowOrdering (ordering matching rule)
>> - these two rules also support extensible match filters
> Your comments imply these rules could be used as attribute type
> equality and ordering rules.
In general my intention is neither to violate X.501 nor changing the
ASN.1 Generalized Time syntax.
Instead the introduction of a compatible/similar/derived attribute value
syntax (e.g. generalizedTime') which supports matching against
client-side known time-stamps *and* server-relative time-stamps (like
NOW or NOW-1Y3M... or X.680 period formats) seems to be fine for me.
In the following generalizedTime' is such a kind of a (very) similar
syntax to the well-defined generalizedTime.
Regarding the EQ/ORD matching rule applicability:
The attribute type is generalizedTime' and the assertion value is for
example NOW which server-internally implicitly also represents a (at
least some kind of possibly not ITU specified?) generalizedTime' conform
NOW is the at client side unknown current time of the server in
generalizedTime'. What's your suggestion regarding a possible solution
on how to support EQ and ORD matching of attribute values compared to
the server side current time?
> I don't believe the met the
> requirements (see X.501) to be used in that manner. That is, they
> only make sense as extensible matching rules.
I really would like to try to understand your concerns. Could you please
give me some links to chapters/sections in X.501 where I can find more
details. Note: I've currently only access to the standard of the year 2006.
The class is generalizedTime' and during EQ/ORD matching two instances
of generalizedTime' are compared:
1. Attribute value of an entry (generalizedTime')
2. Assertion value aka expanded-NOW (generalizedTime')
>> To publish a correct server current time time-stamp value within Root-DSE:
>> - apply the bugfix from ITS#6541
>> - and use -DCTM_G_DIFFERENTIAL_SERVERTIME
> #ifdef's should, IMO, be generally avoided.
it will be removed as soon as the above mentioned bug is fixed in HEAD
>> To extend generalizedTime attribute types to also support "NOW" as
>> assertion value:
>> - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION
> The generalized time syntax is not ours to alter. Introduction of
> such a change would, it seem, lead to interoperability problems.
In my opinion the chosen name for the #ifdef is more than obvious.
Additionally the related comment in the patch's source already say's
that this "extension" is more a violation than an extension.
That's why the #ifdef currently is and probably stays in action (or will
be removed) in the future. As a side-effect this #ifdef could possibly
invoke some disussions... ;-)
It's probably worth to discuss this (violation) in more detail to
provide a solution in regard to a broader applicability of this matching
feature in LDAP. Broader/easier usage/readbility is also the background
I've decided to skip the extensible matching rules and introduce EQ and
E.g. Clients that are connecting to a server that announces the
supportedFeature "current time matching" could make notice of that and
also support "NOW" as assertion value for createTimestamp and so on...
(I've not very well thought about that in detail, yet).
You are right, it's just a work in progress and you are very welcome to
join the discussion on ldapext.