|
A couple other considerations dealing with approach 2
are:
- It allows an ATO (attribute type option) to be tied to any
attribute that is of a given syntax.
- This type of not-so-easy-searching already has to be done
for name forms, content rules, and structure rules. This follows the existing
paradigm. I will say however, that I don't much like the existing paradigm as
far as name forms and structure rules are concerned, I'd rather see that info in
the object class. Oh well, side issue...
An issue with approach 1: - Whether a server supports ATOs will largely be due to
built-in support (unless a plug-in architecture is provided by the vendor). If
the advertisement of the support is on the attributetype, who will populate it?
In other words, If I extend the schema to include a new attributetype, Am I
expected to supply the supported ATOs? What if I do, and the server can't handle
them? Does the server auto-fill attributetypes with unspecified ATOs that it can
support?
Jim
>>> <hahnt@us.ibm.com> 9/16/00 5:00:50 AM >>> Hi all, I like the idea of extending the schema information with the set of attribute descriptions that are known to the server. Both approaches described so far: 1) extend the attributeTypes value to allow for additional fields to be specified within each value, add a new value that defines the OIDs used in the field 2) add a new attribute to the subschemasubentry and contain all the information here are in the right direction. Approach 1) has the benefit that just by looking at the attributeType value, you can get an indication if any attribute descriptions might have been used in creating/modifying entries that contain this attribute. However, there would be the issue of whether or not the server supported the additional data in the attributeTypes value. Approach 2) doesn't change the attributeType value definition (nice for upward compatibility). On the downside, though, in order to see what attribute description a given attribute type can have attached to it, a not-so-easy-search of the new schema attribute would have to be performed. After writing up this short discussion of the approaches, I think I prefer Approach 1) where the "DESCRIPTORS ( <OID> "$" ... )" clause of the attributeTypes value is an optional piece in the format of the value. Is there agreement here? Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 To:
"Jim Sermersheim"
<JIMSE@novell.com> |