|
Regarding #1, My opinion is that servers should not return extension information like this unless it is solicited. Unfortunately, we have already set a precedent with language tags and the binary option which both return unsolicited attribute options. The danger is exaclty the problem you've run into ? clients are given data that they don't understand and can't properly work with.
Since we're talking about this on the LDAPBis list, I'll suggest that we add a recommendation to this effect:
Servers SHOULD NOT return attributes with options unless solicited to do so.
Jim
>>> "Schleiff, Marty" <marty.schleiff@boeing.com> 4/18/04 12:31:39 AM >>> Gentlemen, When using ldapsearch to lookup the membership in an Active Directory group, I got the following (abbreviated) response: CN=PC Backup Group 1,OU=Groups,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com member;range=0-999=CN=Peterson\, Randy R,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com member;range=0-999=CN=Tatham\, William C,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com member;range=0-999=CN=Pham\, Steve,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com I'd never before encountered "range=0-999" and wondered what it meant. A little searching turned up the following URLs: http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt and http://www.hut.fi/cc/docs/kerberos/nss_ldap.html From the second URL: "Active directory uses a method called "Incremental Retrieval of Multivalued Properties" which nss_ldap has no support for, at least not yet. Querying groups having more than 1000 members will return the first 1000 members, with the 'member' attribute changed to 'member;range=0-999'. This is not recognized by nss_ldap, so you will not see any members for that group. More information can be found in the (now expired) Internet Draft labeled Incremental Retrieval of Multivalued Attributes <draft-kashi-incremental-00.txt> ." I was also referred to http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt ; however, I'm not sure that applies to my situation (it seems to describe how a client could request the server to return a partial set of values for a multi-valued attribute -- in my case I didn't request the range, Active Directory just gave it to me when I really wanted the complete set of values). I'd value the opinions of this list around the following questions: 1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions. 2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". 3) Does The Open Group assessment of "LDAP Ready" require a client to understand ranges? 4) Does The Open Group assessment of "LDAP Certified" require a server to return ranges? Or if a server does return ranges (which probably would confuse many clients), can that server be "LDAP Certified". 5) Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser location box, etc. ever be able to request ranges of multi-values attributes (or do they already have this capability and I'm just unaware)? Thx, Marty.Schleiff@boeing.com ; CISSP Associate Technical Fellow - Cyber Identity Specialist IT Access & Security Services (425) 957-5667 |