Subject: correct modifiersName and modifyTimeStamp behavior?

From: Mark Smith <[email-masked]>
Date: Wed, 04 Aug 1999 10:39:02 -0400

When should an LDAP server add or update the values for modifiersName
and modifyTimeStamp within an entry?  Some choices:

(a) During all successful update operations except delete (add, modify,
moddn).

(b) During all successful modify and moddn operations (but not when the
entry is added).

(c) During successful modify operations only.

Our server does (a) but some people say we should be doing (b) or (c)
(and that clients that count on the presence of modifyTimeStamp or
modifiersName values within newly added entries are broken).  The
standards are not 100% clear.  RFCs 2251 and 2252 seem to say that (c)
is the right answer.  X.501 implies (c) but there is a note in X.511
under the modDN description that says "The modifyTimeStamp attribute is
not updated for entries subordinate to the renamed or moved entry." This
implies that modifyTimeStamp should be updated in the entry that is
renamed (choice b).

Opinions?  I'd like to see this clarified in future updates to RFC 2251
and/or 2252.
 
-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: "MIRCEA PANA" <[email-masked]>
Date: Wed, 04 Aug 1999 12:12:03 -0400

When it comes to (custom) directory synchronization, the option (a) looks to
be the most performant one.

E.G.: In order to detect and retrieve all the entries that have beed added,
modified or moved (moddn) in the Directory since "lastTime", the search
filter for option (a) could be: "(modifyTimeStamp>=lastTime)".
...while, for option (b) or (c), the search filter would have to look like:
"|(modifyTimeStamp>=lastTime)(createTimeStamp>=lastTime)"
which  may be a less efficient operation.

However an option (a) implementation is missing the capability to search for
entries added (or moddn) but unmodified since "lastTime". Would this be an
important (and popular) requirement?

Thanks,
Mircea.

---

From: Mark Wahl <[email-masked]>
Date: Wed, 04 Aug 1999 14:09:24 -0500

Given that it is not clear in  X.500 I would recommend that we 
 1) submit a 'defect report' on X.501 to clarify exactly what operations 
    cause user-visible operational attributes to be updated, then
 2) copy this clarification into the following update to 2251.

Would you like to submit the defect report to the X.500 committee?

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: Mark Smith <[email-masked]>
Date: Thu, 05 Aug 1999 11:53:01 -0400

> Would you like to submit the defect report to the X.500 committee?

Great suggestion.  Since I've never submitted an X.500 defect report,
I'll need to do some research into the process.  But I'll work on this
fairly soon and share the text with the LDAPEXT list before I submit it.

---

From: Mark Wahl <[email-masked]>
Date: Thu, 05 Aug 1999 11:08:19 -0500

> fairly soon and share the text with the LDAPEXT list before I submit it.

The easiest way is to get the Word file 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/ImplementorGuideV12

and look near the back for the proforma defect report as well as the email 
addresses of the person to whom you should send it.

---

From: "David Chadwick" <[email-masked]>
Date: Thu, 5 Aug 1999 19:52:09 +0100

Date forwarded: 	Wed, 4 Aug 1999 07:39:11 -0700 (PDT)
Date sent:      	Wed, 04 Aug 1999 10:39:02 -0400
From:           	Mark Smith <[email-masked]>
Organization:   	Netscape Communications
To:             	[email-masked]
Subject:        	correct modifiersName and modifyTimeStamp behavior?
Forwarded by:   	[email-masked]

Mark,

I have taken the liberty of forwarding this message to the X.500 
group, but I agree that the standard is not precise. I would probably 
plump for option b) below, but I can also see an argument for a). I 
can say quite definately that c) was never intended. I think you 
would be perfectly in order to raise a defect report on this asking for 
clarification. Do you have the proforma for this?

David

> When should an LDAP server add or update the values for modifiersName and
> modifyTimeStamp within an entry?  Some choices:
> 
> Our server does (a) but some people say we should be doing (b) or (c) (and
> that clients that count on the presence of modifyTimeStamp or
> standards are not 100% clear.  RFCs 2251 and 2252 seem to say that (c) is
> the right answer.  X.501 implies (c) but there is a note in X.511 under
> the modDN description that says "The modifyTimeStamp attribute is not
> updated for entries subordinate to the renamed or moved entry." This

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email [email-masked] *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: Helmut Volpers <[email-masked]>
Date: Mon, 09 Aug 1999 13:00:21 +0200

Hi all,

Our server does (b) and that is how I interpret the X.500
standard.

Helmut

---

From: [email-masked] (Mark C Smith)
Date: Thu, 12 Aug 1999 14:47:09 -0400

> fairly soon and share the text with the LDAPEXT list before I submit it.

An update for the group:  I submitted the defect report today.  Since
the "Nature of Defect" portion of my report ended up being nearly
identical to what I posted on this mailing list a week ago, I didn't see
any need to present the text to this list prior to submission.  The
message I sent is attached, along with a plain text version of the
defect report (the original message contains Microsoft Word and HTML
versions; MSWord is the requested format).  I suppose in time I will
receive a response, although that does not seem to be guaranteed by the
defect process itself.

Subject: X.501 defect report: Procedures for updating modifiersName and modifiedTimeStamp
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Thu, 12 Aug 1999 14:34:56 -0400

A defect report for X.501 is attached:

   "Procedures for updating modifiersName and modifiedTimeStamp"

I included both a Microsoft Word97 and an HTML version.  Let me know if
you have any questions.  Thanks!

Defect Report Form

Please also send a soft copy of the defect in Microsoft
Word format to the Defect Editor ([email-masked]).

DEFECT REPORT FORM

1. Defect Report Number:

Title: Procedures for updating modifiersName and
modifiedTimeStamp

2. Source: Mark Smith <[email-masked]>

3. Addressed to:

ISO/IEC JTC1/SC6 and ITU-T SG 7

Editor Group on the Directory

4. (a) WG Secretariat: UK (BSI)

(b) ITU-T WP: WP 4

5. Date Circulated by WG Secretariat:

6. Deadline for Response from Editor:

7. Defect Report Concerning: X.501 "THE DIRECTORY:
MODELS"

8. Qualifier: clarification required

9. References in Document: section 13.4.1 "Timestamps"
and section 13.4.2 "Entry Modifier operational attributes."

10. Nature of Defect:

A request for clarification: when should a DSA add or
update the values for modifiersName and modifyTimeStamp within an entry?
Some choices:

(a) During all successful update operations except delete
(that is, during all add, modify, and modifyDN operations).

(b) During all successful modify and modifyDN operations
(but not when the entry is added).

Our DSA does (a) but some people say we should be doing
(b) or (c) (and that DUAs that count on the presence of modifyTimeStamp
or modifiersName attribute values within newly added entries are broken).
The standards are not 100% clear. X.501 implies (c) because it uses the
phrase "last modified" when referring to these attributes. But Note 6 in
X.511 section 11.4.1 "Modify DN syntax" says "The modifyTimeStamp attribute
is not updated for entries subordinate to the renamed or moved entry."
This implies that modifyTimeStamp should be updated in the entry that is
renamed (that is, choice (a) or choice (b) is correct). David Chadwick
assured me that choice (c) was not the intent.

11. Solution Proposed by the Source: (optional)

For the sake of DUAs and consistency of the information
model, I believe the best choice of behavior is (a) above. This could be
accommodated in the standard by replacing this text from X.501 section
13.4.1:

"The modifyTimeStamp indicates the time that an entry
was last modified: …"

with this text:

"The modifyTimeStamp indicates the time that an entry
was added, last modified, or last renamed: …"

Similarly for X.501 section 13.4.2, replace this text:

"The modifiersName operational attribute indicates the
distinguished name of the Directory user that last modified the entry:
…"

with this text:

"The modifiersName operational attribute indicates
the distinguished name of the Directory user that added, last modified,
or last renamed the entry: …"

12. Editor's Response:

                             Defect Report Form

Please also send a soft copy of the defect in Microsoft Word format to the
Defect Editor ([email-masked]).

                             DEFECT REPORT FORM

1. Defect Report Number:

   Title: Procedures for updating modifiersName and modifiedTimeStamp

2. Source: Mark Smith <[email-masked]>

3. Addressed to:

     ISO/IEC JTC1/SC6 and ITU-T SG 7
     Editor Group on the Directory

4. (a) WG Secretariat: UK (BSI)

   (b) ITU-T WP: WP 4

5. Date Circulated by WG Secretariat:

6. Deadline for Response from Editor:

7. Defect Report Concerning: X.501 "THE DIRECTORY: MODELS"

8. Qualifier: clarification required

9. References in Document: section 13.4.1 "Timestamps" and section 13.4.2
"Entry Modifier operational attributes."

10. Nature of Defect:

A request for clarification: when should a DSA add or update the values for
modifiersName and modifyTimeStamp within an entry? Some choices:

(a) During all successful update operations except delete (that is, during
all add, modify, and modifyDN operations).

(b) During all successful modify and modifyDN operations (but not when the
entry is added).

Our DSA does (a) but some people say we should be doing (b) or (c) (and
that DUAs that count on the presence of modifyTimeStamp or modifiersName
attribute values within newly added entries are broken). The standards are
not 100% clear. X.501 implies (c) because it uses the phrase "last
modified" when referring to these attributes. But Note 6 in X.511 section
11.4.1 "Modify DN syntax" says "The modifyTimeStamp attribute is not
updated for entries subordinate to the renamed or moved entry." This
implies that modifyTimeStamp should be updated in the entry that is renamed
(that is, choice (a) or choice (b) is correct). David Chadwick assured me
that choice (c) was not the intent.

11. Solution Proposed by the Source: (optional)

For the sake of DUAs and consistency of the information model, I believe
the best choice of behavior is (a) above. This could be accommodated in the
standard by replacing this text from X.501 section 13.4.1:

"The modifyTimeStamp indicates the time that an entry was last modified: ..."

with this text:

"The modifyTimeStamp indicates the time that an entry was added, last
modified, or last renamed: ..."

Similarly for X.501 section 13.4.2, replace this text:

"The modifiersName operational attribute indicates the distinguished name
of the Directory user that last modified the entry: ..."

with this text:

"The modifiersName operational attribute indicates the distinguished name
of the Directory user that added, last modified, or last renamed the entry:
..."

12. Editor's Response: