Full_Name: Daniel Pluta Version: CVS OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-now-090810.tgz Submission from: (NULL) (91.12.197.171) Please see the README for details. Currently only a DUMMY_OID is assigned to the matching rules and the limited internal attribute and objectclass definitions. I would appreciate your feedback. Thanks!
Hi, I've just uploaded an updated version. Changes regarding schema: - Added EQ-Matching rule to both nowNot{Before|After} attributes - changed attribute nowNotAfter from single- into multi-value ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz Best regards Daniel
> Hi, > > I've just uploaded an updated version. > > Changes regarding schema: > - Added EQ-Matching rule to both nowNot{Before|After} attributes > - changed attribute nowNotAfter from single- into multi-value > > ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz In order to make your contribution useful to others, I think you should definitely separate comparison with respect to current time from the rest of what you need. In this sense, special matching rules to compare generalizedTime-syntax attributes with respect to "now" have nothing to do with the declaration of specific generalizedTime-valued attributes. As I mentioned in an earlier posting, any generalizedTime-syntax attribute can use your special matching rules by way of the extensible filter mechanism, regardless of having any matching rule in their definition. Moreover, attributes can already be defined using slapd.conf/back-config, so there's no need to hardcode them in your module (except, possibly, for your specific needs, but this makes the module less general and useful to others). Finally, I don't think having both a "(<)" and a "(<=)" rule makes sense. LDAP only defines "(<=)" since one may construct "<" as "(!(>=))". But the real reason is that "exactly equal to now" makes little sense as "now" is evanescent: you have no control about exactly when your matching rule will be evaluated, so if the difference between "including now" or "excluding now" is crucial, then there might be something flawed in the policy you're trying to implement. Getting more into implementation related aspects, I think you should really ignore the asserted value, rather than check it's equal to the Epoch. I initially suggested to put the Epoch as the asserted value in order to use some clearly recognizable, yet valid, value. But this should be a matter of style rather than a requirement of the matching rule. With respect to OID assignment, as soon as your contribution is considered of general usefulness, it could receive a temporary OID out of OpenLDAP's experimental branch. If you intend to formalize this set of matching rules somehow, you should apply for IANA assignment of an official OID. Note that I'm not encouraging nor discouraging you in this sense. p.
masarati@aero.polimi.it wrote: >> Hi, >> >> I've just uploaded an updated version. >> >> Changes regarding schema: >> - Added EQ-Matching rule to both nowNot{Before|After} attributes >> - changed attribute nowNotAfter from single- into multi-value >> >> ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz >> > > In order to make your contribution useful to others, I think you should > definitely separate comparison with respect to current time from the rest > of what you need. > In this sense, special matching rules to compare generalizedTime-syntax > attributes with respect to "now" have nothing to do with the declaration > of specific generalizedTime-valued attributes. > I've already thought about this. I'm in two minds about that. > As I mentioned in an earlier posting, any generalizedTime-syntax attribute > can use your special matching rules by way of the extensible filter > mechanism, regardless of having any matching rule in their definition. > I thought, that by not assigning any matching rule the EQ/LE/GE comparison is not possible at all. That's the behavior I would like to achieve regarding the two minimum-attributes (regardless whether the probable separation of matching rules and attribute definitions - disscussed in the above paragraphs). Yesterday I've noticed that without an EQ-Matching definition I was not able to add an additional value in case of a multi-valued attribute definition (so I added EQ-Matching again). I have to admit that I do not understand this in detail. I also have not investigated in deep... > Moreover, attributes can already be defined using slapd.conf/back-config, > so there's no need to hardcode them in your module (except, possibly, for > your specific needs, but this makes the module less general and useful to > others). > The oc/attr definition is for demonstration purposes only (I though it's more compact to include this "demo" and implement it the most restricted way regard data privacy (especially disallow querying LE/GE for both attr). Problably I'll separate the demo into an extra schema file. > But > the real reason is that "exactly equal to now" makes little sense as "now" > is evanescent: you have no control about exactly when your matching rule > hehe that relativistic effects I already had in mind before implementing this kind of matching rule. That's the reason I originally followed the approach to manipulate the search requests' filters. This approach could assure to make use of the "same" now (op->o_time) for all entries. By using the matching rule (especially in combination with the filter= statement in ACLs) "now" will become some kind of "time distance" instead of a point in time because a search' results get evaluated sequentially by test_filter(). In worst case the second have of a billion search entries are valid during the search but get "invalid" during acl processing, because time move's on... ;-) On the other side comparing the lines of code of the matching rule approach to my previous pre-alpha overlay's lines of code, this matching rule's implementation is about 10 times smaller... > will be evaluated, so if the difference between "including now" or > "excluding now" is crucial, then there might be something flawed in the > policy you're trying to implement. > Ok, this in mind I'll at least reduce the matching rules to two but the problem (now == time_delta) still exists. > Getting more into implementation related aspects, I think you should > really ignore the asserted value, rather than check it's equal to the > Epoch. I initially suggested to put the Epoch as the asserted value in > order to use some clearly recognizable, yet valid, value. But this should > be a matter of style rather than a requirement of the matching rule. > I regard to some kind of future formal specification I thought about this, too: in my opinion it seems to be "unnatural" to search (assert) a non-Timestamp-value to a generalizedTimestamp-Syntax attribute... But probably that's really only a matter of style. > With respect to OID assignment, as soon as your contribution is considered > of general usefulness, it could receive a temporary OID out of OpenLDAP's > experimental branch. If you intend to formalize this set of matching > rules somehow, you should apply for IANA assignment of an official OID. > > Note that I'm not encouraging nor discouraging you in this sense. > I'm currently thinking about this... Thanks for your feedback the discussion is very interesting and helpful.
> masarati@aero.polimi.it wrote: >> As I mentioned in an earlier posting, any generalizedTime-syntax >> attribute >> can use your special matching rules by way of the extensible filter >> mechanism, regardless of having any matching rule in their definition. >> > I thought, that by not assigning any matching rule the EQ/LE/GE > comparison is not possible at all. That's the behavior I would like to > achieve regarding the two minimum-attributes (regardless whether the > probable separation of matching rules and attribute definitions - > disscussed in the above paragraphs). By not assigning a matching rule, that specific matching is not possible using normal filters. However, the extensible filter mechanism overrides this, by allowing to specify the desired matching rule in the AVA. > Yesterday I've noticed that without an EQ-Matching definition I was not > able to add an additional value in case of a multi-valued attribute > definition (so I added EQ-Matching again). I have to admit that I do not > understand this in detail. I also have not investigated in deep... That's a totally different business. If you do not define an equality matching rule, multiple values cannot be checked for duplicates. So the only way to add a value consists in performing a modify:delete and a modify:add within the same modify operation that removes the original values and replaces them with themselves plus the new ones. >> Moreover, attributes can already be defined using >> slapd.conf/back-config, >> so there's no need to hardcode them in your module (except, possibly, >> for >> your specific needs, but this makes the module less general and useful >> to >> others). >> > The oc/attr definition is for demonstration purposes only (I though it's > more compact to include this "demo" and implement it the most restricted > way regard data privacy (especially disallow querying LE/GE for both > attr). > Problably I'll separate the demo into an extra schema file. You should. Please note that for the purpose of testing your code, every entry already has a createTimestamp and a modifyTimestamp attribute. >> But >> the real reason is that "exactly equal to now" makes little sense as >> "now" >> is evanescent: you have no control about exactly when your matching rule >> > hehe that relativistic effects I already had in mind before implementing > this kind of matching rule. That's the reason I originally followed the > approach to manipulate the search requests' filters. This approach could > assure to make use of the "same" now (op->o_time) for all entries. Well, this calls for an extension of the matching API that also passes the Operation pointer. Something for 2.5, if worth the effort (note that value matching and operations are orthogonal, as value matching can also occur outside the scope of a LDAP operation, so passing that pointer would basically be a matter of opportunity if matching rule implementations need it). > By using the matching rule (especially in combination with the filter= > statement in ACLs) "now" will become some kind of "time distance" > instead of a point in time because a search' results get evaluated > sequentially by test_filter(). > > In worst case the second have of a billion search entries are valid > during the search but get "invalid" during acl processing, because time > move's on... ;-) > > On the other side comparing the lines of code of the matching rule > approach to my previous pre-alpha overlay's lines of code, this matching > rule's implementation is about 10 times smaller... If you follow my advice, it'll be 100 times smaller :) >> will be evaluated, so if the difference between "including now" or >> "excluding now" is crucial, then there might be something flawed in the >> policy you're trying to implement. >> > Ok, this in mind I'll at least reduce the matching rules to two but the > problem (now == time_delta) still exists. I concur. >> Getting more into implementation related aspects, I think you should >> really ignore the asserted value, rather than check it's equal to the >> Epoch. I initially suggested to put the Epoch as the asserted value in >> order to use some clearly recognizable, yet valid, value. But this >> should >> be a matter of style rather than a requirement of the matching rule. >> > I regard to some kind of future formal specification I thought about > this, too: in my opinion it seems to be "unnatural" to search (assert) a > non-Timestamp-value to a generalizedTimestamp-Syntax attribute... But > probably that's really only a matter of style. I'm not sure I understand what you mean here. If you mean that anything could fit as the asserted value, this is not correct, because LDAP requires the asserted value to comply with the syntax of the matchingRule. Of course one could define a syntax for asserting generalizedTime values that consists in the empty string, so that (createTimestamp:laterThanNow:=) is a valid filter (note the empty asserted value). >> With respect to OID assignment, as soon as your contribution is >> considered >> of general usefulness, it could receive a temporary OID out of >> OpenLDAP's >> experimental branch. If you intend to formalize this set of matching >> rules somehow, you should apply for IANA assignment of an official OID. >> >> Note that I'm not encouraging nor discouraging you in this sense. >> > I'm currently thinking about this... > > Thanks for your feedback the discussion is very interesting and helpful. p.
Please see <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-13-now2.1.c> for a minimal implementation that instantiates a specific syntax (that only allows the empty string) and works for generalizedTime as well as CSN syntaxes. Valid filters are (createTimestamp:nowOrEarlier:=) (entryCSN:nowOrLater:=) Please check the code, and see if you agree in the attributions (significantly, in releasing the copyright to the OpenLDAP foundation). Also, note that an OID from OpenLDAP's devel arc has been used, but not yet allocated. I plan to do it shortly. p.
On Aug 12, 2009, at 1:12 PM, daniel@pluta.biz wrote: > Hi, > > I've just uploaded an updated version. > > Changes regarding schema: > - Added EQ-Matching rule to both nowNot{Before|After} attributes > - changed attribute nowNotAfter from single- into multi-value > > ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz > This submission, aside from not being in the form of a patch, doesn't include "notice of origin" as required by our contributing guidelines <http://www.openldap.org/devel/contributing.html >. Also, your tarball contains a source file that includes a copyright notice, the tarball includes other file(s). This makes it non-obvious as to whether your copyright notice is intended to apply only to the source file but to the tarball as a whole (including the other file(s)). (This is why our guidelines ask for patches with notices at top, it makes it more clear as to what copyright you are asserting.) As an alternative to reworking your submission as a patch, you can instead include a file called COPYRIGHT which contains both of the required notices. Please revise your contribution so that it may be properly considered. Consideration of Ando's submission will be deferred until such time as your contribution is accepted (as it appears to be based upon yours). -- Kurt
On Aug 13, 2009, at 7:24 AM, masarati@aero.polimi.it wrote: > Please check the code, and see if you agree in the attributions > (significantly, in releasing the copyright to the OpenLDAP > foundation). No. Once Daniel corrects his submission, and the Foundation finds it acceptable, it can be used in OpenLDAP with or without modification. No further of legal agreement with Daniel is needed and hence should not be requested. That is, Daniel's copyright notice must provide and must be relied on to give appropriate license. The notice you include in your submission would (assuming Daniel's submission is accepted, and your submission is derived (in the copyright sense) from his) would be wrong as it doesn't preserve his notice. The end result in OpenLDAP Software would be something like: * Copyright 2009 The OpenLDAP Foundation. * Portions Copyright 2009 Daniel Pluta. * Portions Copyright 2009 Pierangelo Masarati * All rights reserved. ... The PORTIONS COPYRIGHT: comment must be removed. Instead, the ACKNOWLEDGEMENT section should include whatever attribution (in the non-copyright sense) is appropriate in this case. Something like: This work was developed by Pierangelo Masarati based upon a previous work developed by Daniel Pluta. Both this and the previous work were developed for inclusion in OpenLDAP Software. > Also, note that an OID from OpenLDAP's devel arc has been used, but > not > yet allocated. I plan to do it shortly. > > p. > >
Dear Pierangelo, (dear Kurt), first of all my special thanks belong to both of you for your contribution to the on going discussions. Secondly I want to take the opportunity just right now to clarify that I do not agree to your idea or suggestion to extend the copyright in direction of a dual-portion-copyright statement. Based on my analysis of your surprisingly fast submitted code sample I came to the following conclusion and justification regarding my decision above: Last but not least I would have appreciated it if you would have contacted me *before* changing the code and not to mention my copyright notice. Thanks Kurt for your intervention. Besides this, as time, discussion and development has continuously moved on (even before your kind of "uncoordinated emergency submit") it seems to me that your sudden sample code does not cover any of my primary intentions already rudimentary contained in "now.c" and mentioned during the discussion: - there's no kind of inheritance of matching rules (all are directly associated to generalizedTime / CSN) - additionally the nowOrLater *and* the nowOrEarlier-rules are associated simultaneously to one and the same attribute (what makes no difference for single-valued attribute and thus could be done. On the other hand this leads to false positively reported valid but indeed invalid entries in case of multi-valued attributes - details see below). - you have not implemented any sort of possibility to allow the definition of separate "syntactically standalone" attributes (derived from generalizedTime/CSN, by independent syntax) to limit LE/GE filtering for both dead center attributes. (limiting search access using ACLs would obviously not work because the extensible search needs to be allowed). - multi-valued upper dead center timestamp attributes can not be handled correctly by your code. I have not investigated in deep but it is clear to me that in case of multiple values whereas one or more timestamp/CSN values are in the past, while at least one is in the future leads to the above mentioned false positive reporting in your code. - It seems to me that you have not tested the behavior of your suggested code properly in this short period of time (your tests have only seem to cover createTimestamp - which btw do not make any sense in concern to now.c's common intention in case the createTimestamp's value has not been faked ;-)). - as your code changes significantly changes the behavior and intention of now.c your submit also lacks any kind of documentation (besides the code, which I had to analyze first). In my opinion your submit sadly does not represent a very useful enhancement nor a functional extension (in the sense of the original goal of now.c) which could be integrated without major adaptations. That's the reason why I'm currently not see any reason to share my copyright notice. Nevertheless, as I've already told you before the discussion with you have always been very helpful for me so I've added you willingly to the acknowledgments section. I hope you understand my explanations and it will be fine for you. Of course I'm available and ready for further technical discussions ... Last but not least and from lessons learn: I think some kind of a formal specification (external to my head ;-)) would be very helpful to understand the design ideas, decisions as well as the new chances (and possible limitations) now.c introduces into LDAP. One or perhaps even more related I-Ds are currently a work in progress here at my side. I've uploaded a new version of now.c (as tgz because it contains various files, e.g. a sample schema in ldif- and schema-format for easier testing and perhaps as a basis for on going discussions). I hope I've correctly updated the IPR statement according my above expressed intention and according the needs of the OpenLDAP foundation. Kurt could you please have a look on it again? The updated version can be obtained from here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815.tgz Thanks a lot and best regards Daniel -------- Original-Nachricht -------- Betreff: Re: [OFFLINE] Re: (ITS#6247) Datum: Thu, 13 Aug 2009 08:54:35 -0700 Von: Kurt Zeilenga <kurt@OpenLDAP.org> An: masarati@aero.polimi.it CC: daniel@pluta.biz Referenzen: <200908131112.n7DBCYIx025879@boole.openldap.org> <46026.93.149.38.235.1250177284.squirrel@www.aero.polimi.it> On Aug 13, 2009, at 8:28 AM, masarati@aero.polimi.it wrote: > Daniel (Kurt), > > (Note to Kurt: as there is no affiliation between Daniel and me, we > did > not coordinate anything, so we'll probably better do it now and > start from > scratch, instead of polluting the ITS). This needs to be done in two steps. 1) Daniel needs to address notices issues in his submission. 2) You need to address the notices issues in your derived submission. Daniel should follow the instructions I provide, and then you should follow the instructions I provide. These steps are simple, straight forward, and have a clear result. > I suggest Daniel evaluates the line I'm proposing No. This in no way fulfills the Foundation requirements. The line you are asking Daniel to evaluate is not a formal notice. You actually failed to met his license, which requires you to include a copy of his copyright notice in your work. You copied only an informal acknowledgement, not his copyright notice and license statement. > and, based on the file I > submitted, formalizes a definitive patch with appropriate copyrights > and > submits it along the guidelines of the OpenLDAP foundation. Your submission doesn't met the guidelines of the Foundation as it also doesn't include a notice of origin nor asserts your copyright, and worse, it failed to met the copying requirement Daniel placed on his submission (that his notice be included in copies).
I've just removed four ugly Debug() statements. ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815-2.tgz BTW: There are still only DUMMY-Values assigned as OIDs.
I've just removed four unnecessary Debug() statements (to get rid of the warnings during the build). ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815-2.tgz Please note there are still only dummy values assigned as OIDs.
Daniel, While I understand you to have both some IPR concerns and technical concerns with what Ando proposed, I will only concern myself to the IPR issues. Thank you for updating your contribution to provide the required notices. I have provided guidance to Ando on how to create a work derived from your submission which, I believe, mets the terms of the license, the OpenLDAP Public License, you granted. In particular, I provided him guidance on how to properly "retain your copyright statement and notices". Presuming your notices are properly retained, I see no IPR issue here in the project accepting your contribution and/or Ando's derived work, and the Foundation distributing either or both. I do regularly review commits to our source repository to ensure IPR issues are adequately addressed, but do feel free to raise any issue you see in how we handle materials which you have copyright interest in. Beyond that, I leave it to the Project to determine the technical suitability of these contributions and what, if any, modifications should be made prior to inclusion in OpenLDAP Software. Given your license grant, the Foundation sees no obligation to seek further permission from you and hence will not seek additional permission before redistributing your work, with or without modification. If it was your intent to require those redistributing your work, with or without modification, to obtain some additional permission from you, please immediately advise us that your copyright statement and notice do not reflect your intentions. If immediately advised, we will try to honor your intentions. Otherwise, we will continue to assume, as we do now, that your copyright statement and notice reflect your intentions at the time of your contribution was offered. With that, I leave determination of the technical suitability to the Project. Regards, Kurt
Kurt@OpenLDAP.org wrote: > With that, I leave determination of the technical suitability to the > Project. It took me several passes through this discussion and the README to understand what the intent of this code is. Just to make sure I get it, let me restate what I saw: 3 extended matching rules for comparing a timestamp attribute to the server's current clock. I'm not sure why the 2 additional syntaxes are useful. If you want to define a generalizedTime attribute that cannot be compared for ordering, simply omit the ORDERING rule from the attribute's definition. The use of negatives is rather confusing. In the example, instead of "nowNotBefore" and "nowNotAfter" I would simply have called them "startDate" and "endDate". The language is also confusing in other areas, I don't understand what property you're trying to convey with the terms "dead center attribute" or "syntactically standalone attribute". On a slightly related note, in the context of time-relative ACLs, it would be worthwhile to define a behavior for time-of-day comparisons (i.e., just compare hours:minutes:seconds, excluding year/month/day). Companies often want to limit access to resources to only a set of office hours, etc. Of course to properly handle the "office hours" case would also require day-of-week matching. That may be getting to be too complicated for this particular submission, but it seems closely related so I mention it here. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
> On a slightly related note, in the context of time-relative ACLs, it would > be > worthwhile to define a behavior for time-of-day comparisons (i.e., just > compare hours:minutes:seconds, excluding year/month/day). Companies often > want > to limit access to resources to only a set of office hours, etc. Of course > to > properly handle the "office hours" case would also require day-of-week > matching. That may be getting to be too complicated for this particular > submission, but it seems closely related so I mention it here. Howard, I was also thinking of something like that. Since we basically have a field available in the matching rule (the asserted value), I suggested to add an assertion syntax defaulting to the empty value. I was planning to turn this assertion syntax into a timestamp mask that allows to filter what fractions should be asserted. Another possibly related issue is locale: the time of slapd is supposed to be UTC, but filtering on working hours and so should be done keeping into account timezone, daylight saving and so. The assertion syntax could handle this in a user-friendly manner. Probably, I better step off and formalize things before further coding. p.
Howard Chu schrieb: > Kurt@OpenLDAP.org wrote: >> With that, I leave determination of the technical suitability to the >> Project. @Kurt: my given copyright notices meet my intentions. > I'm not sure why the 2 additional syntaxes are useful. If you want to > define a generalizedTime attribute that cannot be compared for ordering, > simply omit the ORDERING rule from the attribute's definition. I thought, that it is possible to "overwrite" the ORDERING (even if its left empty) by using any kind of syntax-related matching rule assertion... This is a quite old posting from the list but nevertheless I would like to cite it: http://www.openldap.org/lists/openldap-devel/200010/msg00092.html ------8<-------8<------ >Also, I have found this interesting section in RFC 2252: > >----- >8. Matching Rules > > Servers which implement the extensibleMatch filter SHOULD allow all > the matching rules listed in this section to be used in the > extensibleMatch. In general these servers SHOULD allow matching > rules to be used with all attribute types known to the server, when > the assertion syntax of the matching rule is the same as the value > syntax of the attribute. Yes. That is, if the held value is syntax X, one should be able to use any matching rule in which the assertion syntax X. ------8<-------8<------ > The use of negatives is rather confusing. In the example, instead of > "nowNotBefore" and "nowNotAfter" I would simply have called them > "startDate" and "endDate". In general, the names indeed sound quite strange. But that seems only a matter of style. NotAfter and NotBefore is borrowed from ssl certificates' validNotBefore/-After fields. As I've called the module "now" I just replaced "valid" by "now"... On the other hand I wanted to be sure to not collide with some might be existing attribute definitions. > The language is also confusing in other areas, I don't understand what > property you're trying to convey with the terms "dead center attribute" simply the lower and the upper limits of a time period (lower: nowNotBefore, upper: nowNotAfter) > or "syntactically standalone attribute". All I've ment is just a new syntax name to differentiate regarding the special use of "now" and to avoid the possibility regarding my (possibly wrong) assumption that matching rules can be "overwritten". > On a slightly related note, in the context of time-relative ACLs, it > would be worthwhile to define a behavior for time-of-day comparisons > (i.e., just compare hours:minutes:seconds, excluding year/month/day). This kind of feature sounds fine to me, too. Perhaps something like this could be implemented by introducing some kind of officeHourSyntax + matching rule which operates on e.g. "day(s)_of_week#hh:mm:ss#hh:mm:ss" attribute values (just my first thought and very simplified). On the other side, using only one attribute which stores a start as well as an end timestamp is not what I originally wanted for "now" because I would like to have the possibility to track period extensions using the multi-valued upper dead center attribute. > Companies often want to limit access to resources to only a set of > office hours, etc. Of course to properly handle the "office hours" case > would also require day-of-week matching. That may be getting to be too > complicated for this particular submission, but it seems closely related > so I mention it here. In my opinion your suggestion sounds really interesting. I personally just had searched for some kind of solution to get rid of the just-in-time event-triggered dependencies regarding provisioning of interconnected (not replicated) IDM-systems. So "now's" scope targets to longer (more static, not often changing) time-distances. The check for the "office hours case" could be handled by an all-in-wonder (multi-valued) attribute which stores "day(s)#start#end". Many thanks for your feedback. Some additional feedback/clarification regarding the above mentioned "overwriting" of matching rules would be very fine, too (e.g. a link where I can get the detailed specs).
Some personal thoughts about locale (timezone) support. This seems to be by far out of scope and probably completely against the intention of "now.c". How can the timezone be evaluated/specified? I think this can only be achieved on client-side by specifying some kind of +/-HHMM or timezone-strings in the matching rule's assertion... This offers the possibility to chose a timezone on client side (e.g. a "window" of 46 hours) which is against the intention of "now". now.c's original purpose is strictly limited and specialized on data privacy requirements. Only the server should decide about a currently (now) valid entry. I don't want to give a client the chance to variable request a timestamp (e.g by using a filter or even timezone) of "personal" interest. Even with the above described limited scope there seem to be plenty of open questions before thinking about "office-hours" and so on. Just two examples regarding the current implementation of now: - The server's timezone vs. the client's timezone (that's more or less obvious - in my opinion it's sufficient to store UTC times). - Replication of "now" attributes' values between slapds that are located in different timezones and client's that communicate with these server's...
daniel@pluta.biz wrote: > Some personal thoughts about locale (timezone) support. This seems to be > by far out of scope and probably completely against the intention of > "now.c". > > How can the timezone be evaluated/specified? I think this can only be > achieved on client-side by specifying some kind of +/-HHMM or > timezone-strings in the matching rule's assertion... > > This offers the possibility to chose a timezone on client side (e.g. a > "window" of 46 hours) which is against the intention of "now". > > now.c's original purpose is strictly limited and specialized on data > privacy requirements. Only the server should decide about a currently > (now) valid entry. I don't want to give a client the chance to variable > request a timestamp (e.g by using a filter or even timezone) of > "personal" interest. > > Even with the above described limited scope there seem to be plenty of > open questions before thinking about "office-hours" and so on. Just two > examples regarding the current implementation of now: > - The server's timezone vs. the client's timezone (that's more or less > obvious - in my opinion it's sufficient to store UTC times). > - Replication of "now" attributes' values between slapds that are > located in different timezones and client's that communicate with these > server's... IMHO the client has to convert all user input to GMT and convert all server results to local timezone for presentation to the user. The server internally processes everything as GMT. Maybe I got you wrong though. Other server implementations do it this way when checking logon hours. Ciao, Michael.
Michael Ströder schrieb: > daniel@pluta.biz wrote: >> Even with the above described limited scope there seem to be plenty of >> open questions before thinking about "office-hours" and so on. Just two >> examples regarding the current implementation of now: >> - The server's timezone vs. the client's timezone (that's more or less >> obvious - in my opinion it's sufficient to store UTC times). >> - Replication of "now" attributes' values between slapds that are >> located in different timezones and client's that communicate with these >> server's... > > IMHO the client has to convert all user input to GMT and convert all server > results to local timezone for presentation to the user. The server internally > processes everything as GMT. Maybe I got you wrong though. Other server > implementations do it this way when checking logon hours. The server internally compares the (once set) attributes' values against its current time (whether locale or utc, does not really matter here essentially it's always used the same - utc or local time) but the server does not know (IMHO it cannot reliably determine) from which timezone a client currently is connecting. Imagine a business trip to Japan (GMT+10) login would not work during the original specified (European) office hours, even when asking a local replica server in Japan...
daniel@pluta.biz wrote: > Michael Ströder schrieb: >> daniel@pluta.biz wrote: >>> Even with the above described limited scope there seem to be plenty of >>> open questions before thinking about "office-hours" and so on. Just two >>> examples regarding the current implementation of now: >>> - The server's timezone vs. the client's timezone (that's more or less >>> obvious - in my opinion it's sufficient to store UTC times). Yes, time is always stored in UTC in the server. >>> - Replication of "now" attributes' values between slapds that are >>> located in different timezones and client's that communicate with these >>> server's... >> IMHO the client has to convert all user input to GMT and convert all server >> results to local timezone for presentation to the user. The server internally >> processes everything as GMT. Maybe I got you wrong though. Other server >> implementations do it this way when checking logon hours. > The server internally compares the (once set) attributes' values against > its current time (whether locale or utc, does not really matter here > essentially it's always used the same - utc or local time) but the > server does not know (IMHO it cannot reliably determine) from which > timezone a client currently is connecting. Imagine a business trip to > Japan (GMT+10) login would not work during the original specified > (European) office hours, even when asking a local replica server in Japan... Right. Which is a good argument against centralized enforcement of general logon hours, since only the client knows what timezone is relevant. Of course, a company with offices in many timezones, and standardized working policies, might use such a mechanism to control the electronic door locks in all of their buildings. In that case it would make sense for the client software to treat the in-directory times as zoneless, or localtime... But I agree, a discussion of how to manipulate timezone information is outside the scope of this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi, I've uploaded a cleaned up version. It's nearly a complete rewrite of the original contribution. In addition to the previous version which (intentionally) just supported the constant MRA "NOW" the updated version also supports now[+/-]offset calculation and matching. The offset's syntax is "NYears#Nmonths#Ndays#NHours#NMinutes#NSeconds" where '#' separates the different time unit fields and N is the amount of time (offset) for a distinct time unit. N can be a negative or positive value (all none-digits and blanks are ignored, multiple signs are simply aggregated to a single (the first from the left) sign). Thanks to previous normalization before the actual matching the "timedrift effect" (see followup #4 above) isn't present any more, too. The two matching rule's (nowOrEarlier/nowOrLaterMatch) are compatible with any generalizedTime-syntax based attribute. Additionally the module introduces two specialized syntaxes exclusively dedicated to this modules matching rules (intentionally not supporting any kind of generalizedTime[Ordering]Match-ing extensible match). Please have a look at the README, the sample schema definition, and/or the source for further details. The current version can be found here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-091110-1.tgz Any kind of feedback is very welcome. Thanks a lot! Daniel
Hi, I did just some small cleanups, but added no new functionality. I've extracted the minimalistic slapd-api modifications in an extra file called "now_slapd.patch" also contained in the tgz. The code compiles and runs against todays version of "HEAD". The new tgz-file can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-091229-1.tgz Cheers Daniel
Hi, I've uploaded a new patch implementing the specifications from http://www.ietf.org/id/draft-pluta-ldap-srv-side-current-time-match-00.txt The code compiles and runs against todays "HEAD". The patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100325.patch Best regards Daniel
moved from Incoming to Contrib
Hi, just some changes and cleanups according the still ongoing discussion on ldapext. 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 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 To extend generalizedTime attribute types to also support "NOW" as assertion value: - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION Beware of patching conflicts in schema_init.c: This patch contains small redundant parts from my parallel contribution in ITS#6532 Regards, Daniel
On May 1, 2010, at 12:31 PM, daniel@pluta.biz wrote: > Hi, > > just some changes and cleanups according the still ongoing discussion on > ldapext. I recommend consideration of this patch be deferred until the specification is less of a work-in-a-progress. > > 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. 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. > > 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. > > > 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. > > > Beware of patching conflicts in schema_init.c: > This patch contains small redundant parts from my parallel contribution > in ITS#6532 > > Regards, > Daniel > >
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.
In regards to my X.501 comments, see "Matching Rule Requirements" section of X.501(93). Note that only the 93 edition is normative here. I note that you actually need to specify the syntaxes and matching rules in X.500 terms, and then simply specify a string representation for the syntaxes for use in LDAP. See RFC 4521, Section 5.1 (for LDAP Syntaxes) and 5.2 (for Matching Rules) and Section 5 more generally for schema. As far as your I-D goes, I currently deferring to Steve's initial review at this early stage in its development because I'm busy and I trust Steve to tease out any obvious ASN.1, X.500, and/or LDAP issues with your I-D and to "educate" you as might be necessary. I'll join in later, possibly after you revise your I-D once or twice to address Steve's comments. -- Kurt
I've enabled <g-differential> format as default for the Root-DSE's serverTime attribute (and thus removed the #ifdef CTM_G_DIFFERENTIAL_SERVERTIME). The updated patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100503.patch Please use -DCTM during compilation. Below is a sample schema file called "example.schema" and some sample data called "example.ldif". In addition also some sample ldif change files and filter statements are provided to: - offer you some first, quick and easy testing possibilities regarding "LDAP server side current time matching"'s matching rules in action - and to give us a chance to get more detailed feedback regarding problems concerning the LDAP specification in common (e.g. violation of the standard) and slapd in detail. Many thanks! Depending on your feedback and the current status of the discussion on ldapext the code will be updated accordingly. It's currently just a prototype, the obviously open implementation TODOs are: - use operation's time-stamp instead of system calls (OpenLDAP 2.5?) - X.680 duration-syntax (instead of custom offset fun: "n#n#n#n#n#n") - further cleanups: function aggregation / coding style / ... - integration into "make test"? e.g. using FTPL: http://www.code-wizards.com/projects/libfaketime (?!) #========================================= $: cat example.schema attributetype ( 1.3.6.1.4.1.7650.666.1.1.1 NAME 'demoTs1' DESC 'draft-pluta-ldap-srv-side-current-time-match: 1st demo attribute' EQUALITY nowMatch ORDERING nowOrderingMatch SYNTAX 1.3.6.1.4.1.7650.6.2.3.1.0 ) attributetype ( 1.3.6.1.4.1.7650.666.1.1.2 NAME 'demoTs2' DESC 'draft-pluta-ldap-srv-side-current-time-match: 2nd demo attribute' EQUALITY nowMatch ORDERING nowOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) attributetype ( 1.3.6.1.4.1.7650.666.1.1.3 NAME 'demoTs3' DESC 'draft-pluta-ldap-srv-side-current-time-match: 3rd demo attribute (violat es RFC4517)' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) objectclass ( 1.3.6.1.4.1.7650.666.1.2.1 NAME 'ctmDemo' DESC 'draft-pluta-ldap-srv-side-current-time-match: demo objectClass' AUXILIARY MAY ( demoTs1 $ demoTs2 $ demoTs3 ) ) #==DATA======================================= $: cat example.ldif dn: dc=example,dc=com objectClass: domain objectClass: extensibleObject objectClass: top dn: ou=dev,dc=example,dc=com objectClass: organizationalUnit objectClass: top objectClass: ctmDemo ou: dev demoTs1: 20100101000000Z demoTs2: 20100101000000Z demoTs3: 20100101000000Z #==LDIF=CHANGE=FILES========================== $: cat add_delete.ldif dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs1 demoTs1: 20100101000000Z - add: demoTs1 demoTs1: 20100201000001Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs2 demoTs2: 20100101000000Z - add: demoTs2 demoTs2: 20100201000001Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs3 demoTs3: 20100101000000Z - add: demoTs3 demoTs3: 20100201000001Z #----------------------------------------- $: cat add_mv.ldif dn: ou=dev,dc=example,dc=com changetype: modify add: demoTs1 demoTs1: 20110201000000Z - add: demoTs1 demoTs1: 20120201000000Z - add: demoTs1 demoTs1: 20130201000000Z - add: demoTs1 demoTs1: 20100201000000Z dn: ou=dev,dc=example,dc=com changetype: modify add: demoTs2 demoTs2: 20110201000000Z - add: demoTs2 demoTs2: 20120201000000Z - add: demoTs2 demoTs2: 20130201000000Z - add: demoTs2 demoTs2: 20100201000000Z dn: ou=dev,dc=example,dc=com changetype: modify add: demoTs3 demoTs3: 20110201000000Z - add: demoTs3 demoTs3: 20120201000000Z - add: demoTs3 demoTs3: 20130201000000Z - add: demoTs3 demoTs3: 20100201000000Z #----------------------------------------- $: cat reset.ldif dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs1 - add: demoTs1 demoTs1: 20100101000000Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs2 - add: demoTs2 demoTs2: 20100101000000Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs3 - add: demoTs3 demoTs3: 20100101000000Z #==FILTER=STATEMENTS====================== #BTW: You can use the FakeTime Preload Library #(link above) to easily fake slapd's time to #get constant results for automatic testing (demoTs1=20100101000000Z) (demoTs1<=NOW) (demoTs1>=NOW) (demoTs1>=-2#0#0#0#0#0) (demoTs2=20100101000000Z) (demoTs2<=NOW) (demoTs2>=NOW) (demoTs2<=0#-1#0#0#0#0) (demoTs3=20100101000000Z) #Only possible if compiled using: #-DRFC4517_ASSERTION_SYNTAX_VIOLATION (demoTs3<=NOW) (demoTs3>=NOW)
An updated version of the patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100509.patch
Created attachment 605 [details] daniel-pluta-now-20090810.tgz From FTP server
Created attachment 606 [details] daniel-pluta-now-20090812.tgz From FTP server
Created attachment 607 [details] pierangelo-masarati-2009-08-13-now2.1.c
Created attachment 608 [details] daniel-pluta-now-20090815.tgz
Created attachment 609 [details] daniel-pluta-now-20090815-2.tgz
Created attachment 610 [details] daniel-pluta-now-20090815-3.tgz
Created attachment 611 [details] daniel-pluta-now-2009-11-10-1.tgz
Created attachment 612 [details] daniel-pluta-now-2009-12-29-1.tgz
Created attachment 613 [details] daniel-pluta-now-2010-03-25.patch
Created attachment 614 [details] daniel-pluta-now-2010-05-01.patch
Created attachment 615 [details] daniel-pluta-now-2010-05-03.patch
Created attachment 616 [details] daniel-pluta-now-2010-05-09.patch
I suspect that due to the changes in bug#9120 that this work needs updating again?