Full_Name: Quanah Gibson-Mount Version: 2.1.16 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.82) Hello, We have found that it would be useful for attributes like "gn, givenname" to return the attribute they were searched on. I.e., if I search on "gn", I would like to see the returned attribute be "gn" rather than "givenname", and vice versa. I imagine this would take some major reworking of 2.1, so maybe in 2.2? --Quanah
This feature has been implemented in OpenLDAP 2.1 since release 2.1.3. See the ldapsearch usage message, "matched values filter". The man page appears to be missing documentation on this feature at the moment. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support > -----Original Message----- > From: owner-openldap-bugs@OpenLDAP.org > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of quanah@stanford.edu > Full_Name: Quanah Gibson-Mount > Version: 2.1.16 > OS: Solaris 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.82) > > > Hello, > > We have found that it would be useful for attributes like > "gn, givenname" to > return the attribute they were searched on. I.e., if I > search on "gn", I would > like to see the returned attribute be "gn" rather than > "givenname", and vice > versa. I imagine this would take some major reworking of > 2.1, so maybe in 2.2? > > --Quanah > > >
Matched values, I think, doesn't fulfill this request. However, the request is pretty much the same as ITS#2432 so I suspect the 2.1 approach you suggest for it may work for this. I also note that 2.2 will offer a number of other capabilities which, if not outright supporting such things, will make implementing such things a lot easier. (E.g., virtual directory work, SLAPI, etc..) At 06:41 PM 4/8/2003, hyc@highlandsun.com wrote: >This feature has been implemented in OpenLDAP 2.1 since release 2.1.3. See >the ldapsearch usage message, "matched values filter". The man page appears >to be missing documentation on this feature at the moment. > > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support > >> -----Original Message----- >> From: owner-openldap-bugs@OpenLDAP.org >> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of quanah@stanford.edu > >> Full_Name: Quanah Gibson-Mount >> Version: 2.1.16 >> OS: Solaris 8 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.82) >> >> >> Hello, >> >> We have found that it would be useful for attributes like >> "gn, givenname" to >> return the attribute they were searched on. I.e., if I >> search on "gn", I would >> like to see the returned attribute be "gn" rather than >> "givenname", and vice >> versa. I imagine this would take some major reworking of >> 2.1, so maybe in 2.2? >> >> --Quanah >> >> >>
It's unclear of whether you are asking for something different than ITS#2432 or asking for Matched Values (draft-ietf-ldapext-matchedval) support. As the former was separately requested and the latter is already supported, I see little reason to track this request. If you are requesting something significantly different from ITS#2432 or Matched Values, I suggest you provide some clarification. Otherwise, this issue will be closed. Regards, Kurt
changed notes changed state Open to Suspended
moved from Incoming to Software Enhancements
--On Thursday, April 10, 2003 5:09 PM +0000 Kurt Zeilenga <openldap-its@OpenLDAP.org> wrote: > It's unclear of whether you are asking for something different than > ITS#2432 or asking for Matched Values (draft-ietf-ldapext-matchedval) > support. As the former was separately requested and the latter is already > supported, I see little reason to track this request. If you are > requesting something significantly different from ITS#2432 or Matched > Values, I suggest you provide some clarification. Otherwise, this issue > will be closed. Yes, this is different that 2432. 2432 is specifically for the purpose of having AUXILIARY objectClasses that do mapping of a fake attribute (say foo) to other attributes in the directory. I think Howard's answer was sufficient for that. For #2431, specifically what we are looking at, is attributes defined in the schema's distributed with OpenLDAP that have multiple names, i.e., gn and given name, cn and common name, etc. What I was asking for, is that I can do something like the following: ldapsearch uid=quanah cn cn: Quanah Gibson-Mount ldapsearch uid=quanah commonname commonname: Quanah Gibson-Mount This is not the behavior I see at this time. Instead I see: ldapsearch uid=quanah commonname cn: Quanah Gibson-Mount I believe Howard's answer is yes, this can be done, but I'm not clear whether or not that is correct from your response. --Quanah -- Quanah Gibson-Mount Senior Systems Administrator ITSS/TSS/Computing Systems Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
At 10:17 AM 4/10/2003, quanah@stanford.edu wrote: >I believe Howard's answer is yes, this can be done, but I'm not clear >whether or not that is correct from your response. I'm not all that familiar with back-meta/ldap, so I differ to Howard and others on whether that can be done. However, I think its clear that this can be done in HEAD with a post-operation plugin and, eventually, with virtual view capabilities. When these become more available/usable, I would not be surprised to find the non-standard NAMEs be dropped from schema. E.g., ( 2.5.4.3 NAME 'cn' SUP name ) When that is done, the problem becomes one of aliasing or "virtual views". Hence, I think ITS#2431 and ITS#2432 are really not that different. Kurt
--On Thursday, April 10, 2003 10:45 AM -0700 "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote: > At 10:17 AM 4/10/2003, quanah@stanford.edu wrote: >> I believe Howard's answer is yes, this can be done, but I'm not clear >> whether or not that is correct from your response. > > I'm not all that familiar with back-meta/ldap, so I differ > to Howard and others on whether that can be done. > > However, I think its clear that this can be done in HEAD with > a post-operation plugin and, eventually, with virtual view > capabilities. > > When these become more available/usable, I would not be surprised > to find the non-standard NAMEs be dropped from schema. E.g., > ( 2.5.4.3 NAME 'cn' SUP name ) > > When that is done, the problem becomes one of aliasing or "virtual > views". Hence, I think ITS#2431 and ITS#2432 are really not > that different. okay. :) --Quanah -- Quanah Gibson-Mount Senior Systems Administrator ITSS/TSS/Computing Systems Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
changed notes
changed state Suspended to Closed
moved from Software Enhancements to Archive.Software Enhancements
reject per past discussions (regarding similar requests)