[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Grouping Attributes Together



Now for a thought. As you say, the reason this is
hard is that the LDAP/X.500 information model defines
multi-valued attributes to be a SET of values, rather
than a SEQUENCE. My thought is what would happen if
we made this a SEQUENCE instead? And added an "insert
after" variation or some such thing to the modify
operation.

I realize this is a more fundamental change, and may
turn out to be a bad idea. But we should think about
it before dismissing it. Comments?       -- Tim

David Chadwick wrote:
> 
> 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
> 
> ***************************************************