So, couldn't you just always request in the search that the DN or CN be returned as one of the attributes? If the entry is found, you're going to get the DN of the entry as the record identifier, then getting the DN (or CN) again as an attribute becomes just a throwaway, but solves the problem of producing or consuming bad LDIF.
-----Original Message----- From: Kurt Zeilenga [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 9:57 AM To: Chris Ridd Cc: Gergely Santa; perl-ldap Subject: Re: Net::LDAP::LDIF patch On Apr 24, 2007, at 5:50 AM, Chris Ridd wrote: > The LDIF RFC 2849 defines that ldif-attrval-records (ie not change > records) > contain a dn-spec followed by at least one attrval-spec. LDIF, as defined in RFC 2849, is used to represent directory input. Namely, LDAP requests (Add, Delete, Modify, Rename) requests. The requirement to have at least one attrval-spec flows from basic LDAP data-model requirements that an entry cannot be empty (contain no attributes). Though LDIF is often used to represented LDAP search entry results, it is not actually designed for this purpose. When used this purpose, the at least attribute restriction is commonly lifted as entry results may contain none of the entry's attributes. -- Kurt
