RE: PCLS classes deprecated in PCELS

Hmm. Clearly, PCELS classes that are not compatible with PCLS should use
their own prefix, a simple and time-honored way to separate class
hierarchies. However, I still worry about the rigidity and lack of
extensibility if we simply say "Here lies PCLS, and here lies PCELS. May
their paths never cross". The example given in my previous note regarding a
more generic (AND ABSTRACT) policyConditionAssociation, from which a more
specific policyConditionInPolicyRule, as well as a more specific
policyConditionInPolicyCondition are subclasses, seems infinitely better.

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: Ryan Moats [mailto:[email protected]]
> Sent: Friday, September 12, 2003 10:28 AM
> To: Pana, Mircea
> Cc: David McTavish; '[email protected]'
> Subject: Re: [Policy] PCLS classes deprecated in PCELS
> 
> On Fri, Sep 12, 2003 at 11:15:07AM -0500, Ryan Moats wrote:
> | On Fri, Sep 12, 2003 at 11:01:33AM -0500, Pana, Mircea wrote:
> | | I would like to understand why you have a problem with PCELS
> inserting a new
> | | class in the inheritance chain of a PCLS defined class.
> |
> | Because you've broken the binding between an LDAP object class's
> OID and
> | an that object class's name. Included in this binding is the
> superior
> | objectclass.  Therefore
> |
> | ( <oid> NAME "pcimRepository" SUP top )
> |
> | and
> |
> | ( <oid> NAME "pcimRepository" SUP pcimRulesContainer )
> |
> | are *NOT* the same from an LDAP point of view: they require
> different
> | OID and different names.
> |
> | Ryan
> 
> Actually, that is a solution for all of the subclass cases: in
> PCELS call
> tem pcime*, give them different OIDs from what's in PCLS and then
> everything
> is ok.
> 
> Ryan
> 
> _______________________________________________
> Policy mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/policy