Subject: RE: [Policy] PCLS classes deprecated in PCELS

From: "Pana, Mircea" <[email-masked]>
Date: Fri, 12 Sep 2003 16:10:33 -0500

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-masked]]
> Sent: Friday, September 12, 2003 1:50 PM
> To: Larry S. Bartz; [email-masked]'
> Cc: [email-masked]; 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-masked]
> https://www1.ietf.org/mailman/listinfo/policy
>

---

From: Ryan Moats <[email-masked]>
Date: Fri, 12 Sep 2003 16:30:20 -0500

On Fri, Sep 12, 2003 at 04:10:33PM -0500, Pana, Mircea wrote:
| 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.
| 

It might confuse future implementers to reuse "pcim", but I'm unsure if that
is a valid technical reason for avoiding reuse.

Ryan

---

From: "Larry S. Bartz" <[email-masked]>
Date: Mon, 15 Sep 2003 08:41:21 -0500

Pana, Mircea wrote, On 09/12/03 16:10:
> 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. 
> 
> 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.
> 

Excellent!

> 
> 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.

The distinction between PCIM/PCLS (the "core") and PCIMe/PCELS (the
"extension") is significant; significant enough to distinguish the
work of you and your co-authors by assigning a set of distinctive names
to all new and different PCELS attributetypes and objectclasses. If
PCELS does not do this, implementers will naturally expect that
information components with similar prefixes belong to the same
information model. The logical differences between PCIM/PCLS and
PCIMe/PCELS preclude this kind of mix and match. PCELS should
facilitate implementation by providing its own set of names.

One more thing. I agree with John Strassner, who writes:
 > ..this document changes PCLS in several fundamental ways. I do NOT
 > think that the word "update" should be used anywhere in this document. </js>

Thanks,

-- 
--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz
#
#  voice (317) 226-7060
#  FAX   (317) 226-6378
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|