RE: Implementing "Class of Service" or "virtual attributes" in Op enLDAP?

[Keith Bigelow <keith.bigelow@businessobjects.com>]

Kurt/Robert,

If one was hoping to be agnostic to backends, and wanted to work with both
the iPlanet CoS and present/future OpenLDAP collective attributes, as well
as other implementations from Tivoli, MSFT, etc., do you have any clever
suggestions on an approach that would let me work with an arbitrary backend?

My concern is that I get stuck doing redundant implementations per backend,
which sounds less than efficient,

thanks again,

Keith

At 05:16 AM 2002-09-26, Rob Byrne - Sun Microsystems wrote:
>> I had a look at your draft...I have a question on the section below: it
looks as if it forces collective attributes to always be subtypes of
non-collective atributes.  Otherwise, as they cannot be operational nor
mentioned as an
>> attribute type for an objectclass their inclusion in an entry would
constitute a schema error.

Inclusion of a collective attribute in an entry is controlled
by administrative controls (See Section 3).  In systems following
X.500 models, DIT Content Rules are used.  In other systems,
other administrative controls are used.

Kurt

-----Original Message-----
From: Rob Byrne - Sun Microsystems [mailto:robert.byrne@sun.com]
Sent: Thursday, September 26, 2002 5:12 AM
To: Kurt D. Zeilenga
Cc: Keith Bigelow; 'openldap-devel@OpenLDAP.org'
Subject: Re: Implementing "Class of Service" or "virtual attributes" in
OpenL DAP?



Kurt,

I had a look at your draft...I have a question on the section below: it
looks as if it forces collective attributes to always be subtypes of
non-collective atributes.  Otherwise, as they cannot be operational nor
mentioned as an
attribute type for an objectclass their inclusion in an entry would
constitute a schema error.

Rob.

 "Collective attribute types are commonly defined as subtypes of non-
  collective attribute types.  By convention, collective attributes are
  named by prefixing the name of their non-collective supertype with
  "c-".  For example, the collective telephone attribute is named
  c-TelephoneNumber after its non-collective supertype telephoneNumber.

  Non-collective attributes types SHALL NOT subtype collective
  attributes.

  Collective attributes SHALL NOT be SINGLE-VALUED.  Collective
  attribute types SHALL NOT appear in the attribute types of an object
  class definition.

  Operational attributes SHALL NOT be defined to be collective."

"Kurt D. Zeilenga" wrote:

> At 08:17 AM 2002-09-25, Keith Bigelow wrote:
> >I've reviewed the archives and the project pages, but haven't been able
to determine if v3 LDAP virtual attributes will be a likely addition to a
future drop.
> >
> >Is anyone working on implementing virtual attributes?
>
> There has been some work in the past on what are called
> "collective" attributes, attributes whose values are shared
> amongst a collection of entries.  These are primarily specified
> in X.501.  draft-zeilenga-ldap-collective-xx.txt is intended
> to fill in the gaps in their mapping to LDAP.
>
> Presently I think the work is stalled (I'm busy with other
> things).
>
> >If so, is the implementation likely to follow Netscape's
<http://www.ldapguru.org/modules/news/article.php?item_id=102>http://www.lda
pguru.org/modules/news/article.php?item_id=102?
>
> I think we should stick with following collective attribute
> specifications in this area.
>
> >My goal is to minimize my LDAP schema dependency by leveraging
[hopefully] OpenLDAP's ability to use virtual attributes / Class of Service
(CoS) to share attributes between entries in a way that is transparent to my
application[s].
> >
> >Please advise if this is in the roadmap, if there is interest in
collaborating on offering this extension, or if this is too far in the
weeds.
>
> Collective attributes are listed on the roadmap...
>
> Additional help is welcomed...  feel free to jump on in.
> Start by reading draft-zeilenga-ldap-collective-xx.txt
> (available from the IETF, HEAD's doc/drafts, ...).