[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Grouping Attributes Together
I'm glad to hear about this work. We've been experimenting, and validating,
that an approach similar to what you describe as the "family of entries"
approach provides far and away the best combination of access control
policy granularity, locality of reference by services which manage or consume
their respective entries, and understandability. We don't, however, believe
that the benefit of the system will accrue if those entries are not equally
related to the principle owners and consumers of the data.
For instance, in the example of an email in box, the group of attributes
which describe the server where the in-box is located, the protocols it
available to speak to it, and the network addresses for reaching it are
all properly associated with the service on which the in-box is hosted.
The attributes describing who's in-box it is, how much disk space
they're allowed, a per-user set of policies governing how often
messages are purged, or trash emptied, or preferred message formats,
etc. can reasonably be created subordinate in the namespace to the
service definition...and that provides a really useful metaphor for
managing a user's email account - by simply renaming the directory
entry describing the in-box to locate it under another post office service,
the post office services SHOULD be able to coordinate among themselves
to create the new in-box, transfer messages stored in the old in-box to the
new in-box (cf: Xerox' mail service, which did this), and ultimately purge the
no-longer needed messages from the old in-box, once they've all been
transferred.
But note - the relationship of the Post Office service, the In-Box account
record, and the Owner of the email account (the bloke who's mail gets
routed to the In-Box on the Post Office) is three-way, and making sure that
the Person's knowledge of where their In-Box is located, as, for instance,
particularly if their email address changes as a result, must also be taken
into account.
The DMTF CIM User Group have been discussing these kinds of three-way
relationships, and how they need to be mapped onto the directory. There's
likely to be some mutual interest, here.
Best regards,
Ed
----------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861-3320
>>> "David Chadwick" <d.w.chadwick@iti.salford.ac.uk> 11/19/1998 08:49:21 >>>
There has been the requirement for many years to be able to group
together a set of related attributes for an object. Examples include:
all the attributes that describe a PGP key
all the attributes that describe an Email address/post box
This works using the existing X.500/LDAP information model if the
object only has one such set of attributes e.g. one PGP key, or
one email address, but does not work if the object has many such
sets of attributes. The reason it does not work is that multi-valued
attributes comprise a SET and not a SEQUENCE, hence it is not
possible to relate which particular value from attribute 1 belongs
with which particular value from attribute 2.
The X.500 group are working on a solution to this problem, and
have two possible candidate solutions. One is compound
attributes, the other is families of entries.
Compound attributes are attributes whose values are themselves
sets of attributes. In this way a whole set of attributes is related
together via the enclosing compound attribute value.
Families of entries comprise a parent entry with subordinate
entries, where each subordinate entry contains the set of related
attributes. The family can be treated as one compound entry or a
single entry by the user, depending upon the operation.
Both solutions will require additions to the LDAP protocol (via
controls) and to the X.500 information model.
Given that the problem domain is equally applicable to users of
LDAP servers as of X.500/LDAP DSAs, is seems desirable that the
solution chosen to this problem is one that both the IETF LDAP
group and ITU-T X.500 group can readily accept.
I would therefore like to propose that the LDAP-EXT group add this
work item to their charter. I will be present at the Orlando meeting
to further describe the problem and proposed solutions if the group
would like to discuss it some more before making a decision. I also
have the texts of both solutions (families of entries and compound
attributes) that I will make available to the list, so that a technical
choice can be made. (Both solutions are currently in Word/RTF
format and so would need some editing before they are available in
ASCII, although they could be distributed now as is, if people
thought that this was appropriate).
I await your feedback
David
***************************************************
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
***************************************************