ietf-ldapbis

ietf-ldapbis@openldap.org

13 discussions

Name Forms without DIT Structure Rules
by Michael Ströder 30 Apr '15

30 Apr '15

HI! (Hope there are still enough interested subscribers here...) An interop question to server vendors who already implemented Name Forms and DIT Structure Rules: Do you enforce RDN name checks if there is a name form referencing the structural object class of an entry but no governing structural rule? There seem to be different interpretations: https://lists.forgerock.org/pipermail/opendj/2015-April/004508.html http://www.openldap.org/lists/openldap-technical/201504/msg00303.html Ciao, Michael.

1 0

New Version Notification for draft-seantek-ldap-pkcs9-00.txt
by Sean Leonard 10 Sep '14

10 Sep '14

Hello old ldapbis list: Looks like this place is deserted...nevertheless, I wanted to inform list members of this proposal to add definitions to the IANA registry. These are based on PKCS #9, which predates ldapbis. However, the definitions in PKCS #9 never got added. So, this document adds them. Feedback is requested, as well as suggestions on how best to proceed with this to get IETF consensus. Thanks, Sean -------- Forwarded Message -------- Subject: New Version Notification for draft-seantek-ldap-pkcs9-00.txt Date: Wed, 10 Sep 2014 06:56:51 -0700 From: internet-drafts(a)ietf.org To: Sean Leonard <dev+ietf(a)seantek.com>, Sean Leonard <dev+ietf(a)seantek.com> A new version of I-D, draft-seantek-ldap-pkcs9-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-ldap-pkcs9 Revision: 00 Title: Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9 Document date: 2014-09-10 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-seantek-ldap-pkcs9-00.txt Status: https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/ Htmlized: http://tools.ietf.org/html/draft-seantek-ldap-pkcs9-00 Abstract: PKCS #9 includes several useful definitions that are not yet reflected in the LDAP IANA registry. This document adds those definitions to the IANA registry. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat

1 0

Any case where same controlType is used twice?
by Michael Ströder 12 Apr '12

12 Apr '12

HI! Is there any known LDAP extended control which is used more than once in a LDAPRequest or LDAPResponse? Or can a client expect that a controlType is only used exactly once in the list of returned controls in a single message? Up to now I've never seen something like this but one never knows. Ciao, Michael.

1 0

ldapadd issue in custom objectclass
by pankaj bhamare 25 Jun '09

25 Jun '09

hi, I have created custom object class and its attribute attributetype ( 1.2006.08.20.1 NAME 'DealerCode' DESC 'RFC2256: Dealer code' SUP name ) attributetype ( 1.2006.08.20.2 NAME 'GroupCode' DESC 'RFC2256: Group code' SUP name ) objectclass ( 1.2006.08.20.3 NAME 'DealerMaster' DESC 'Information regarding dealer' SUP top STRUCTURAL MUST ( DealerCode ) MAY ( GroupCode $ mail )) i have stored this file in /etc/openldap/schema/dealer.schema then i have include this file in slapd.conf file then i have started server. For testing purpose i have created one ldif file dn: DealerCode=PankajB,dc=abacus,dc=com DealerCode: PankajB objectClass: DealerMaster When i execute this ldif file with below mention command ldapadd -x -D "cn=Manager,dc=abacus,dc=com" -W -f dealerentry.ldif It ask for ldap password after entering the password "adding new entry "DealerCode=PankajB,dc=abacus,dc=com" appears on sceen then it hangs Awaiting for your reply. Thanks in advance

3 2

LDAP Bar BOF Tonight 8pm.
by Ludovic Poitou 19 Nov '08

19 Nov '08

Hi, As Kurt mentioned in the App Area, there will be an LDAP Bar BOF this Wednesday for those interested that are in Minneapolis. Meet in the lobby at 8pm and we'll figure out a place to talk over dinner. Overview (copied from initial LDAP BOF proposal): Lightweight Directory Access Protocol (LDAP) BOF Chair(s): TBD The purpose of this BOF is to discuss the formation of a working group to undertake LDAP standards work. It is conceived that the proposed WG would undertake both the revision of existing technical specifications for LDAP extensions and the engineering of new LDAP extensions. There are numerous existing technical specifications for LDAP extensions. Most of the Standard Track specifications were published prior to the current LDAP "core" specification [RFC 4510] and are in the need of revision. In some cases, it may be more appropriate to move the extension off the Standards Track. While the work of determining which RFC should be revised (or moved off to a different track), and prioritization of the work, could be deferred to the WG, it is hoped that the BOF will reach some conclusions as to which revision work is of the highest priority. There are also numerous extensions to LDAP which seem worthy of standardization. It is hoped that the BOF will reach some conclusion as to short list of new extension work items to be undertaken (at least initially) by the proposed WG. That short list might include, for instance, in LDAP Transactions and Extensions for X.500 Alignment. By including both revision and new engineering work items in a single working group it is hoped that the sufficient participation levels will be maintained to make reasonable progress in both revision and new engineering work. Ludovic Poitou Sun Microsystems Inc. OpenDS Community Lead Directory Services http://blogs.sun.com/Ludo/ Grenoble Engineering Center - France Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Standard test suite for LDAP client testing?
by Emiel van de Laar 20 Sep '08

20 Sep '08

Hello list, I'm posting this to two mailing lists... Hope no one minds. I'm working on an LDAP client API implementation. To test the API I'm looking for a standard test set (data) which can be loaded into various server implementations. The closest thing I have found so far is the following project which seems to be quite dormant. http://www.opengroup.org/dif/blits/ The LDIFs I tried worked for 99%; a couple of errors were found relating to schema. It is quite dated... And then there are the test cases... which could probably be updated as well. Any one have any other recommendations? Perhaps someone is involved with BLITS or something similar? I could flesh out my own test data and test cases but I'd rather build on something that already exists. Thanks in advance! Regards, - Emiel van de Laar

2 1

IETF#73 LDAP BOF Proposal
by Kurt Zeilenga 18 Sep '08

18 Sep '08

I intend to send a BOF proposal for IETF#73 for the purpose of forming a new working group to undertake LDAP standards work. Below is a rough proposal for your consideration and comments. (I am surely biased as what new engineering efforts the proposed WG ought take on, please do feel free to offer other possible work items.) -- Kurt Lightweight Directory Access Protocol (LDAP) BOF Chair(s): TBD The purpose of this BOF is to discuss the formation of a working group to undertake LDAP standards work. It is conceived that the proposed WG would undertake both the revision of existing technical specifications for LDAP extensions and the engineering of new LDAP extensions. There are numerous existing technical specifications for LDAP extensions. Most of the Standard Track specifications were published prior to the current LDAP "core" specification [RFC 4510] and are in the need of revision. In some cases, it may be more appropriate to move the extension off the Standards Track. While the work of determining which RFC should be revised (or moved off to a different track), and prioritization of the work, could be deferred to the WG, it is hoped that the BOF will reach some conclusions as to which revision work is of the highest priority. There are also numerous extensions to LDAP which seem worthy of standardization. It is hoped that the BOF will reach some conclusion as to short list of new extension work items to be undertaken (at least initially) by the proposed WG. That short list might include, for instance, in LDAP Transactions and Extensions for X.500 Alignment. By including both revision and new engineering work items in a single working group it is hoped that the sufficient participation levels will be maintained to make reasonable progress in both revision and new engineering work.

13 16

Revising attribute type 'mail'?
by Michael Ströder 10 Sep '08

10 Sep '08

HI! Given that RFC 5336 and RFC 5337 are out now the question arises whether 1. attribute type 'mail' defined in RFC 4524 should be revised to use LDAP syntax DirectoryString instead of IA5String with a new OID but the same NAME 'mail' or 2. a new attribute type should be defined with a different NAME. Personally I tend to 1. Ciao, Michael.

3 2

Change of name forms and DIT structure rules when renaming an entry
by Michael Ströder 21 Aug '08

21 Aug '08

HI! when displaying an input form for renaming an entry I'd like to let the user search for possible new superior DNs. If applicable I'd like to construct the search filter derived from applicable DIT structure rules. So the question is how to find the structural object classes which are allowed for superior entries. X.501 (1993) section 12.6.5 says: "Each object and alias entry is governed by a single DIT structure rule." Currently I determine the governing structure rule by looking up the best matching name form for 1. the structural object class and 2. the current old RDN. Then I can derive the possible superior structure rules and lookup the superior structural object classes via the accompanying name forms. But now I wonder what to do in case the user wants to change the RDN together with a new superior DN in one rename operation? From my understanding changing the RDN could lead to another governing structure rule. Is that right? Ciao, Michael. P.S.: I'd appreciate interop testing over Internet regarding this... -- Michael Ströder E-Mail: michael(a)stroeder.com http://www.stroeder.com

2 3

subscribe
by Radha Krishna 19 Aug '08

19 Aug '08

**************************************************************************** **************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

ietf-ldapbis