Open Radar

 
Area:
Contacts

Summary:
When searching for any non-telephone number entry on large LDAP directories conforming to RFC 4517 and E.123, Contacts displays no results (even though there are known to be matches on the directory server).

Steps to Reproduce:
1a. Add an LDAP account for contacts, using:
Settings -> Contacts -> Accounts -> Add Account -> Other -> Add LDAP Account
1b. Add an RFC 4517 compliant LDAP server with a large number of entries
2a. Open the contacts app
2b. Open the groups section
2c. Select the newly configured LDAP server
2d. Search for a contact; e.g. "foo"

Expected Results:
I expect to see relevant results for the search "foo"

Actual Results:
The contacts app does nothing period of time (a spinning wheel is visible in a portion of the UI), then no results are displayed (even though there are known to be matches on the directory server).

Version:
Various releases of iOS 9, 10.1, 10.2

Notes:
The underlying issue appears to be the search filter created by the iOS devices:
(|(o=foo*)(cn=foo*)(ou=foo*)(sn=foo*)(mail=foo*)(IMHandle=foo*)(givenname=foo*)(postalAddress=foo*)(telephoneNumber=foo*))

Specifically, the problem appears to lie in the subfilter (telephoneNumber=foo*)

RFC 4517 (4.2.30 telephoneNumberSubstringsMatch, and E.123 as proxy) specifies an insignificant character handling step to occur on an LDAP servers before processing the search filter. Compliant LDAP servers (Oracle, OpenDS, OpenDJ, UnboundID, etc) handle this by stripping out the non-significant characters from the search filter from telephoneNumber filters.

In almost all cases where the underlying search is not a phone number (e.g. the case described where a user searches for "foo"), the search filter essentially becomes (on the LDAP backend) this: (telephoneNumber=*)

This of course results in all entries being returned, which in a large directory takes some time and returns a large amount of data.


Configuration:
Numerous iOS devices; iPhone 6S, SE, iPad Air 2, etc.