[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Families of Entries
Date forwarded: Mon, 11 Jan 1999 21:45:34 -0800 (PST)
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: ietf-ldapext@netscape.com
Subject: RE: Families of Entries
Date sent: Tue, 12 Jan 1999 16:25:05 +1100
Forwarded by: ietf-ldapext@netscape.com
>
> Dear all, just a few comments on the family of entries issues
> and compund attributes.
>
thankyou for taking the time to comment
> The requirement is very real having collection of entries and
> parent/child concepts. In addition compound attributes have wide
> utility.
>
> some points:
> a) Building Parent/Child Definitions
> The way in which parent/child entries are built are related to
> operational functionality desired from the directory service in line
> with business models. Eg a person entry may have many roles, and roles
> may be supported by many people. Also people report to many managers and
> managers may be a person (a leaf entry) that is responsible for many
> organisations/units (as represented higher in the directory).
>
this was not the functionality we were trying to support in families.
> In creating families of logically dispersed but related
> directory entries we need to understand the distributed and operational
> management and requirements behind that.
Again, it was not envisaged in the families model to support widely
dispersed but logically related entries. Rather it was supporting a
single entry having collections of attributes, and putting these
collections together, below the entry in convenient child collecting
pots.
> As it is easy to create a single
> instance of a mechanism and define it in ASN.1 and apply that in a single
> server, but slightly more difficult to engineer that into distributed
> environment that scales well - as well as understand the operational
> resource that will be needed to run the system.
>
there is no requirement (currently) to distribute children of families, they
will always be in the same server as their ancestor.
> In fact the operational resource will be the same style to
> manage that of other directory relational/name based attributes such as
> URLs, DNs-Role Occupant, See Also, Group of Names...., etc. So we could
> just be adding a mechanism that may already be supported with normal entry
> attributes.
> And all that needs to be developed is the searching and matching
> rule processes around these "relational" attributes (as per the F.510
> service model).
>
in fact, the controls are there to support searching and matching on
families of entries, as if they were a single entry
> b) Total Scope of Directory Searching and Information Management
> With Family of entries mechanisms we now have a directory model
> that is distributed and related by name containment (the DIT), grouped by
> schema definitions, access controls, collective attributes (subentries),
> accessed through contexts (time of day, language, etc) grouped by
> replication requirements, organised operationally by logical hierachy-
> family definitions and from a business/user information (value)
> perspective entries are related through See Also, Role Occupants, Group of
> Names, Mail Lists, etc. In addition subtyping of attributes may be used -
> so all in all directory searching and information management can become
> complex.
>
> I tend to think that X.500 object - hierarchy approach has a
> great deal to offer at the all levels of the tree. But at the lower
> levels, a relational model approach may required. Both in terms of
> information definition and directory engineering. So comments are
> invited here.
> Note the issues re Multiple Service Providers and split entries
> and how relational search processes can solve that.
>
>
> c) Multiplexed Family Relationships
> The mechanism currently defined seems to be a single value
> operational attribute for each entry for the Hierarchy Info.
the current spec uses the object class attribute to denote parent-
child relationships.
> This in the
> ideal world, should be multi-valued as a child entry may have many parents
> and parents may want logical groups of children.
>
>
It is correct to say that many entries may want to share the same
collection of attributes, but that is done currently by either copying
the collection into each entry, or having a see-also or some other
pointer, or collective attributes in a subentry. the same
mechanisms can be used for families. Alternatively logical
groupings of children can be done via a new object class. But there
is no way currently for any entry to have multiple parents, so
families are no different to normal entries in this respect.
> d) Cross-Subordinate DSA management.
> The way in which cross DSA boundaries are managed in terms of
> subentries (collective attributes, schema, service/search definitions,
> etc) adding entries, etc in a set of distributed-subordinate DSAs is via
> DOP. It follows that in theory that if a DSA sibling is added as another
> DSA. Then the parent and sibling entries in other DSAs will require
> updating. How this is done is a distribution - management issue that needs
> to be looked at.
>
No, I dont propose to ever split families up between DSAs. there
are enough broken homes in the real world without introducing
more in the DIT :-)
> In closing, the requirement for family entries and compound
> attributes is real.
> However, the mechanisms proposed are logical but should we
> debate the compound attribute area and relational /matching rule areas to
> see if these requirements can be met in a different way.
>
>
There is a hierarchical relationship attribute proposed in the F.510
work that does allow widely disparate entries to be related together
hierarchically. However, this is completely separate from the
families approach. Are you mixing the two up?
David
> regards alan
>
> >
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string A7OX-K3QT-JPTU
***************************************************