|
Let me pose some silliness and wonder at how to deal with it.
An attribute called X is of syntax integer
A modify adds the value "1#qrs#5" to X, then deletes the value "1#xyz#5"
from X
The server tries to evaluate the two values being updated on X. Neither
of them are integers, thus it can't use its normal compare routines to check
for equality. I suppose the server could (in the event of syntax violations)
fail over to using an exact octet match.
While the server is gathering up these modifications (in order to later
commit them), I guess it can't hold the attribute values in a syntax-based
data structure, because it can't rely on the values adhering to the
syntax.
I think there's something even more ugly, but I can't think of it
now...
Jim
>>> Timothy Hahn <hahnt@us.ibm.com> 9/5/03
1:25:28 PM >>>
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: hahnt@us.ibm.com
Internal: Timothy
Hahn/Durham/IBM@IBMUS
phone: 919.224.1565 tie-line:
8/687.1565
fax: 919.224.2540
|
| "Jim Sermersheim"
<jimse@novell.com>
Sent by: owner-ietf-ldapbis@OpenLDAP.org
09/05/2003 02:45 PM
|
To:
<ietf-ldapbis@OpenLDAP.org>
cc:
"Duane Buss" <DBuss@novell.com>, "Vithalprasad
Gaitonde" <GVithalprasad@novell.com>, "Joseph Cook"
<JCook@novell.com>, "Jim Schnitter" <JSchnitter@novell.com>,
"Mike Cronquist" <MCRONQUIST@novell.com>, "Richard Ellis"
<RELLIS@novell.com>, "Steve McLain" <SMCLAIN@novell.com>,
"Parameswaran S" <SPARAMESH@novell.com>, "Susan Perrin"
<SPERRIN@novell.com>
Subject:
Protocol: modification items may violate
schema | All,
An issue
has been raised regarding the language in 4.6:
"While indi! vidual
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 distinguishe! d name v alue 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
I'm surprised this discussion is
still going on. X.511 is pretty clear on this - the result must conform, but it
is necessary to allow intermediate steps to violate the schema
On the other hand, Jim's example with
the bogus values for Add/Delete of an Integer attribute should fail immediately
due to Syntax violation. The point is that temporary ObjectClass violations are
allowed, so long as the final object conforms to the requirements of its
ObjectClass, but other violations return errors immediately.
Also, from one of Jim's other
examples: removing an attribute or value that is part of the entry's RDN is
explicitly not allowed.
-- Howard
Chu
Chief Architect, Symas Corp.
Director, Highland Sun
http://www.symas.com
http://highlandsun.com/hyc
Symas: Premier OpenSource
Development and Support
|