Topics

Selection formulas supported for directory catalogs
In R5.0.4, the Advanced tab of a directory catalog Configuration document includes a new field, "Selection Formula." Use this field to enter a selection formula to aggregate only documents defined by the formula. For more information, see the Release Note titled "Selection Formula in a Directory Catalog Configuration document."

If you add a selection formula to a directory catalog Configuration document created prior to R5.0.4, the dircat task entirely rebuilds the directory catalog the first time it runs on the R5.0.4 server.

Server directory catalogs now support full functionality for R4.6 clients
R4.6 clients can use typeahead and F9 lookups against an R5.0.4 server directory catalog. In addition, an R5.0.4 server that uses a directory catalog correctly resolves the mail addresses of groups for R4.6 clients. Pre-R5.04 server directory catalogs don't completely support these features for R4.6 clients.

More name formats supported for members of external LDAP directory groups
If you use the group expansion feature in an LDAP Directory Assistance document so that you can use external LDAP directory groups in Notes database ACLs, the names of the members of the LDAP directory groups can now be in any standard X.500 or LDAP format. Previously, the distinguished names of the group members had to have formats similar to "cn=xxx, ou=xxx, o=xxx" or "uid=xxx, ou=xxx, ou=xxx o=xxx." Names with formats such as "mail=xxx, l=xxx, o=xxx" and "cn=xxx, dc=xxx, dc=xxx" are two examples of acceptable name formats for the members of external LDAP groups in R5.0.4.

Currently, naming rules specified in a Directory Assistance document must still correspond to the Notes naming model, however. So to represent in a directory assistance naming rule a distinguished name format that doesn't conform to the Notes model, we recommend that you use an all-asterisk rule, even if some name components correspond to those used in Notes.

For example, given names formatted as "mail=xxx, l=atlanta, o=acme," we recommend that you use an all-asterisk rule. Although a rule such as the following might also work, you should use such a rule with caution:

OrgUnit4	OrgUnit3	OrgUnit2	OrgUnit1	Organization	Country
			*	acme	*

LDAP telephone numbers no longer converted to international format
In R5.0.4 values for LDAP telephone number attributes in the Domino Directory remain in the format in which you add them to the directory. Previously, telephone numbers were normalized to an international format. In R5.0.4 an entry with a telephone number will be searched if the search filter specifies either the stored format or the internationalized format of the number. For example, if an entry has the telephone number 1 (800) 123-4567, the filter "telephoneNumber= 1 (800) 123-4567" and the filter "telephoneNumber=+1 800 123 4567 both search the entry.

Searches of LDAP "mail" attribute no longer case-sensitive
In R5.0.2 and R5.0.3 only, it was necessary to use the exact case when searching for a specific value for the mail attribute. For example, if a mail attribute value for an entry was JDoe@acme.com, then the search filter mail=jdoe@acme.com would not return results for that entry. R5.0.4 corrects this problem.

LDAP subtree searches now return the base entry
R5.0.4 corrects a problem in which the LDAP service didn't return a base entry as part of the results of a subtree search. For example, in R5.04 if you do a subtree search that specifies o=acme as the base, the LDAP service now returns the entry for o=acme as part of the results.

Domino LDAP service recognizes changes in group membership
In R5.0.2 and R5.0.3 only, if you changed the members of a group in the Domino Directory, the LDAP service would not recognize the change unless you rebuilt a specific view after making the change. R5.0.4 corrects this problem.

LDAP searches of the Domino Directory using the filter mail=* now work correctly
Prior to R5.0.4 if you used mail=* as a search filter, the LDAP service included in the results entries that didn't have mail attributes defined for them. For example, if you added the object "Printer" without a mail attribute, the mail=* search filter nevertheless returned printer entries. This problem is corrected in R5.0.4.

Directory assistance failover improvement
In R5.0.4 directory assistance failover to an alternate replica of a secondary directory works when server availability conditions change after server startup. Prior to R5.0.4, directory assistance failover didn't work consistently because directory assistance didn't dynamically update its internal tables of available replicas to reflect changed server availability.

Note that if you use database links to configure failover replicas, and none of the servers referenced by the links for a specific domain are available at the time you start up a server that uses the Directory Assistance database, directory assistance doesn't have the information it needs to locate a replica for a domain. As a result, if one of these servers later becomes available, directory assistance still cannot failover to that server until you restart the directory assistance server. When you start up a server, and a server referenced by a database link is unavailable, you see the console message: "Could not access Public Address Book on Server xxx, error is Server not responding."