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

[Steven Legg <[e-mail]>]

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:
>>>>>>>> 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....).

I assumed that timeAttr was of Generalized Time, nowBefore,
nowBeforeOffset, nowAfter or nowAfterOffset syntax. What you are
describing now is quite different from what is written up in the draft.

> This gT-similar syntax allows ordinary generalizedTime formats as well 
> as the special time-stamp "NOW/NULL"

I see below that you also allow offsets as values.

 > 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).

Syntactic validity applies to protocol messages as much as anything else.
"NOW" is not a valid Generalized Time value in a protocol message and it
isn't made valid just because the server substitutes the value in its
internal processing.

 > 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?

I haven't ever heard anyone else express a need for such a special value.

> - 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?

I would take a lot of hard work to attempt to make such a change to ISO 8601
and/or X.680 with no guarantee of success. The ASN.1 working group might
just tell you that no change is necessary because you can use a CHOICE to
define a suitable type, i.e.,

     CHOICE {
         time       GeneralizedTime,
         now        NULL,
         nowOffset  DURATION
     }

The LDAP-specific encoding could be anything you like as long as it provides
a one-to-one mapping of values.

> - 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?

If GeneralizedTime were extended to include a special value to indicate
the current time then I imagine it would be called something like "NOW"
or "CURRENT-TIME". The NULL type in ASN.1 is used in cases where the
only thing that needs to be conveyed is the presence of some quantity
because its value is implicitly understood. You had not previously indicated
that the assertion syntax for nowMatch could also include GeneralizedTime
values so it seemed to have an implicitly understood value that fits
with the typical use of NULL.

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

This is one seriously convoluted syntax. To legitimize all the things your
implementation is doing the syntax would have to be at least notionally
represented by a choice type like the one I gave above and would be both
the attribute syntax of timeAttr and the assertion syntax of nowMatch.
However there would be restrictions on the use of the syntax depending on
the context. To protect disclosure of timestamps it would be necessary to
allow only "NOW" as a value of the assertion syntax when nowMatch is used
in a filter (extensible match or otherwise). However, when nowMatch is used
to compare attribute values during, for example, update operations the
assertion syntax would be unrestricted. The attribute syntax would be
unrestricted in protocol messages but at some point in the processing of
an operation the "NOW" and offset values have to be replaced by
GeneralizedTime values. The description would have to be extensive to
cover all the situations in which the syntax and matching rule are
explicitly or implicitly involved.

I for one, would not be interested in implementing such a strange syntax.

> 
> 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

This is a use case that you haven't previously revealed or justified.

Regards,
Steven

> 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