Re: [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