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

From: Daniel Pluta <[email-masked]>
Date: Sun, 02 May 2010 11:13:37 +0200

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:
> 
>> decision) denied. To give interested clients a chance to determine
>>  the server's time we suggest that the server should publish its 
>> current time to be query able for some kind of verification / 
>> debugging possibility.
> 
> The immediately preceding sentence is the answer to the "why?"; so 
> that clients can verify that the server's idea of "now" is 
> reasonable, or to debug unexpected results.

Ok, that's fine.

>> Let me now come to the still somewhat open question: "Where and 
>> how?" Q: Where should the time be published? Why within the 
>> Root-DSE, and not in each entry? A: In our opinion clients would 
>> ask servers seldom for their current time but there exist some 
>> justifications for clients to do so. The time information is very 
>> helpful especially in case of supposed errors or for debugging. 
>> Imagine replicated environments where one replica system for 
>> example is operating using the wrong system time. This would 
>> probably lead to strongly varying result sets depending on the 
>> server that answers the queries. Because the time is so seldom 
>> queried we prefer its publication within the "neutral zone" the 
>> Root-DSE, instead of attaching it using an extra attribute for each
>>  entry.
> 
> You haven't considered that the LDAP server a client is connected to
>  could be an X.500 server supporting a distributed DIT, or a virtual
>  directory.

As we've written (above and in our draft, sect. 7.3) we prefer and have
always preferred the Root-DSE. Publishing an additional operational
attribute carrying the current time of the server (an entry is delivered
from) has been mentioned (sect. 7.4) but left open for discussion to
determine whether such kind of information is useful for someone else.

> In both cases the result returned to the client can contain entries 
> contributed by more than one server, each of which has its own time.

Unlike your suggested approach using filter statements like for example
(&(currTime>=9:00)(currTime<=12:00)) to enable client side filtering for
an operational attribute called e.g. currTime that contains the server's
time during delivery our concept does not and has never had a need for 
such kind of attribute.

With your argument concerning the distributed DIT in mind this entry
local attribute does not seem to make sense (even in regard to your
scenario) so we tend to remove sect. 7.4 from the draft.

>> And finally the minor important question: Q: In case the server 
>> would already publish its current system time, what about 
>> additionally publishing the server's timezone?
> 
> Publishing the server time as local time plus time zone (which is 
> allowed by the Generalized Time syntax) allows UTC, server local time
>  or time zone to be recovered from the one value. I would recommend 
> doing that.

That's fine and it complies with what we've suggested in sect. 6.2.

> That is too inflexible. What you should be doing is extending the 
> access control mechanisms in OpenLDAP so that it is possible to 
> express which identities are permitted to apply which matching rules
>  to which attribute types. That, combined with the new matching
> rules, would allow you to do everything you want to do with the new 
> syntaxes and more besides. It would allow access controls to be 
> tailored for the needs of each service and could be applied to 
> syntaxes other than timestamps. It would also allow tighter controls 
> to be placed on existing attributes of Generalized Time syntax.

You're completely right here. We've also thought about that previously
but canceled it because in our opinion this won't be a general but only
a product specific solution.

[snip]

> That's what I don't like about the new syntaxes. Each new 
> authorization criterion needs a new syntax, so we get a proliferation
> of new syntaxes just like old syntaxes, but with special rules. Put
> the rules in the access control models where they belong.

Many thanks for this explanation. We have not thought about this, yet.
It obviously does not scale.

> I would rather do that in the access control mechanisms.

We too. ;-)

[snip]

Last but not least, towards an 01-version please let me give a first
short summary regarding the intermediate status of our ongoing
discussion (please feel free to comment):

General remarks:
- LDAP Server Side Current Time Matching seems to be of interest
- Steven, many thanks for the discussion and your valuable feedback!

Attribute Value Syntaxes to enforce/denie some kind of access:
- Doesn't seem to make sense in general - better use ACLs.
- No need for the many syntactically dedicated ext. matching rule

Matching Rules:
- Instead of all the extensible matching rules only two:
   - equality matching rule: "nowMatch"
   - ordering matching rule: "nowOrderingMatch"
   - both matching rules support now and timely offset matching
   - both matching rules support extensible match filters

Assertion Syntaxes:
- Two standalone assertion syntaxes preferred:
   - simple "NOW"
   - flexible X.680 (based on your already avail. implementation)
   - both compatible with the above matching rules
- Alternative:
   Differentiation between "now" and "nowOffset" assertion syntax
   not strictly needed: both can be integrated in one "Assertion
   Syntax" that supports any offset (also "NOW" using some kind
   of a zero offset?).
- In my opinion: "NOW" would offer improved readability

Operational Attribute for each Entry:
- Distributed DIT could result in many different "NOW"s
   - Currently there's no known use-case for something like this.
   - Remove from draft
[- Nevertheless, keep it just for informational reasons]?!

Root-DSE:
- "supportedFeature" seems to be ok
- "serverTime" whether in UTC or <g-differential> format
    - both seem to be reasonable

Best regards,
Daniel

---

From: Steven Legg <[email-masked]>
Date: Tue, 04 May 2010 17:03:02 +1000

Hi Daniel,

Daniel Pluta wrote:
>> that clients can verify that the server's idea of "now" is reasonable, 
>> or to debug unexpected results.
> 
> Ok, that's fine.
> 
> 
>>> Let me now come to the still somewhat open question: "Where and how?" 
>>> Q: Where should the time be published? Why within the Root-DSE, and 
>>> not in each entry? A: In our opinion clients would ask servers seldom 
>>> for their current time but there exist some justifications for 
>>> clients to do so. The time information is very helpful especially in 
>>> case of supposed errors or for debugging. Imagine replicated 
>>> environments where one replica system for example is operating using 
>>> the wrong system time. This would probably lead to strongly varying 
>>> result sets depending on the server that answers the queries. Because 
>>> the time is so seldom queried we prefer its publication within the 
>>> "neutral zone" the Root-DSE, instead of attaching it using an extra 
>>> attribute for each
>>>  entry.
>>

I'm already doing it so it is obviously useful to someone else (for something
else).

> (&(currTime>=9:00)(currTime<=12:00)) to enable client side filtering for

FYI, for my purposes the filtering is done by the access control decision
function in the server using what is inevitably that server's current time.
Client's don't do any filtering and don't see currentTimeOfDay because
they don't ask for it.

> scenario) so we tend to remove sect. 7.4 from the draft.

Let me try to make it clearer. Suppose that we have a DIT for
o=Acme Corporation with two subunits ou=Sales and ou=Finance. Further
suppose that there are two LDAP/X.500 servers. The first server holds the
o=Acme Corporation entry and the entire ou=Sales subtree. The second
server just holds the entire ou=Finance subtree. Consider an LDAP client
that connects to the first server and issues a search for (cn=Smith) with
the base object ou=Finance,o=Acme Corporation. The first server does not
hold any entries in this subtree so it chains the search request to the
second server. The second server performs the search and returns the
resulting entries to the first server which then forwards them to the
LDAP client. The entries in the result have all come from the second
server, though they were delivered to the client by the first server.
If access controls on the second server used the "now" ordering matching
rule, or if the filter instead included a filter item with the
"now" ordering rule, then the rule would have been evaluated with respect
to the current time on the second server. However, if the client read
the current server time from the root DSE (necessarily in a separate
operation), then it would get the current time on the first server,
which wasn't the time used to determine the results of the person search.
In this scenario the client derives no benefit from knowing the current
server time from the root DSE because it is irrelevant to the person
search result. A current time attribute appearing in each entry gives
the time of the server that actually evaluated that particular entry
(in this case, the second server).

> 
> 
>>> And finally the minor important question: Q: In case the server would 
>>> already publish its current system time, what about additionally 
>>> publishing the server's timezone?
>>

There isn't a common, standardized access control model for LDAP that
you can extend, but that doesn't mean you have to standardize a poor
approach instead. It would be reasonable to have a non-normative
(informative) section or annex (or a separate draft) that describes
how the new matching rules (the normative part) can be used to protect
the privacy of timestamp values when used in conjunction with an access
control model that supports the ability to express what matching rules
can be applied to what attribute types. You could use an extended
OpenLDAP access control model as a concrete example. Anyone wanting to
achieve the same thing on a different platform would need to extend
their native access controls in an equivalent way, but would have the
guidance from the draft and the example from OpenLDAP to go by.

>   Syntax" that supports any offset (also "NOW" using some kind

Whether that differentiation is needed depends on how one extends
the access control model. If there is only the offset assertion
syntax, then the extended access control model needs to be able to
express which identities can apply what matching rules *and*
*assertion* *values* to what attribute types. Note that you need
to be able to prevent the use of non-zero offsets to protect the
timestamps in the ways you want. If there is a nowMatch and a
separate nowOffsetMatch (likewise nowOrderingMatch and
nowOffsetOrderingMatch), then the extended access control model
only needs to be able to express which identities can apply what
matching rules to what attribute types. Only the nowMatch and
nowOrderingMatch rules would be allowed for a protected timestamp
attribute type. The nowOffsetMatch and nowOffsetOrderingMatch rules
would be prohibited, amongst other rules.

Of course, nowMatch is a special case of nowOffsetMatch and
nowOrderingMatch is a special case of nowOffsetOrderingMatch.

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

>   - Currently there's no known use-case for something like this.

The use-case is the generalization for a distributed or virtualized DIT
of *your* use-case.

Regards,
Steven

---

From: Daniel Pluta <[email-masked]>
Date: Tue, 04 May 2010 20:45:33 +0200

Hi Steven,

> (in this case, the second server).

Ok, attaching the current server time using a derived attribute seems to 
offer advantages in case of a chaining in action. So both sections' 
contents are of use and should stay in the draft.

>> That's fine and it complies with what we've suggested in sect. 6.2.

Just a short remark: Daylight saving time possibly reduces the grade of 
usefulness of this information in general, nevertheless I think it 
should be at least optional to be used instead of UTC time.

> can be applied to what attribute types.

> You could use an extended

I already had a look into OpenLDAP sources: It's quite not easy to 
implement some kind of search-privilege limitation using for example a 
matching rule white-/black-list attached to search privileges...

I've already implemented a just-for-fun patch which successfully extends 
the ACL-parsing to restrict search-privileges but applying the resulting 
data structure during matching is currently nearly impossible without 
major changes in OpenLDAP's current source.

> would be prohibited, amongst other rules.

Yes that would fulfill our original intentions in an ideal way - the 
"only" difficulty regarding OpenLDAP's current source seems to be the 
application of acl structures during matching.

Another approach which currently also works for us:
Using "filter=...." statements in current OpenLDAP ACLs fulfills our 
requirements, too. Because this filtering takes place in the last step 
(right before delivery).

This acl-filter is not applied in the user-context thus the user does 
not need access to the time-stamp attributes at all. Instead the server 
processes this filter in its own context.

Possible disadvantage: it could happen that an user's requested search 
uses "(objectClass=*)" which results in a huge result set, which will be 
reduced two 1 entry during the final filtering step in the server.

A probably more efficient approach would be:
Using the rewrite module to dynamically add limiting filter expressions 
to incoming user requests:

(ojbectClass=*) ==slapo-rwm==> (&(objectClass=*)(limit1)(limit2)).

Such extended/limiting filters would lead to initially smaller result 
sets in the first step. Additionall the final server-context-filtering 
could be skipped completely. The only (big) problem as the filter is 
rewritten in the user's context the user needs search permissions on the 
attribute. Granting common search privileges do not fulfill our privacy 
scenarios because inappropriate matching rules can be chosen using 
extensible match filters. Thus the search-permission should be further 
narrowed e.g. on attribute to matching rule association basis...

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

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! ;-)

> The use-case is the generalization for a distributed or virtualized DIT

As stated above this makes of course sense - NOW. ;-)
Many thanks for the scenario!

Best regards,
Daniel

---

From: Steven Legg <[email-masked]>
Date: Fri, 07 May 2010 16:58:11 +1000

Hi Daniel,

[snip]

> should be at least optional to be used instead of UTC time.

In eB2bcom's implementation the local time part always reflects the time
on local clocks for users in the same region as the server, but the
timezone part changes depending on daylight saving time (where I'm sitting
now, the timezone is either +10:00 or +11:00 depending on the time of year).
Thus UTC is always correct and local time is always appropriate.
It isn't possible to know whether a server is on daylight savings time
from the timestamp alone, but we've never had a need to know.

> major changes in OpenLDAP's current source.

Can't you examine the search filter before evaluating it to find the
disallowed combinations of attribute type and matching rule ? Any filter item
that is disallowed can be rewritten to be an undefined match, or the search
can be rejected, whichever makes sense. It ought to be possible to work out
which matching rules are going to be used on which attribute types without
actually waiting to see what happens. I'm assuming that permission to match
is determined only on the user identity (i.e., not dependent on the location
of the entry being accessed), which is still less restrictive than using
the new syntaxes.

> in my personal opinion I would prefer to use "NOW" instead of "NULL".

The filter would look like (timeAttr:nowMatch:=NULL). 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. The nowMatch
rule is not, and cannot be, the equality matching rule of timeAttr, so
(timeAttr=NOW) is bogus.

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

Regards,
Steven

---

From: Daniel Pluta <[email-masked]>
Date: Fri, 07 May 2010 17:45:08 +0200

Hi Steven,

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

>> So, let me just try to justify the use of "NOW" instead of "NULL": 
>> the latter needs 33% 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

---

From: Steven Legg <[email-masked]>
Date: Wed, 12 May 2010 12:24:15 +1000

Hi Daniel,

> syntax (1.3.1....24) but of a new generalizedTime-similar syntax 

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.

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

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

> or what ever) which extend the generalizedTime syntax to address the 

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.

> (point in) time? If yes, where can I find a source/cite which answers 

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.

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

> ldap_initialize( <DEFAULT> )

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

Regards,
Steven

---

From: Daniel Pluta <[email-masked]>
Date: Mon, 17 May 2010 20:32:18 +0200

Hi Steven,

> describing now is quite different from what is written up in the draft.

This extension just demonstrates a possible future demand. Instead of my 
above statement this syntax and the matching rules have been developed 
during our discussion based on our draft but not mentioned in it - 
please excuse me the unintended confusion this might has caused!

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

In my opinion we are not the only party that is interested in allowing 
Generalized Time to be compared with the current time but possibly we 
are the only party that relies on well defined standards.
For example the SQL-guys seems to make use of "now" without any problems 
since years...

>> - 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?
> 
> The LDAP-specific encoding could be anything you like as long as it 
> provides a one-to-one mapping of values.

I don't think another type solves the might by future demand regarding 
support for adding the server side current time into a generalizedTime 
attribute using for example ldif changetypes.

Of course this is not directly related to our draft's matching idea but 
seems to be a valid question that could arise sooner or later in regard 
to LDAP server's that are able to deal with the current time...

>> 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?
> 
> because its value is implicitly understood. You had not previously 
> indicated that the assertion syntax for nowMatch could also include GeneralizedTime

Our prototype just demonstrates two orthogonal approaches for discussion:
1.) extend RFC4517's generalizedTime[Ordering]Match to support current 
time matching (there seems to be a need for the NOW assertion/attribute 
syntax, to also allow modify/add operations the way)

2.) create an RFC4517-similar generalizedTime syntax with similar 
generalizedTime[Ordering]Match rules to achieve the same goal as 1.) but 
without altering/violating the specified behavior of RFC4517.

Although both approaches do not seem to fulfill the privacy requirements 
they are just used for discussion: probably there is a need for such 
kind of functionality which can be justified similar to the 
justification we've already given regarding the matching of client side 
unknown current time.

E.g. adding the current time (possibly also with an offset) to an 
entry's attribute because the client does not know the server's current 
time, especially in the distributed directory environment where the 
client does not establishes a connection to the server the (add/modify) 
operation will be of effect. Imagine a 
Resource-Provider-Reseller-Scenario where the reseller needs to add the 
current time to a previously paid resource directly into the provider's 
side for example.

If there currently is (or in the future could be) a common need for such 
kind of feature we should take this into account in regard to the 
specification of current time matching.

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

Convoluted yes, but just in case there is a need for the above 
demonstrated behavior (on top of our goal of current time matching).

> To legitimize all the things your

For us the current time matching is the primary goal. Everything else on 
top (mentioned above) is optional for us. Nevertheless we wanted to 
mention it because other people could become interested into this 
direction. If so we probably need to take care.

If there is no positive feedback regarding any demand for our add-on 
ideas we would like to focus on the current time matching from now on. 
Therefore the 01-Version of our draft will address:

- Two new matching rules useful for extensible matching of 
generalizedTime attribute values:
	nowMatch / nowOffsetMatch
- Two new assertion value syntaxes:
	NULL / DURATION

nowMatch just supports the NULL syntax while nowOffsetMatch supports 
both syntaxes.

That's it - more or less.

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

I've given a justification in this message, please see above.

Best regards,
Daniel

---

From: Steven Legg <[email-masked]>
Date: Tue, 25 May 2010 16:37:56 +1000

Hi Daniel,

> For example the SQL-guys seems to make use of "now" without any problems 

SQL has a much richer expression syntax than LDAP so it is possible to
naturally express all sorts of things that LDAP filters weren't designed for.
In LDAP we are restricted to comparing an attribute to a constant value.
It would be nice to be able to compare one attribute to another attribute
(i.e., do a join) or compare an attribute to the value of an expression
(possibly including an environment variable like the current time) and
so on.

To my mind, the absence of a way to represent "now" in GeneralizedTime
isn't really the problem. The limited expressibility of LDAP filters is the
problem, and a better query language for LDAP is the solution. I would
rather spend my time building a better query language than building
workarounds like forcing "now" into GeneralizedTime. What you see as
future demand I see as skirting around the real issue.

>>> "NOW" or what ever) which extend the generalizedTime syntax to 
>>> address the first question?
>>

Quite right, but what you are talking about is what I see as a special case
of a more general facility to be able to set any attribute to the value of an
expression, much as one can do in SQL. That would be a more interesting and
more generally useful future direction.

> current time to a previously paid resource directly into the provider's 

You would need to make a case for the end server's idea of the current
time being better than the client's idea of the current time. Their clocks
will be about the same anyway and any discrepancy won't matter for many/most
applications.

The client could always get the same effect by updating the timestamp
with a reasonable value, then reading back the modifyTimestamp of the entry
and finally replacing the previously written timestamp value with the value
from the modifyTimestamp. It's more work, but it can be done today.

>>> a compromise which just represents an limited "LDAP specific 
>>> temporary workaround" that perhaps (mis)uses the nullValue.
>>>
>>> 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...
>>

The matching rules are okay, but the "everything else" looks like the wrong
direction from my, possibly unique, perspective.

> ideas we would like to focus on the current time matching from now on.

That would be best, unless someone else wades into this discussion expressing
support for the add-ons.

Regards,
Steven