RE: Trouble with attributes
John Strassner <[email protected]> Thu, 18 Sep 2003 11:29:40 -0600
| 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_01C37E0A.70E8BEE0 Content-Type: text/plain 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. :-) 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]] 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]] 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. :-) 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_01C37E0A.70E8BEE0 Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 10 (filtered)"> <title>RE: [Policy] PCLS classes deprecated in PCELS</title> <style> <!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} p {margin-right:0in; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman";} p.Numbered, li.Numbered, div.Numbered {margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.8in; margin-bottom:.0001pt; text-indent:-.25in; line-height:200%; font-size:10.0pt; font-family:"Times New Roman";} p.Bulletted, li.Bulletted, div.Bulletted {margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:1.5in; margin-bottom:.0001pt; text-indent:-.25in; line-height:200%; font-size:10.0pt; font-family:"Times New Roman";} p.numbered0, li.numbered0, div.numbered0 {margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.8in; margin-bottom:.0001pt; text-indent:-.25in; line-height:200%; font-size:10.0pt; font-family:"Times New Roman";} p.bulletted0, li.bulletted0, div.bulletted0 {margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:1.5in; margin-bottom:.0001pt; text-indent:-.25in; line-height:200%; font-size:10.0pt; font-family:"Times New Roman";} p.numbered00, li.numbered00, div.numbered00 {margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.8in; margin-bottom:.0001pt; text-indent:-.25in; line-height:200%; font-size:10.0pt; font-family:"Times New Roman";} p.bulletted00, li.bulletted00, div.bulletted00 {margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:1.5in; margin-bottom:.0001pt; text-indent:-.25in; line-height:200%; font-size:10.0pt; font-family:"Times New Roman";} span.emailstyle20 {font-family:Arial; color:navy;} span.emailstyle24 {font-family:Arial; color:navy;} span.EmailStyle27 {font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> </style> </head> <body lang=EN-US link=blue vlink=blue> <div class=Section1> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>Mircea,</span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'> </span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>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.</span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'> </span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>Trust me, I know how to write an LDAP filter. </span></font><font size=2 color=navy face=Wingdings><span style='font-size:10.0pt;font-family:Wingdings;color:navy'>J</span></font><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial; color:navy'> 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?</span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'> </span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'> </span></font></p> <div> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span style='font-size:12.0pt;color:navy'>regards,<br> John</span></font></p> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span style='font-size:12.0pt;color:navy'> </span></font></p> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span style='font-size:12.0pt;color:navy'>John C. Strassner</span></font></p> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span style='font-size:12.0pt;color:navy'>Chief Strategy Officer</span></font></p> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span style='font-size:12.0pt;color:navy'>Intelliden Inc.</span></font></p> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span style='font-size:12.0pt;color:navy'>90 South Cascade Avenue</span></font></p> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span style='font-size:12.0pt;color:navy'>Colorado Springs, CO 80906 USA</span></font></p> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span lang=FR style='font-size:12.0pt;color:navy'>phone: +1.791.785.0648</span></font></p> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span lang=FR style='font-size:12.0pt;color:navy'> fax: +1.719.785.0644</span></font></p> <p class=MsoAutoSig><font size=3 color=navy face="Times New Roman"><span lang=FR style='font-size:12.0pt;color:navy'>email: [email protected]</span></font></p> </div> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=FR style='font-size:10.0pt;font-family:Arial;color:navy'> </span></font></p> <div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'> <p class=MsoNormal><font size=2 face=Tahoma><span style='font-size:10.0pt; font-family:Tahoma'>-----Original Message-----<br> <b><span style='font-weight:bold'>From:</span></b> Pana, Mircea [mailto:[email protected]] <br> <b><span style='font-weight:bold'>Sent:</span></b> Thursday, September 18, 2003 10:56 AM<br> <b><span style='font-weight:bold'>To:</span></b> 'John Strassner'; '[email protected]'<br> <b><span style='font-weight:bold'>Subject:</span></b> RE: Trouble with attributes</span></font></p> <p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size: 12.0pt'> </span></font></p> <div> <p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:blue'>John,</span></font></p> </div> <div> <p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size: 12.0pt'> </span></font></p> </div> <div> <p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:blue'>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.</span></font></p> </div> <div> <p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size: 12.0pt'> </span></font></p> </div> <div> <p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:blue'>Respectfully,</span></font></p> </div> <div> <p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:blue'>Mircea.</span></font></p> </div> <blockquote style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt; margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'> <p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----<br> <b><span style='font-weight:bold'>From:</span></b> John Strassner [mailto:[email protected]]<br> <b><span style='font-weight:bold'>Sent:</span></b> Wednesday, September 17, 2003 1:43 PM<br> <b><span style='font-weight:bold'>To:</span></b> Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; '[email protected]'<br> <b><span style='font-weight:bold'>Cc:</span></b> '[email protected]'; 'David McTavish'<br> <b><span style='font-weight:bold'>Subject:</span></b> Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS</span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. </span></font><font size=2 color=navy face=Wingdings><span style='font-size:10.0pt;font-family: Wingdings;color:navy'>J</span></font></p> <p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>John originally wrote:<br> 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. </span></font></p> <p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>Mircea replied:<br> <mircea></span></font> <br> <font size=2><span style='font-size:10.0pt'>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></span></font></p> <p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family: Arial;color:navy'>John replied back:<br> <js><br> 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?<br> </js></span></font><font size=2 color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;color:blue'> </span></font></p> <p><font size=2 color=blue face=Arial><span style='font-size:10.0pt;font-family: Arial;color:blue'>Mircea replied back:<br> <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></span></font><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial; color:navy'> </span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>John's hopefully final reply:<br> <js2><br> 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.<br> <br> 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.<br> </js></span></font><font size=2 color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;color:blue'> </span></font></p> <p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size: 12.0pt'> </span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>Yet Mircea replies: </span></font></p> <p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:blue'><mircea3></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>BTW: I am commenting on PCELS -03 published in August 2003.</span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>On (1) above:</span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'> The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "</span></font><font size=2 color=black face=Arial><span style='font-size:10.0pt;font-family:Arial;color:black'>Its attributes are defined in the section 5.4 of the [PCLS].</span></font><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;color:navy'>" 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.</span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>On (2) above:</span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>- 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.</span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>- 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.</span></font></p> <p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:blue'></mircea3></span></font><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial; color:navy'> </span></font></p> <p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size: 12.0pt'> </span></font></p> <div> <p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:blue'>Respectfully,</span></font></p> </div> <div> <p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:blue'>Mircea.</span></font></p> </div> </blockquote> </div> </div> </body> </html> ------_=_NextPart_001_01C37E0A.70E8BEE0--