[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:
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
That's the reason we have to clarify our intention and to further
differentiate in regard to your answer:
You assumed that the timeAttr is of generalizedTime syntax, but the
above "timeAttr" (from my previous posting) is not of generalizedTime
syntax (1.3.1....24) but of a new generalizedTime-similar syntax
(1.3.1...7650....).
I assumed that timeAttr was of Generalized Time, nowBefore,
nowBeforeOffset, nowAfter or nowAfterOffset syntax. What you are
describing now is quite different from what is written up in the draft.
This 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!
<hypothetical_discussion>
My main questions into direction of any interested standardization
organization would be:
- How to express this special (floating) point in time in regard to
ISO8601 - is there possibly a gap in ISO8601?
I haven't ever heard anyone else express a need for such a special value.
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?
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.
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...
- Is it really a standardization organization's intention that the
nullValue should be (mis)used to represent the abstract floating
current (point in) time? If yes, where can I find a source/cite which
answers this question?
If GeneralizedTime were extended to include a special value to indicate
the current time then I imagine it would be called something like "NOW"
or "CURRENT-TIME". The NULL type in ASN.1 is used in cases where the
only thing that needs to be conveyed is the presence of some quantity
because its value is implicitly understood. You had not previously
indicated that the assertion syntax for nowMatch could also include GeneralizedTime
values so it seemed to have an implicitly understood value that fits
with the typical use of NULL.
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
workaround" that perhaps (mis)uses the nullValue.
</hypothetical_discussion>
The nowMatch rule is not, and cannot be, the equality matching rule
of timeAttr, so
(timeAttr=NOW) is bogus.
It's not bogus in case timeAttr is of gT-similar syntax. For that
reason we think the nowMatch matching rule needs to at least:
- support EQ-matching for attribute's of our generalizedTime-similar
syntax
- support EXT-matching for generalizedTime syntax attributes
Hopefully now our idea has become more obvious and hopefully it also
conforms to the directory specification - feedback is greatly
appreciated.
Background regarding the EQ matching support:
Next to LDAP search operations our current prototype also supports
NULL and OFFSET assertion values during add/delete/modify operations.
It's supported to use this assertion values for example via ldif
changes for (multi-value) attributes based on our
generalizedTime-similar syntax. To support multi-value handling an
appropriate equality rule has to exist and needs to be used. Therefore
we would like to see our new gT-similar syntax to support EQ-matching
using nowMatch to detect already existing values in multi-value
attributes...
This is one seriously convoluted syntax.
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
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.
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.
2.) MODIFY:
ldap_initialize( <DEFAULT> )
add timeAttr:
20100301000001Z
NULL
0#0#0#0#0#1
This is a use case that you haven't previously revealed or justified.
I've given a justification in this message, please see above.
Best regards,
Daniel
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext