Re: (ITS#6247)

[daniel@pluta.biz]

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.