Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]

[Daniel Pluta <[e-mail]>]

Hi Steven,


Steven Legg wrote:
> Hi Daniel, Daniel Pluta wrote:
>> Hi Steven, Steven Legg wrote:
>>> Hi Daniel, Daniel Pluta wrote:
>>>> Hi Steven, Steven Legg wrote:
>>>>> Hi Daniel, Daniel Pluta wrote:
>>>>>> Hi Steven, Steven Legg wrote:
>>>>>>> Hi Daniel, Daniel Pluta wrote:
>>>>>>>> Hi Steven, Steven Legg wrote:
>>>>>>>>> Daniel Pluta wrote:
>>>>>>>>>> Steven Legg wrote:
>>>>>>>>>>> Daniel Pluta wrote:

>>>> - In my opinion: "NOW" would offer improved readability
>>>
>>> Yes, except that there is an existing assertion syntax that you could
>>> use. It is useful for interoperability with X.500 for each new LDAP
>>> syntax to define its corresponding ASN.1 type. The assertion
>>> syntax for the rules without offset carries no information, which would
>>> naturally correspond to the ASN.1 NULL type. RFC 3687 defines
>>> an LDAP syntax for the NULL type (1.2.36.79672281.1.5.1).
>>
>> Ohh yeah!  :-/
>>
>> Although I understand the idea behind this type and also your 
>> suggestion I'm just not very happy with this syntax only because 
>> there is no ASN.1 definition for a an abstract type like "the current 
>> time" (additionally to the ISO8601 specified common "point in time" 
>> for example). On the other hand: the comparison takes place on server 
>> side so we do not (need to) send any value to be compared which 
>> justifies to indicate this by NULL, e.g. using "(timeAttr=)" as a 
>> filter.
>>
>> Nevertheless I'm not happy with this especially in regard to 
>> usability/readability.
>>
>> Even more, Am I right that a valid filter expression would look like: 
>> (timeAttr=NULL) in case the LDAP string representation is "NULL"? If 
>> yes in my personal opinion I would prefer to use "NOW" instead of 
>> "NULL".
>
> The filter would look like (timeAttr:nowMatch:=NULL).

Correct, but only for attribute types that are using the "ordinary" 
(RFC4517) generalizedTime syntax.


> An equality match filter item applies the equality matching rule of 
> the attribute type
> using an assertion value of the syntax of that matching rule.

To avoid this kind of conflict our draft also has mentioned extra 
attribute type syntaxes (next to the also mentioned assertion syntaxes). 
Possibly this has not become clear in this early version of our document 
because we have not been aware of the 100% exact LDAP terminology - 
sorry for that.

That's the reason we have to clarify our intention and to further 
differentiate in regard to your answer:

You assumed that the timeAttr is of generalizedTime syntax, but the 
above "timeAttr" (from my previous posting) is not of generalizedTime 
syntax (1.3.1....24) but of a new generalizedTime-similar syntax 
(1.3.1...7650....).
This gT-similar syntax allows ordinary generalizedTime formats as well 
as the special time-stamp "NOW/NULL" to be used as an assertion as well 
as an attribute value syntax. Thus it should be possible and allowed (by 
the specs) to offer a EQ- matching rule to support this new type to be 
comparable using EQ matching. In addition this equality matching rule 
would be also applicable as extensible matching rule for ordinary 
generalizedTime attributes.

BTW (please don't shoot me, it's just for demonstration/discussion 
purposes):
Our currently (and soon to be contributed) prototype implementation also 
supports the nowMatch eq-matching in regard to generalizedTime. For sure 
it's absolutely clear to us that this is a harsh violation in regard to 
the current RFC4517. Therefore this undocumented trick currently needs 
to be enabled at compile time using for example 
"-DRFC4517_ASSERTION_SYNTAX_VIOLATION" and  optionally 
"-DRFC4517_ATTRIBUTE_SYNTAX_VIOLATION", too.

I just wanted to mention these two violation as a basis for the 
following philosophical/hypothetical discussion:


<hypothetical_discussion>

DISCLAIMER (again): we are aware of generalizedTime syntax and don't 
intend to violate existing standards at all. We just want to think about 
possible future consequences, demands, add-ons or requirements regarding 
any extension. We are really interested to discuss the honest pros and 
cons related to a might be every day usage:

Based on the commonly accepted usefulness of nowMatch as extensible 
matching rule we also can imagine that many people would probably like 
to use this kind of time-stamp comparison more "naturally" applied on 
generalizedTime syntax attributes (using EQ/ORD-match filters), too. 
Isn't it possibly imaginable that the string "NOW" in some future could 
become just a (specialized but valid) instance of the "generalizedTime" 
class? In fact, and caused by "NOW"'s server side expansion (right 
before) the matching processing "NOW" is already (even today) a 
syntactically correct generalizedTime value (during matching). In that 
case it s/w/could become comparable using equality matching (at least 
during the matching processing itself)...

We know that there is currently no syntax definition available to 
express the (relativistic) current time (aka NOW) in any LDAP related 
base standard (e.g. ISO8601, ITU X.680). Probably it's worth to discuss 
this obviously seeming gap directly with some standardization 
organization, e.g. by starting the discussion at the well-defined and 
standardized "point in time" asking for how to syntactically correct 
express the abstract value of the floating "current point in time" (aka 
NOW).

My main questions into direction of any interested standardization 
organization would be:
- How to express this special (floating) point in time in regard to 
ISO8601 - is there possibly a gap in ISO8601?
- Would it be worth to introduce a specialized syntax token (e.g. "NOW" 
or what ever) which extend the generalizedTime syntax to address the 
first question?
- Is it really a standardization organization's intention that the 
nullValue should be (mis)used to represent the abstract floating current 
(point in) time? If yes, where can I find a source/cite which answers 
this question?

I don't think we two are currently able to answer these questions in the 
correct (standardized) way - all we've found out seems just to be a 
compromise which just represents an limited "LDAP specific temporary 
workaround" that perhaps (mis)uses the nullValue.

</hypothetical_discussion>

> The nowMatch rule is not, and cannot be, the equality matching rule of 
> timeAttr, so
> (timeAttr=NOW) is bogus.

It's not bogus in case timeAttr is of gT-similar syntax. For that reason 
we think the nowMatch matching rule needs to at least:
- support EQ-matching for attribute's of our generalizedTime-similar syntax
- support EXT-matching for generalizedTime syntax attributes

Hopefully now our idea has become more obvious and hopefully it also 
conforms to the directory specification - feedback is greatly appreciated.


Background regarding the EQ matching support:
Next to LDAP search operations our current prototype also supports NULL 
and OFFSET assertion values during add/delete/modify operations. It's 
supported to use this assertion values for example via ldif changes for 
(multi-value) attributes based on our generalizedTime-similar syntax. To 
support multi-value handling an appropriate equality rule has to exist 
and needs to be used. Therefore we would like to see our new gT-similar 
syntax to support EQ-matching using nowMatch to detect already existing 
values in multi-value attributes...

Demo output of a ldapsearch followed by a modification which adds three 
values (const gT-similar time-stamp, NOW, NOW+1sec offset):

1.) SEARCH:
ldap_initialize( <DEFAULT> )
filter: (objectClass=*)
requesting: timeAttr
# extended LDIF
#
# LDAPv3
# base <cn=a,dc=foo,dc=bar> with scope baseObject
# filter: (objectClass=*)
# requesting: timeAttr
#

# a, foo.bar
dn: cn=a,dc=foo,dc=bar
timeAttr: 20100301000000Z

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

2.) MODIFY:
ldap_initialize( <DEFAULT> )
add timeAttr:
        20100301000001Z
        NULL
        0#0#0#0#0#1
modifying entry "cn=a,dc=foo,dc=bar"
modify complete

3.) SEARCH (again):
ldap_initialize( <DEFAULT> )
filter: (objectClass=*)
requesting: timeAttr
# extended LDIF
#
# LDAPv3
# base <cn=a,dc=foo,dc=bar> with scope baseObject
# filter: (objectClass=*)
# requesting: timeAttr
#

# a, foo.bar
dn: cn=a,dc=foo,dc=bar
timeAttr: 20100301000000Z
timeAttr: 20100301000001Z
timeAttr: 20091224193010Z
timeAttr: 20091224193011Z

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

Please don't wonder about the year 2009 time-stamps: we use the "fake 
time preload library" 
(http://www.code-wizards.com/projects/libfaketime/) to reliably test our 
prototype using always the same start in time time-stamps where our 
current time (during the above operations) has been set to start at 
"20091224193000Z"


Again: someone else (in the future) could have the comprehensible 
idea/demand/requirement to client-side trigger the search and write of 
the current server time (+/-offset) into ordinary time-stamp 
attributes... which leads again to the (just hypothetical) questions 
I've explained above.


>> Focused on the LDAP string representation: sending "NULL" instead of 
>> "NOW" seems to be not more than an ineffectual misuse to me. Even "" 
>> (the empty string) would be preferable instead of "NULL" in my opinion.
>>
>> So, let me just try to justify the use of "NOW" instead of "NULL": 
>> the latter needs 33% additional resources! ;-)
>
> NULL is already a standard syntax, so adding another syntax with an 
> underlying
> ASN.1 type of NULL is 100% additional resources :-)

Impressive - in fact that's really extremely scary! ;-)

The good news in the end: Our prototype in the meantime has been already 
prepared to support NULL instead of NOW which is in my opinion just a 
questionable intermediate compromise - at least as long as some 
standardization organization with more detailed normative knowledge has 
declined to extend the standard or has approved to use the nullValue to 
express the current time.


Best regards,
Daniel