Subject: Protocol: modification items may violate schema

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 05 Sep 2003 12:45:56 -0600

All,

An issue has been raised regarding the language in 4.6:

"While individual modifications may violate the directory schema, the
resulting entry after the entire list of modifications is performed MUST
conform to the requirements of the directory schema."

While I believe most server implementors understand this to mean that
while any one modification item may cause an object class violation, the
entire set of modifications must be evaluated an no error returned if
the net effect would not violate schema.

For example, in one test it is expected that given the entry
(singleValAttr is a SINGLE-VALUE attribute):

dn: dc=example
objectclass: x
singleValAttr: val1

the following modify should not error:
dn: dc=example
changetype: modify
add: singleValAttr
singleValAttr: val2
-
delete: singleValAttr
singleValAttr: val1

While it's obvious that the net effect is to have a single value (val2)
in singleValAttr, because the order is backward, a server doesn't like
it.

Other examples might include:
- Deleting a distinguished name value and re-adding the same value
- Adding an attribute value of invalid syntax and then removing it.
- Adding a value that would produce contraintViolation, then removing
it.

Regarding the statement above: I've always read this as a requirement
on the data being presented to the server--that at least the resulting
entry MUST conform. I haven't (until recently) thought about it as a
requirement that the server allow silly things to be present in a list
of modification items.

What do others feel? Is there a need for clarity here? Are these kinds
of tests valid indicators of standards-compliance?

Jim

---

From: Timothy Hahn <[email-masked]>
Date: Fri, 5 Sep 2003 15:25:28 -0400

Jim,

I had always interepreted this as indicating that even if "silly things" 
are done in some of the modificationItems, that the server shouldn't 
necessarily fail the modification because an "intermediate result" was not 
compliant to the schema definitions.

Re-stated, an entry in the process of being modified (within an atomic 
operation) is allowed to be non-compliant to the schema, but by the end of 
applying all the modifications (at the end of the atomic operation) the 
entry MUST be schema compliant.

That's how I always interpreted it.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Durham/IBM@IBMUS
phone: 919.224.1565     tie-line: 8/687.1565
fax: 919.224.2540

"Jim Sermersheim" <[email-masked]>
Sent by: [email-masked]
09/05/2003 02:45 PM
 
        To:     <[email-masked]>
        cc:     "Duane Buss" <[email-masked]>, "Vithalprasad Gaitonde" 
<[email-masked]>, "Joseph Cook" <[email-masked]>, "Jim 
Schnitter" <[email-masked]>, "Mike Cronquist" 
<[email-masked]>, "Richard Ellis" <[email-masked]>, "Steve 
McLain" <[email-masked]>, "Parameswaran S" <[email-masked]>, 
"Susan Perrin" <[email-masked]>
        Subject:        Protocol: modification items may violate schema

All,

dn: dc=example
objectclass: x
singleValAttr: val1

Jim

---

From: "Mark Smith" <[email-masked]>
Date: Fri, 5 Sep 2003 16:27:17 -0400

Timothy
Hahn wrote:

Jim,

I had always interepreted
this as indicating
that even if "silly things" are done in some of the modificationItems,
that the server shouldn't necessarily fail the modification because an
"intermediate result" was not compliant to the schema definitions.

Re-stated, an entry in the
process of
being modified (within an atomic operation) is allowed to be
non-compliant
to the schema, but by the end of applying all the modifications (at the
end of the atomic operation) the entry MUST be schema compliant.

That's how I always
interpreted it.

Me too.  Another way to
look at (from the server implementor's perspective) is that some kinds
of schema checks may only be done on the "final" entry that results
from application of all of the items in the modify operation.

-Mark