RE: RE: Trouble with attributes
David McTavish <[email protected]> Mon, 22 Sep 2003 13:46:13 -0400
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38131.6AA366A0 Content-Type: text/plain; charset="iso-8859-1" I agree with Mircea in this regard. I have no problem with a particular LDAP class having multiple auxiliary classes which may have overlapping attributes. Searching LDAP should focus on matching the desired objectClass instead of on an attribute level. The only problem I could foresee is if each auxiliary class inferred a different meaning into the values specified in the overlapping attribute, but seeming that the description for the attribute is embedded directly to the attribute, this should not be the case. d. -----Original Message----- From: Pana, Mircea [mailto:[email protected]] Sent: Monday, September 22, 2003 1:09 PM To: John Strassner; '[email protected]' Subject: [Policy] RE: Trouble with attributes 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:[email protected] <mailto:[email protected]> ] Sent: Thursday, September 18, 2003 1:30 PM To: 'Pana, Mircea'; John Strassner; '[email protected]' 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: [email protected] -----Original Message----- From: Pana, Mircea [ mailto:[email protected] <mailto:[email protected]> ] Sent: Thursday, September 18, 2003 10:56 AM To: 'John Strassner'; '[email protected]' 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:[email protected] <mailto:[email protected]> ] Sent: Wednesday, September 17, 2003 1:43 PM To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; '[email protected]' Cc: '[email protected]'; '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. ------_=_NextPart_001_01C38131.6AA366A0 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>RE: Trouble with attributes</TITLE> <META content="MSHTML 6.00.2800.1226" name=GENERATOR></HEAD> <BODY> <DIV><SPAN class=823134317-22092003><FONT face="Courier New" size=2>I agree with Mircea in this regard. I have no problem with a particular LDAP class having multiple auxiliary classes which may have overlapping attributes. Searching LDAP should focus on matching the desired objectClass instead of on an attribute level. The only problem I could foresee is if each auxiliary class inferred a different meaning into the values specified in the overlapping attribute, but seeming that the description for the attribute is embedded directly to the attribute, this should not be the case.</FONT></SPAN></DIV> <DIV><SPAN class=823134317-22092003><FONT face="Courier New" size=2></FONT></SPAN> </DIV> <DIV><SPAN class=823134317-22092003><FONT face="Courier New" size=2>d.</FONT></SPAN></DIV> <DIV><SPAN class=823134317-22092003><FONT face="Courier New" size=2></FONT></SPAN> </DIV> <DIV><SPAN class=823134317-22092003><FONT face="Courier New" size=2></FONT></SPAN> </DIV> <DIV><SPAN class=823134317-22092003><FONT face="Courier New" size=2></FONT></SPAN> </DIV> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Pana, Mircea [mailto:[email protected]]<BR><B>Sent:</B> Monday, September 22, 2003 1:09 PM<BR><B>To:</B> John Strassner; '[email protected]'<BR><B>Subject:</B> [Policy] RE: Trouble with attributes<BR><BR></FONT></DIV> <P><FONT size=2>John,</FONT> </P> <P><FONT size=2>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.</FONT></P> <P><FONT size=2>Regards,</FONT> <BR><FONT size=2>Mircea.</FONT> </P> <P><FONT size=2> -----Original Message-----</FONT> <BR><FONT size=2>From: John Strassner [<A href="mailto:[email protected]">mailto:[email protected]</A>]</FONT> <BR><FONT size=2>Sent: Thursday, September 18, 2003 1:30 PM</FONT> <BR><FONT size=2>To: 'Pana, Mircea'; John Strassner; '[email protected]'</FONT> <BR><FONT size=2>Subject: RE: Trouble with attributes</FONT> </P><BR> <P><FONT size=2>Mircea,</FONT> </P> <P><FONT size=2>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.</FONT></P> <P><FONT size=2>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?</FONT></P><BR> <P><FONT size=2>regards,</FONT> <BR><FONT size=2>John</FONT> </P> <P><FONT size=2>John C. Strassner</FONT> <BR><FONT size=2>Chief Strategy Officer</FONT> <BR><FONT size=2>Intelliden Inc.</FONT> <BR><FONT size=2>90 South Cascade Avenue</FONT> <BR><FONT size=2>Colorado Springs, CO 80906 USA</FONT> <BR><FONT size=2>phone: +1.791.785.0648</FONT> <BR><FONT size=2> fax: +1.719.785.0644</FONT> <BR><FONT size=2>email: [email protected]</FONT> </P> <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Pana, Mircea [<A href="mailto:[email protected]">mailto:[email protected]</A>] </FONT><BR><FONT size=2>Sent: Thursday, September 18, 2003 10:56 AM</FONT> <BR><FONT size=2>To: 'John Strassner'; '[email protected]'</FONT> <BR><FONT size=2>Subject: RE: Trouble with attributes</FONT> </P> <P><FONT size=2>John,</FONT> </P> <P><FONT size=2>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.</FONT></P> <P><FONT size=2>Respectfully,</FONT> <BR><FONT size=2>Mircea.</FONT> <BR><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: John Strassner [<A href="mailto:[email protected]">mailto:[email protected]</A>]</FONT> <BR><FONT size=2>Sent: Wednesday, September 17, 2003 1:43 PM</FONT> <BR><FONT size=2>To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; '[email protected]'</FONT> <BR><FONT size=2>Cc: '[email protected]'; 'David McTavish'</FONT> <BR><FONT size=2>Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS</FONT> <BR><FONT size=2>Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. J</FONT> <BR><FONT size=2>John originally wrote:</FONT> <BR><FONT size=2>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. </FONT></P> <P><FONT size=2>Mircea replied:</FONT> <BR><FONT size=2><mircea> </FONT><BR><FONT size=2>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></FONT></P> <P><FONT size=2>John replied back:</FONT> <BR><FONT size=2><js></FONT> <BR><FONT size=2>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?</FONT></P> <P><FONT size=2></js> </FONT><BR><FONT size=2>Mircea replied back:</FONT> <BR><FONT size=2><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> </FONT></P> <P><FONT size=2>John's hopefully final reply:</FONT> <BR><FONT size=2><js2></FONT> <BR><FONT size=2>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.</FONT></P> <P><FONT size=2>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.</FONT></P> <P><FONT size=2></js> </FONT></P> <P><FONT size=2>Yet Mircea replies: </FONT><BR><FONT size=2><mircea3></FONT> <BR><FONT size=2>BTW: I am commenting on PCELS -03 published in August 2003.</FONT> <BR><FONT size=2>On (1) above:</FONT> <BR><FONT size=2> 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.</FONT></P> <P><FONT size=2>On (2) above:</FONT> <BR><FONT size=2>- 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.</FONT></P> <P><FONT size=2>- 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.</FONT></P> <P><FONT size=2></mircea3> </FONT></P> <P><FONT size=2>Respectfully,</FONT> <BR><FONT size=2>Mircea.</FONT> </P></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C38131.6AA366A0--