Subject: RE: Protocol: modification items may violate schema

From: John McMeeking <[email-masked]>
Date: Sun, 7 Sep 2003 14:57:41 -0500

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 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.

John  McMeeking

                      Timothy                                                                                               
                      Hahn/Durham/IBM@IBMU        To:       [email-masked]                                       
                      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: [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:                      To:        <[email-masked]> 
      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" <[email-masked]> 9/5/03 5:09:52 PM >>>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jim Sermersheim
Sent: Friday, September 05, 2003 3:00 PM
To: [email-masked]
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 <[email-masked]> 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: [email-masked]
Internal: Timothy Hahn/Durham/IBM@IBMUS
phone: 919.224.1565     tie-line: 8/687.1565
fax: 919.224.2540

     "Jim                                                                  
     Sermersheim"                To:        <[email-masked]>    
     <jimse@novel                cc:        "Duane Buss"                   
     l.com>               <[email-masked]>, "Vithalprasad Gaitonde"      
     Sent by:             <[email-masked]>, "Joseph Cook"        
     owner-ietf-l         <[email-masked]>, "Jim Schnitter"              
     dapbis@OpenL         <[email-masked]>, "Mike Cronquist"        
     DAP.org              <[email-masked]>, "Richard Ellis"         
                          <[email-masked]>, "Steve McLain"              
     09/05/2003           <[email-masked]>, "Parameswaran S"           
     02:45 PM             <[email-masked]>, "Susan Perrin"           
                          <[email-masked]>                             
                                 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

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 8 Sep 2003 12:10:01 +1100

John,

> intermediate results should fail.  The final result, of course, cannot

I agree.

> 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

>                       Sent by:                    Subject:
> RE: Protocol: modification items may violate schema
>                       owner-ietf-ldapbis@O
>
>                       penLDAP.org
>
>
>
>
>
>                       09/05/2003 08:16 PM
>
>
>
>
>
>
>
>
>
>

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 8 Sep 2003 14:36:30 +0200

John McMeeking writes:
> I think a reasonable interpretation (clarification) is that
> intermediate results of a modify request are allowed to violate the
> object class definitions

and DIT content rules, or at least their MUST/MAY/NOT parts.

> but modifications that result in other errors during intermediate
> results should fail.  The final result, of course, cannot violate the
> schema.

-- 
Hallvard