|
Well, as long as we're on the topic...
Models doesn't give state whether a DIT content rule applies only to the structural object class it names, or if it is inherited to subclasses of that object class (there may be some inferences, but nothing obvious). >From memory, I think X.500 says DIT content rules only apply to the structural object class named in the DIT content rule (no inheritance). Whatever the case may be, It should probably be called out in Models to avoid confusion.
Jim
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 2/11/04 5:37:19 PM >>> At 01:54 PM 2/11/2004, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> For instance, it is quite clear in X.501 that which auxiliary >> classes an entry can belongs to is controlled solely by the >> DIT Content Rule. However, the entry's structural object >> class has a auxiliary super class, then the entry belong to >> that auxiliary class even when the DIT content rule disallows >> it from belong to that auxiliary class. > >I guess that would mean that an entry of that structural object class >cannot be created unless a DIT content rule allows the auxiliary class. Or one could argue that's not necessary because its controlled through the structural object class of the entry. That is, it can be argued that a DIT content rules only controls the optional set of auxiliary classes an entry may belong to. As any entry of this structural class must belong to this auxiliary class, it not subject to the DIT content rule. My point here is that someone would need to engineer how such subclassing should work. That's a tall order when you consider that not only did X.501 not explicitly disallow Structurals from subclassing Auxiliaries, it did not explicitly disallow Auxiliaries from subclassing Structurals. Even if we were to only allow the former category, sections 8, 12, and 14 of X.501 would need to be significantly revised. That is, the alternative to stating these restrictions is not simple removal of the restrictions. The alternative is to revise the technical specification such that the model make sense in the face of such subclassing and that it is clear how implementations are to behave. The WG considered this alternative during the WG Last Call and rejected it. Hence, at this point, if there are those who believe strongly that this alternative should have been taken, that they (on an individual basis) write an I-D making sense of such subclassing. That is, I don't think the WG should revisit this issue in absence of a specific alternative text. That text should attempt to address the underlying problems with X.501 which caused the restrictions to be added in the first place. Kurt |