[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(Fwd) Families, compound attributes and contexts
Mark,
I relayed your interest in the tagging of attribute values to the FDAS
group and here is the reply from one of the editors, Erik. It appears
that whilst attribute value contexts might be somewhat useful, they
will not be as useful as families or compound attributes for
generally grouping attributes together.
David
------- Forwarded Message Follows -------
From: Erik Andersen <ERA@FL.DK>
To: "'OSI Directory'" <osidirectory@az05.bull.com>
Subject: Families, compound attributes and contexts
Date sent: Fri, 11 Dec 1998 16:08:40 +0100
David, thank you very much for your note from Orlando. It was very
useful.
To be very clear on contexts. We did not do any technical work on
contexts
itself, except for adding a new filter item that is somewhat similar to
the present filter item. This filter item evaluates to TRUE if an
attribute of the specified type has value that satisfies the contexts
assertion. Contexts feature has been included in the search rules
in such
a way that the F.510 communications address requirement could
be
fulfilled.
There is a significant difference between the contexts feature and
the two
other proposals. Contexts specifies characteristics associated with
a
particular attribute value (this is actually what is required for
communications addresses), while the attributes in a compound
attribute/family entry in principle have the same status. However,
this
has very little significance. Another more major difference is that in
contexts we can only have simple equality matching, and not have
more
sophisticated matching as for the two other proposals. We could
live with
just simple equality matching for the current F.510 requirements,
but
future requirements could require more complex matching, e.g.
substring
matching. So, having an alternative to contexts, this alternative will
surely be used by the FDAS group and reflected in the profile.
Also, the
compound attributes/families of entries solves a number of other
issues
not solved by contexts.
The FDAS group may still need the contexts feature as we have
defined it
in the search rules for language support.
As to the choice between compound attributes and families of
entries, I do
not have any particular preference, except I want the best possible
solution. I believe that the major reason for Anthony to propose
compound
attributes was that he felt it would have the least impact on the
standard. As they stand now, the two proposals are very much
alike.
Anthony should be complimented for taking the initiative in this
area and
for getting this initiative accepted within the standard committee.
It seems to me, that we must make sure that we get the best from
both
proposals. If we then also can get a solution that will improve
alignment
with the IETF work, that would be great. It is not so important what
we
call the result.
Erik Andersen, Consultant, Direct Tel. (+45) 3945 0736, Mobile:
(+45) 2097
1490, E-mail: era@fl.dk <mailto:era@fl.dk>
FISCHER & LORENZ A/S
Tuborg Parkvej 10, DK-2900 Hellerup, Copenhagen, Denmark
Tel. (+45) 3945 0700, Fax (+45) 3945 0777, E-mail: fl@fl.dk
<mailto:fl@fl.dk> , Internet: http://www.fl.dk <http://www.fl.dk>
CEN/ISSS Directory Workshop chairman, Internet:
http://www.cenorm.be/isss/Workshop/DIR/Default.htm
<http://www.cenorm.be/isss/Workshop/DIR/Default.htm>
***************************************************
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
***************************************************