So, in ad.c [ad_inlist], the AttributeDescription (*desc) does not have it's flags set 'properly.' That is, apparently within that structure there are flags and tags, during the parsing of the schema, the flags and tags get set properly (same file [slap_bv2ad]): desc.ad_flags |= SLAP_DESC_BINARY;

That means that, in ad_inlist, the desc's name still has ";binary" in it, and no flags set. I find that if I map this condition as an entry in the if/else cascade -- right after checking the flags, but before the if-fail on flag compare -- the data is properly returned. (I'll generate a patch, if that's an appropriate thing to do/place to do it.)

However, there remains a problem: other LDAP Servers appear to return the 'attribute-name' requested (userCertificate;binary::) to describe the data. Now that the data is being returned, it's being returned without the ";binary" option -- as 'userCertificate::'. Per ITS#3113, ";binary" is obsoleted?

Is there a compatibility mode that can be optioned to support this? Obsoleted and back-wards compatibility being in conflict..... i.e. is there a way to say "return the attribute by name-requested instead of schema-name?"

----- Original Message ---- From: Kevin Vargo vargok@yahoo.com To: Pierangelo Masarati ando@sys-net.it Cc: openldap-its@openldap.org Sent: Tuesday, March 13, 2007 10:15:26 AM Subject: Re: (ITS#4868) Binary Attribute Patch(es)

----- Original Message ---- From: Pierangelo Masarati ando@sys-net.it To: vargok@yahoo.com Cc: openldap-its@openldap.org Sent: Monday, March 12, 2007 4:52:04 PM Subject: Re: (ITS#4868) Binary Attribute Patch(es)

...

These address the use of Binary-valued attributes (#3113, #3386):

For example, inetOrgPerson.userCertificate is usually transferred with the ";binary" directive. ";binary" is not handled by OpenLDAP/Back-SQL.

Well, the solution you propose is not correct, since you are altering schema data, which is supposed to be read-only. In any case, the point is:

Yeah; I think the actual submission found the ";binary" and reset the reference to it, not actually doing anything to it.

• if we decide that back-sql should ignore tags, then the solution

consists in using the canonical name of the underlying AttributeType when looking up data;

• however, this would destroy the possibility to use different storages

for differently encoded data; for example, a column for "cn;lang-en" and a column for "cn;lang-jp". I don't know how many users would prefer one solution over another, but in any case either we find a solution that preserves both capabilities or we choose one. I'd vote in favor of ignoring ";binary" since it's obsolete and related to transport only, but in favor of honoring language tags.

Sounds great to me. I just want support for ";binary" both on storage and retrieval to be supported. I'll accept that it's obsolete -- I'll also put forth that a lot of things still use it (e.g. Lotus Domino v6).

...

There remains an issue with selecting attributes using, e.g., "userCertificate;binary" -- nothing is returned. Someone with a better understanding of the attribute-processing method would be much more effective in terms of finding the correct place to remove the ";binary" from the "attribute-name." (i.e. "userCertificate;binary" is NOT the attribute-name; "userCertificate" is the attribute-name, ";binary" is a transport directive (see #3113).

In fact, "userCertificate;binary" is the attribute description. The attribute name is in ad_type->sat_cname.

And, in fact, none of what I did appears to have been sufficient. I'm still looking at why selecting "userCertificate;binary" as part of an ldapsearch attribute-list doesn't pull the data. "userCertificate" does. The issue appears to be related to the ad_inlist verification on the search-supplied attribute -- "userCertificate;binary" doesn't resolve. If you know where I can look to figure this out, that would help. I've been through some areas and not found exactly where just yet.

Thanks for your assistance. Kevin Vargo

____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html