Pete Rowley <prowley <at> redhat.com> writes: > > >When I apply the caseExactMatch definition to the attribute, I expected it to > >enforce the matching rule. However it did not seem to have any effect. I > >tested it both with the schema checking on and off. I ended up using the > >default attributeType and I just changed the SYNTAX to > >1.3.6.1.4.1.1466.115.121.1.26. > >This seems to enforce the case for the uid. I think I was under the mis- > >understanding that I could tweak the attribute type specifically to meet my > >sites needs. I have been reading up on the CoS and I think this is where I > >went wrong. Is there an alternate method to provide granular control over > >attributeTypes, or is the FDS tied to the CoS model? The entry I am talking > >about is listed below. Thanks > > > > > Class of service has nothing to do with schema. It is a mechanism for > sharing attribute / value pairs among a group of entries so that an > administrator has one place to change those attribute value pairs. The > only place CoS gets involved with schema is when schema checking is on, > when it will ensure the attribute / value pairs it provides are allowed > to appear in the entry. > > I am at a loss to explain why changing the syntax from DirectoryString > to IA5String would suddenly produce the results you were expecting. Are > you restarting the server between changes to the schema files? > Well if that is the case and there is no underlying mechanisims that I was exluding I am really discouraged with the ability to provide customization. Do you see anyting wrong with how I attempted to define the attribute that could have been causing the issue? It has to be something I am leaving out. Yes I restarted everytime. The onlytime I can get it to enforce the case is with the IA5String. Since the IA5String seems to be working, do you see any problem with me leaving it defined? Thanks again
