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.