RE: PCLS classes deprecated in PCELS

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.

 

With respect to the second point, that's much better. I will provide
comments on the schema itself next week.

 

With respect to naming, I don't understand the problem. You have build a new
design, not an update of an existing design. Thus, new concepts should be
assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas
existing concepts should be assigned the pcim prefix. Thus, it is not a
"everything or nothing" decision but instead a judicious application of new
(pcels) vs old (pcim) concepts.

 

 

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: Friday, September 12, 2003 3:11 PM
To: 'Joel M. Halpern'; Larry S. Bartz; '[email protected]'
Cc: [email protected]; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

 

So, if I understand correctly, everything would be "OK" if PCELS did: 

1. Define only subclasses of PCLS classes and, where not possible, redefine
PCLS concepts as new classes (use different names and oid.s). This is
already the case in the currently published ID with the exception of
pcimGroup* that would need to be redefined with a different name.  

2. Use "for compliance with PCIMe implementations SHALL use <list schema
items> instead of <list of schema items> for the realization of <concepts>"
instead of deprecating PCLS classes. This would be added to a new revision
of the ID.

I'm fine with both. (I hope I did not miss anything) 

Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as
there are no naming conflicts, I would prefer to avoid it if possible. Could
you live with that? However if we have to do it for one item we should do it
for all.

Thanks, 
Mircea. 





> -----Original Message----- 
> From: Joel M. Halpern [mailto:[email protected]
<mailto:[email protected]> ] 
> Sent: Friday, September 12, 2003 1:50 PM 
> To: Larry S. Bartz; '[email protected]' 
> Cc: [email protected]; David McTavish; Pana, Mircea 
> Subject: Re: [Policy] PCLS classes deprecated in PCELS 
> 
> 
> Ryan as just nicely explained this to me in a way that got it 
> through my 
> thick skull.  You both are correct.  We can not move existing classes. 
> 
> Hence, one needs to create new classes, and include text that 
> says "use 
> this instead of the old thing". 
> 
> Unfortunate, but really a common problem with class naming / 
> inheritance 
> (not specific to just LDAP). 
> 
> As I said to Ryan, thanks for the patience explaining this. 
> Joel 
> 
> At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: 
> >Ryan Moats wrote, On 09/12/03 11:27: 
> >[snip} 
> >>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. 
> > 
> >I'll go further and suggest that every component of PCIMe which is 
> >not exactly as defined in PCLS should be prefixed "pcime". If PCELS 
> >simply avoids deprecating, renaming, or redefining anything from 
> >PCLS, there can be no conflict with PCLS. And if everything new 
> >which is introduced by PCELS is prefixed "pcime", there can be no 
> >confusion about which is "core" and which is "extension". 
> > 
> >Such a strategy will ultimately satisfy Joel's concerns, 
> when he wrote: 
> > > My feeling is that concerns about PCELS should be in the 
> context of 
> > > support for PCIMe, 
> >and 
> > > if one can accurately map PCIMe to LDAP in a way that is 
> compatible 
> > > with PCLS, then that would clearly seem desirable 
> > 
> >PCELS should map PCIMe to LDAP in a way which is not 
> INcompatible with 
> >PCLS, in a way which does not break PCLS. I agree that 
> "concerns about 
> >PCELS should be in the context of support for PCIMe". I augment that 
> >by saying that PCELS should not be concerned with recasting PCLS in 
> >any way. 
> > 
> >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any 
> >impact on PCLS. 
> > 
> > 
> >-- 
> >-- 
> >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 
> ::::::::::| 
> ># Larry Bartz 
> ># 
> >#  voice (317) 226-7060 
> >#  FAX   (317) 226-6378 
> >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 
> ::::::::::| 
> 
> 
> 
> _______________________________________________ 
> Policy mailing list 
> [email protected] 
> https://www1.ietf.org/mailman/listinfo/policy
<https://www1.ietf.org/mailman/listinfo/policy>  
>