Kurt Zeilenga schrieb:

On May 1, 2010, at 12:31 PM, daniel@pluta.biz wrote:

...

The patch can be downloaded here: ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch

Changes:

• 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 assertion value:

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 ORD instead. 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.