ldapadd issue in custom objectclass

LDAP Bar BOF Tonight 8pm.

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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Standard test suite for LDAP client testing?

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

Standard test suite for LDAP client testing?

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

Revising attribute type 'mail'?

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.

IETF#73 LDAP BOF Proposal

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.

Change of name forms and DIT structure rules when renaming an entry

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 <at> stroeder.com
http://www.stroeder.com

Several name forms for a structural object class?

HI!

Looking at section 4.1.7.2. "Name Forms" in 
http://www.ietf.org/rfc/rfc4512.txt it's not really clear to me whether 
more than one name form may be associated with the same structural 
object class. I think it's possible (and I've implemented it that way in 
web2ldap) but the server I'm currently testing with disallows it.

Ciao, Michael.

object class to add mail attribute for organization?

Hi,

I am trying to find what is the standardized (or recommended) auxiliary
object class, which permits addition of mail attribute for organization
entry. Organization object class does not contain mail attribute. (As it
does not contain labeledURI attribute, but by including labeledURIObject
auxiliary object class you can add URI addresses for organization entries.
By the way - is the labeledURIObject still valid object class definition?)

Organizations use widely customer service email addresses like
info <at> company.com or sales <at> company.com. That is the reason why I would like
to add mail attribute to O or OU entry. I am trying to avoid inventing new
object classes nor do I want to turn off schema checking.
Is extensibleObject a solution to my need? Is it commonly supported by LDAP
servers and recommended way to allow addition of new attributes to entries? 

I am wondering why these important attribute types (labeledURI and mail) are
not included in RFC4519 standard schema for user applications, because now
there is no easy way to add URI addresses or email addresses to
organizations or organizational units?

Would it be good idea to collect all often needed attributes, which are for
historical reasons not part of core standard to one or more auxiliary object
class?

Best regards,

Jyri

jyri-pekka.tahtinen <at> netum.fi

WG Action: Conclusion of LDAP (v3) Revision (ldapbis)

The LDAP (v3) Revision (ldapbis) in the Applications Area has concluded.

The IESG contact persons are Lisa Dusseault and Ted Hardie.

+++

The LDAPBIS working group has concluded. With the publication of
RFCs 4410-4424, the working group has completed all of the items
on its charter. This task has required a complex and interlocked
set of standards to be updated together, and its successful completion
is a testament to the working group's abilities and stamina.
The IESG congratulates the chairs, document authors, and participants
in the working group, and it thanks them for their efforts. The mailing
list will remain active.

BCP 64 RFC 4520 on Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)

A new Request for Comments is now available in online RFC libraries.

        BCP 64        
        RFC 4520

        Title:      Internet Assigned Numbers Authority (IANA) 
                    Considerations for the Lightweight Directory Access 
                    Protocol (LDAP) 
        Author:     K. Zeilenga
        Status:     Best Current Practice
        Date:       June 2006
        Mailbox:    Kurt <at> OpenLDAP.org
        Pages:      19
        Characters: 34298

        I-D Tag:    draft-ietf-ldapbis-bcp64-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4520.txt

This document provides procedures for registering extensible elements
of the Lightweight Directory Access Protocol (LDAP).  The document also
provides guidelines to the Internet Assigned Numbers Authority (IANA)
describing conditions under which new values can be assigned.  This document specifies an Internet Best
Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.

This document is a product of the LDAP (v3) Revision
Working Group of the IETF.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce