John,
There are many design techniques that lead to attribute "mixtures" within a same entry and the possilities for something to go wrong are countless. I don't see why attribute re-use would be evil ;-) while subclasses or aux. class attachment would not. We just need to design our applications in the idea that a shared repository is always a source of surprises.
Regards,
Mircea.
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Thursday, September 18, 2003 1:30 PM
To: 'Pana, Mircea'; John Strassner; 'policy@ietf.org'
Subject: RE: Trouble with attributes
Mircea,
Perhaps I should have been clearer. I agree, there's nothing in LDAP or X.500 that prevents you doing what you've done. My point was that in my opinion, it is a poor design to do that.
Trust me, I know how to write an LDAP filter. J But you're putting all of the burden on the client in your approach. Furthermore, how are you going to write your schema? PCELS is, in my opinion, not an extension but rather a redesign. This is fine, but in this case I would have expected to see a stand-alone schema for PCELS. Does that make sense?
regards,
John
John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO 80906 USA
phone: +1.791.785.0648
fax: +1.719.785.0644
email: john.strassner@intelliden.com
-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Thursday, September 18, 2003 10:56 AM
To: 'John Strassner'; 'policy@ietf.org'
Subject: RE: Trouble with attributes
John,
I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time.
Respectfully,
Mircea.
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org'
Cc: 'rmoats@lemurnetworks.net'; 'David McTavish'
Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS
Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. J
John originally wrote:
With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.
Mircea replied:
<mircea>
Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that?</mircea>
John replied back:
<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible?
</js>
Mircea replied back:
<mircea2>The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2>
John's hopefully final reply:
<js2>
This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted.
I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else.
</js>
Yet Mircea replies:
<mircea3>
BTW: I am commenting on PCELS -03 published in August 2003.
On (1) above:
The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error.
On (2) above:
- LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse.
- An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set.
</mircea3>
Respectfully,
Mircea.