[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Grouping Attributes Together
Providing a CIM perspective here. I am putting a proposal together round
extensions to the metaschema required to accomodate a formal definition of
methods and events (as opposed to the rather informal one CIM has at the
moment). It is pretty clear that CIM will have to distinguish classes and
types. A class being a type that has instances. A type being necessary to
define the set of properties defining the parameters for a method as well as
the set of properties that characterise an event or a class.
Types are either simple or constructed - i.e. prmitives such as int and
string or structures
It is a natural further step to consider properties as characterized by
types, i.e. the type of a property is the same as the type as applied to a
class or event. Currently CIM restricts property types to simple types. Part
of the reasoning behind this is that we wanted to avoid introducing multiple
ways of defining relationships between classes - allowing only associations
(and inheritance if you want to think of it as a relationship).
This is all very straightforward object oriented stuff and is merely
reiterating approaches that have been taken by numerous systems (SmallTalk,
Simula, O2 etc)
I think the challenge in this thread is to define exactly what the LDAP
equivalents are and determine how they will be mapped to CIM. Given that CIM
is hovering on the edge of the changes needed to accomodate a formal
specification of methods and events, there is an opportunity here to meet
requirements that arise from a mapping to LDAP or X.500.
Patrick
-----Original Message-----
From: Alan Lloyd [mailto:Alan.Lloyd@OpenDirectory.com.au]
Sent: Thursday, November 26, 1998 8:31 AM
To: 'd.w.chadwick@iti.salford.ac.uk '; 'ietf-ldapext@netscape.com '; 'Ed
Reed '
Cc: 'wg-user@dmtf.org '
Subject: RE: Grouping Attributes Together
For my two bobs worth, the two solutions defined in the F.510 PDAP (and
as described on the cover - quite correctly) may be supportive - ie. one
may need both types of mechanism is the directory system.
IMHO composite attributes are a definite requirement for eg. Directory
Enabled mail systems where a dierctory attribute can in fact be a mail
box or in fact a mail message.
The parent/multiple child entry grouping can also solve this but does
require a a different style of search and matching mechanisms ie.
upgrades - eg is the child entry leaf or non leaf object, etc.
So if these options are being evaluated for LDAP , then the areas of
search rule changes and protocol/complex-attribute/binary encoding must
be looked at also.
regards alan
----------
From: Ed Reed
To: d.w.chadwick@iti.salford.ac.uk; ietf-ldapext@netscape.com
Cc: wg-user@dmtf.org
Sent: 11/20/98 3:16:17 AM
Subject: 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
***************************************************