[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Protocol: modification items may violate schema
John,
John McMeeking wrote:
> I think a reasonable interpretation (clarification) is that
> intermediate
> results of a modify request are allowed to violate the object class
> definitions, but modifications that result in other errors during
> intermediate results should fail. The final result, of course, cannot
> violate the schema.
I agree.
> I don't see a problem with allowing a server to not evaluate
> intermediate
> results, but a client really ought to order modications so that
> single-valuedness, for example, of an attribute is not
> violated, and I know
> of no reason why a server should be required to handle some
> of the "silly"
> changes described in earlier notes.
I agree again. Object class violations on intermediate results have
to be allowed otherwise certain object class definitions, for example
auxiliary classes with mandatory attributes, could never be satisfied.
Requiring servers to hold off on checking for the "silly" violations
imposes an implementation burden for no real gain.
Regards,
Steven
>
>
> John McMeeking
>
>
>
>
>
> Timothy
>
> Hahn/Durham/IBM@IBMU To:
> ietf-ldapbis@OpenLDAP.org
> S cc:
>
> Sent by: Subject:
> RE: Protocol: modification items may violate schema
> owner-ietf-ldapbis@O
>
> penLDAP.org
>
>
>
>
>
> 09/05/2003 08:16 PM
>
>
>
>
>
>
>
>
>
>
> I suspect that not all pathological cases were considered
> when the sentence
> was written.
>
> Thinking through this, I'd say that in light of "be lenient
> in what you
> accept and strict in what you emit", I think it would
> acceptable for an
> implementation to ALLOW such a case as is posed below -
> though I agree with
> you that supporting such behavior can be problematic.
>
> Of course, you'd want an implementation to not go overboard
> on such support
> (thinking in terms of denial of service types of "attacks" by sending
> servers valild LDAP protocol elements for the server to "chew
> on" but which
> don't really do anything useful - i.e. "silliness"). But I think this
> would result in an UNWILLING_TO_PERFORM error code rather than an
> SCHEMA_VIOLATION error code.
>
> 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: To:
> <ietf-ldapbis@OpenLDAP.org>
> owner-ietf-ldapbis@Open cc:
>
> LDAP.org Subject:
> RE: Protocol:
> modification items may
> violate schema
> 09/05/2003 07:18 PM
>
>
>
>
>
>
>
> Yes, this is what I'm trying to understand. Where RFC2251
> says "violate
> directory schema" does it really mean *any* schema violation, or is it
> talking only about those that would cause objectClassViolation?
> Jim
>
> >>> "Howard Chu" <hyc@highlandsun.com> 9/5/03 5:09:52 PM >>>
>
>
> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Jim Sermersheim
> Sent: Friday, September 05, 2003 3:00 PM
> To: ietf-ldapbis@OpenLDAP.org
> Subject: Re: Protocol: modification items may violate schema
>
> 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" To:
> <ietf-ldapbis@OpenLDAP.org>
> <jimse@novel cc: "Duane Buss"
>
> l.com> <DBuss@novell.com>, "Vithalprasad
> Gaitonde"
> Sent by: <GVithalprasad@novell.com>, "Joseph
> Cook"
> owner-ietf-l <JCook@novell.com>, "Jim Schnitter"
>
> dapbis@OpenL <JSchnitter@novell.com>, "Mike
> Cronquist"
> DAP.org <MCRONQUIST@novell.com>, "Richard
> Ellis"
> <RELLIS@novell.com>, "Steve McLain"
>
> 09/05/2003 <SMCLAIN@novell.com>, "Parameswaran
> S"
> 02:45 PM <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 a lue 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
>
>
>
>
> #### smime.p7s has been removed from this note on September
> 07, 2003 by
> John McMeeking
>
>
>
>