X500Standard.com

The families of entries concept fulfils a long-standing directory requirement that has been amplified by the ITU-T Rec. F.510 requirement for support Communications Addresses. A communications address as specified by ITU-T Rec. F.510 consists of the address itself, e.g. a telephone number. In addition several pieces of information are associated with such an address, such as the service provided, tariff, etc.

The Directory has the concept of multi-valued attributes. A multi-value attribute can store several values of the same type. As an example, a person can have several telephone numbers stored in a single attribute. However, there is no implied order of such attribute values. The administrator or the user may enter values in one order, while the directory implementation may store them and transmit them back to users in another order. It is therefore not possible to rely on the order of attribute values.

A user may want to store related information in two or more multi-valued attributes. As an example, two telephone numbers in a multi-valued attribute might be associated with different company locations. However, it is not possible to correlate the value in one attribute with a corresponding value in another attribute. As an example, the communications addresses problem cannot therefore be solved by several multi-valued attributes.

In principle, a complex attribute type could be devised where an attribute value would be a sequence of the communications address itself and its associated characteristics. Such an approach has several disadvantages.

1. support for such an attribute type would require special implementation;
2. a rather special complex matching would be required; and
3. it is not possible to add new characteristics to a communications address without changing the attribute type and the corresponding implementation.

The families of entries approach can solve the above problem.

In the traditional entry structure, contained attributes are considered more or less mutually independent and each provides a piece of the information about an object. However, as illustrated by the communications address example, certain attributes may be related and together form a unity. Such attributes can be place in a special child entry subordinate to the main entry. Such a subordinate entry does not represent an object, only a confined part of an object.

Families of entries model

The figure above illustrates some of the basic features of the family of entries concept.

It is possible to take two complementary views of the families of entries concept:

1. A family of entries can be viewed as a subtree with the ordinary entry as the root. The ordinary entry is called the ancestor of the family. Family members below an ancestor have some of the characteristics of ordinary entries. Entry content and placement are controlled in the same way. In directory terms, a family member is an instance of a structural object class and zero or more auxiliary object classes that control the content of the entry. Structure rules determine the placement of family members. A family member also has a Relative Distinguished Name (RDN) and can thereby be individually addressed by directory operations.
2. An ancestor together with its families represents a single real world object and can therefore be viewed as a single compound entry.

Combined matching of family members and special rules for return of information within a compound entry is the main reason for using special child entries instead of traditional subordinate entries.

Due to the way users expect matching to be performed (see later) it is in most cases only reasonable to use a single family of entries for a single purpose. As an example, if a family represents a set of communications addresses, it may not be feasible to use the same family to represent EDI trading profiles. It is therefore possible to have several families within a compound entry.

A directory user has probably no perception of families, but can in the way the result is packaged see some relationship among the pieces of the information about the object represented by the compound entry.

Communications addresses as a family

A subscriber is represented by a directory entry that holds all relevant information about that subscriber. A subscriber may have several communications addresses. As mentioned before, each communications address has several attributes. To be able to relate such attributes to a particular communication address, each communications address is placed together with its associated attributes in a subordinate child family member as illustrated in figure above. This figure also gives some indication on what type of information that might be associated with a communications address.

EDI trading profiles as a family

A similar situation exists in the EDI world. An EDI user can have several so-called trading profiles. Each such trading profile has several parameters. These parameters would be represented by attributes in a directory solution. The families of entries feature will allow each trading profile to be placed in a subordinate family child entry as illustrated above.

Postal addresses as a family

A person or an organisation (a subscriber in F.510 terms) may have several postal addresses. A postal address can be represented by a single attribute type (e.g. the postalAddress attribute type). However, there are several advantages in representing a postal address by several, more simple attributes, such as street name, house number, city, country, zip code, etc.:

• the attributes are of simple attribute types with a simple syntax;
• it makes searching and matching simpler; and
• it is easier to validate the individual components against an official address database.

Such multiple postal addresses could be stored in family members subordinate to the ancestor.

Multiple families example

Figure 5 above shows a little more complicated example. An organizational person, Charles Smith, has two postal addresses for whatever reason. The entries for the postal addresses together with the ancestor comprise one family. Charles Smith also has two communications addresses. One of them is an e-mail address with two e-mail accounts, one at the place of work and one at home, and that both offer POP3 mailboxes and SMTP servers. These entries together with the ancestor comprise another family.

This example can be used to illustrate the different way matching can be performed against families within a compound entry.

Matching Families

Entry Only	Each family member matched independent of other family members (treated as ordinary individual entries)
Compound Entry	All family members are grouped together before matching
Strand	All family members on a strand are grouped together before matching - Match, if one strand matches
Multi-strand	All family members on one strand from each family are grouped before matching - Match if one combination of strands matches

Figure 6 - Family grouping for operation evaluation

The way family members are grouped for operation evaluation determines the result of the operation. The grouping is specified in the operation request. Here, we will concentrate on search operations. The grouping determines how the filter matching is performed as indicated in figure 6.

The entry-only match is the simplest one. Each entry is matched independently against the filter, as were they just ordinary entries. This is the default, if grouping is not specified in the search request.

The compound entry match considers the compound entry as a whole. All attributes of all family members within a compound entry are pooled together. If that results in several attributes of same type being in the grouping, then these attributes (at least conceptually) merged into one attribute with all the values present. The matching is then performed on this grouping.

Figure 7 above illustrates strand matching. A strand is the collection of entries from the ancestor down to a leaf family member - both included. There are as many strands within a compound entry as there are leaf family members. When performing strand matching, members on a strand are grouped together for matching. Each strand in turn is grouped and matched, i.e. there would in principle be seven matching attempts against the compound entry illustrated in the figure. If at least one strand matches the filter, the compound entry, or part of it, is a candidate for information return. What information that is returned is discussed later.

The multi-strand matching is illustrated in figure 8. This is a somewhat complicated matching, but is probably the most useful grouping for matching. Here, the entries from one strand from each of the families are grouped before matching. Each combination of strands, one from each family, is one at the time grouped and matched, i.e. there would in principle be ten matching attempts against the compound entry illustrated in figure 8.

Marking and returning family members

The concept of marking entries has been introduced as a convenient description tool for specification of what members of a compound entry should be returned.

When a grouping of family members results is a match against the search filter, all entries in that group have participated in the matching. All those members are marked as participating members. However, some members in the group may not have made an active contribution to the match. Members that have actively contributed to the match are marked as contributing members.

Let us assume that figure 9 represents the same situation as figure 5, and that we have the filter:

{ givenName=Charles & streetAddr=Main & serverName=xx }

then we would not have any match for the entry-only or the strand groupings, but we would have matching for multi-strand and compound-entry groupings. In case of multi-strand grouping, the entries would be marked as indicated in figure 9. For a compound-entry grouping the entries would be marked as contributing as shown in figure 9, while all entries would have been matched a participating.

Contributing Entries Only	Only entries marked as contributing to the match are returned
Participating Entries Only	Only entries marked as participated in a match are returned
Compund Entry	All entries within compound entry are returned if just one entry is marked as contributing

Figure 10 - Entry Information Selection

What is returned as the result of the marking is determined by entry information selection data type in the operation argument. Figure 10 shows the different options.

Entries from a particular compound entry are packaged in such a way that they on the protocol have the appearance of a single entry.