[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] [Fwd: New Version Notification for draft-pluta-ldap-srv-side-current-time-match-00]
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
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext