Re: Attribute Name Length Bounds

[Ryan Moats <rmoats@lemurnetworks.net>]

On Thu, Jul 17, 2003 at 01:40:49PM -0600, Jim Sermersheim wrote:
| I also see that we could just add "or exceed server limits" to the end
| of the phrase "or the encoding structures or lengths of data fields are
| found to be incorrect" in the first paragraph. But I'm not sure...
|  
| This section talks about data that is either malformed or cannot be/is
| not  recognized, so it seems like a good fit. It splits the problems
| into two classes (those that cause the connection to terminate, and
| those that simply return protocolError).
|  
| Adding the change above causes a connection termination. The change Bob
| suggests allows one to differentiate between something that looks like
| an attack (say some size is 20gb), and something that simply exceeds a
| small limit, and act accordingly.
|  
| Which seems more correct to others (and do both seem incorrect to
| anyone)?
|  
| While I think this is a good fix to add, does it fix the problem? After
| reading http://www.openldap.org/lists/ietf-ldapbis/200306/msg00065.html
| the answer is "Yes". Then when I read
| http://www.openldap.org/lists/ietf-ldapbis/200306/msg00071.html, it
| seems to say "Not really". 
| Does requiring the server to return an error when it can't handle a
| too-big attribute name solve this particular problem? If not--and we
| still want to talk about mandatory minimums for schema names, we need to
| do it in the context of [Models].

Speaking as a schema designer, this doesn't help me because it doesn't
address the fundamental issue of ensuring that the proposed schema works
on an implementation.  I don't see how a schema designer can have any
confidence that a schema will work unless there is a mandatory minimum.

Ryan Moats