From ldapext-bounces@ietf.org Wed Jun 2 11:20:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27294 for ; Wed, 2 Jun 2004 11:20:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVXEN-00050T-NS; Wed, 02 Jun 2004 11:00:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVStL-0005PT-ST for ldapext@megatron.ietf.org; Wed, 02 Jun 2004 06:22:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12747 for ; Wed, 2 Jun 2004 06:22:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVSsy-0000ZZ-WB for ldapext@ietf.org; Wed, 02 Jun 2004 06:22:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVSr7-0007HP-00 for ldapext@ietf.org; Wed, 02 Jun 2004 06:20:21 -0400 Received: from [62.4.23.8] (helo=sgi2.linagora.com) by ietf-mx with esmtp (Exim 4.12) id 1BVSpv-0006T2-00 for ldapext@ietf.org; Wed, 02 Jun 2004 06:19:07 -0400 Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id C12131982BA; Wed, 2 Jun 2004 12:18:39 +0200 (CEST) Received: from [192.168.0.185] (unknown [192.168.0.185]) by sgi2.linagora.com (Postfix) with ESMTP id 390A2198195; Wed, 2 Jun 2004 12:18:39 +0200 (CEST) From: Alexandre PAUZIES Organization: LINAGORA To: Steven Legg Subject: Re: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt Date: Wed, 2 Jun 2004 12:18:34 +0200 User-Agent: KMail/1.6.52 References: <1395B4B334FCC143B36AF788E68B6381015C014A@ausyms21.ca.com> <40A99CA9.8030307@adacel.com.au> In-Reply-To: <40A99CA9.8030307@adacel.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200406021218.34124.alexandre.pauzies@linagora.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 02 Jun 2004 08:42:55 -0400 Cc: ldapext@ietf.org, "Ramsay, Ron" X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Le Tuesday 18 May 2004 07:18, Steven Legg a =E9crit=A0: > Ramsay, Ron wrote: > > Why isn't this covered by the old matching rules? The X.500 standard > > > > caseIgnoreMatch applies to UTF-8 and matches case (though they may not > > have defined the meaning of space?). > > These matching rules strip out diacriticals before performing the case > ignore match, which is something the existing case ignore matching rules > don't do. > > The names of these matching rules are clearly causing confusion. A better > name for caseIgnoreNonasciiMatch, for example, would be something like > caseIgnoreCanonicalLatinMatch or caseIgnoreBasicLatinMatch. Hi, you're right, the name of those matching rules isn't clear, I'm french, so = my=20 work is focused on Latin characters, but may be this could be useful for=20 other kind of characters, I don't know, that's why I choose to ignore all=20 non-ascii characters instead of only latin's ones. Do you think this could only work on latin characters ? Thanks for your comment. Alexandre. =2D-=20 Alexandre Pauzi=E8s LINAGORA - Soci=E9t=E9 de services en Logiciels Libres http://www.linagora.com/ - T=E9l: 01.58.18.68.28 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 4 02:49:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15520 for ; Fri, 4 Jun 2004 02:49:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW8TS-0004pP-MC; Fri, 04 Jun 2004 02:46:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW8N5-0003S1-TC for ldapext@megatron.ietf.org; Fri, 04 Jun 2004 02:40:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15022 for ; Fri, 4 Jun 2004 02:40:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW8My-00046P-RF for ldapext@ietf.org; Fri, 04 Jun 2004 02:40:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW8MC-0003jL-00 for ldapext@ietf.org; Fri, 04 Jun 2004 02:39:12 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BW8La-0003HS-00 for ldapext@ietf.org; Fri, 04 Jun 2004 02:38:35 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Fri, 04 Jun 2004 16:37:17 +1000 Received: (qmail 17284 invoked from network); 4 Jun 2004 06:37:44 -0000 Received: from unknown (HELO adacel.com.au) (10.32.24.165) by nexus.adacel.com with SMTP; 4 Jun 2004 06:37:44 -0000 Message-ID: <40C018B7.7010301@adacel.com.au> Date: Fri, 04 Jun 2004 16:37:43 +1000 From: Steven Legg User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandre PAUZIES Subject: Re: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt References: <1395B4B334FCC143B36AF788E68B6381015C014A@ausyms21.ca.com> <40A99CA9.8030307@adacel.com.au> <200406021218.34124.alexandre.pauzies@linagora.com> In-Reply-To: <200406021218.34124.alexandre.pauzies@linagora.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA15022 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Alexandre, Alexandre PAUZIES wrote: > Le Tuesday 18 May 2004 07:18, Steven Legg a =E9crit : >=20 >>Ramsay, Ron wrote: >> >>>Why isn't this covered by the old matching rules? The X.500 standard >>> >> >> > caseIgnoreMatch applies to UTF-8 and matches case (though they may n= ot >> > have defined the meaning of space?). >> >>These matching rules strip out diacriticals before performing the case >>ignore match, which is something the existing case ignore matching rule= s >>don't do. >> >>The names of these matching rules are clearly causing confusion. A bett= er >>name for caseIgnoreNonasciiMatch, for example, would be something like >>caseIgnoreCanonicalLatinMatch or caseIgnoreBasicLatinMatch. >=20 >=20 > Hi, >=20 > you're right, the name of those matching rules isn't clear, I'm french,= so my=20 > work is focused on Latin characters, but may be this could be useful fo= r=20 > other kind of characters, I don't know, that's why I choose to ignore a= ll=20 > non-ascii characters instead of only latin's ones. >=20 > Do you think this could only work on latin characters ? I don't know enough about non-Latin scripts to answer one way or the othe= r. So from a position of ignorance, I suggest that you choose a name that re= flects what the matching rule is about, to the extent that you have defined it. If so= me later specification updates the matching rule to apply canonicalization to non-= Latin scripts then that specification can always define an additional name that= reflects the rule's wider applicability. Matching rules are permitted to have more= than one name. Regards, Steven >=20 > Thanks for your comment. >=20 > Alexandre. >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 4 06:18:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26443 for ; Fri, 4 Jun 2004 06:18:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWBkr-00027Z-Ad; Fri, 04 Jun 2004 06:16:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWBgI-0000rk-Gy for ldapext@megatron.ietf.org; Fri, 04 Jun 2004 06:12:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26253 for ; Fri, 4 Jun 2004 06:12:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWBgF-00008k-Ug for ldapext@ietf.org; Fri, 04 Jun 2004 06:12:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWBfK-0007ZT-00 for ldapext@ietf.org; Fri, 04 Jun 2004 06:11:11 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BWBew-0007CR-00 for ldapext@ietf.org; Fri, 04 Jun 2004 06:10:46 -0400 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.30) id 1BWBeq-0003X5-SJ; Fri, 04 Jun 2004 12:10:40 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1BWBen-0000vd-23; Fri, 04 Jun 2004 12:10:37 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BWBel-0002je-00; Fri, 4 Jun 2004 12:10:35 +0200 From: Hallvard B Furuseth Message-Id: To: Alexandre PAUZIES Subject: Re: [ldapext] draft-pauzies-ldap-schema-nonascii-mr-00.txt In-Reply-To: <200406021218.34124.alexandre.pauzies@linagora.com> References: <1395B4B334FCC143B36AF788E68B6381015C014A@ausyms21.ca.com> <40A99CA9.8030307@adacel.com.au> <200406021218.34124.alexandre.pauzies@linagora.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 4 Jun 2004 12:10:35 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: "Ramsay, Ron" , ldapext@ietf.org, Steven Legg X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Alexandre PAUZIES writes: > you're right, the name of those matching rules isn't clear, I'm > french, so my work is focused on Latin characters, but may be this > could be useful for other kind of characters, I don't know, that's why > I choose to ignore all non-ascii characters instead of only latin's > ones. >=20 > Do you think this could only work on latin characters ? Sounds like this message got lost, so I'm reposting. I've appended a few new points at the end (after the =3D=3D=3D=3D's). From: Hallvard B Furuseth Date: Wed, 19 May 2004 10:14:21 +0200 Alexandre PAUZIES writes: > http://www.ietf.org/internet-drafts/draft-pauzies-ldap-schema-nonascii-mr= -00.txt The draft says: > When using thoses rules, non-ASCII characters such as letters with > accents are converted (when UTF-8 compatibility conversion is > possible RFC 2044 [RFC2044]) to ASCII characters (same letter without > accent) before the match. First, "same letter without accent" is not a good rule, and I don't know of any standard tables one can use to implement it anyway. When I asked the Unicode mailinglist (unicode@unicode.org) about a similar problem, the recommendations were: - use the NFKD decompositions from the UCD, then see if the first character is an ASCII character, and if so, remove diacritics in the 03xx block (that have a "Mn" general category and a non-zero combining class). - or produce the NFD normalisation of the text, and remove all characters with a non-zero combining class. Unlike NFD, NFKD would for example convert the trademark symbol to "TM" and superscript 2 to "2". However, many people will find a rule like above close to what they need, but unfortunately useless or poor for their purpose. For example, an important special case I'd want in our server is to translate "=F8" to "o", both for foreigners who have been told plain-ASCII names and so that Norwegian "=F8" would match Swedish "=F6". Other examples (from D. Starner): Diagraphs can be treated as titlecase or capital or intelligently. 00FE - "th" 00DE - "TH" 00F0 - "dh" ("th"?) OOD0 - "DH" ("TH"?) 0108 - "CH" (Esperanto) 0109 - "ch" 011C, 011D - "GH", "gh" (E-o) 0124, 0125 - "HH", "hh" (") 0134, 0135 - "JH", "jh" (") 015C, 015D - "SH", "sh" (") 017F - "s" Depending on your goals, 015F & 0161 could be "sh", 0163 "ts", 017D "zh", etc. 0195 - "hw" 01A3 - "gh"(?) 01BF - "w" 01C0 - "|" ("c"?) 01C1 - "||"? ("x"?) 01C3 - "!" ("q"?) 0223 - "w" ("ou"? "8"?) I omitted most capitals and those that can be found by decomposition or name stripping, as well a bunch I don't know anything about. My impression from the Unicode mailinglist is that there are a lot of such special cases not covered by Unicode, and that the usual solution is to amend the Unicode character mappings with private mappings at need. I think no comprehensive list of such special cases exists. What such a list would consist of would in any case depend on e.g. which languages/cultures/geographical areas it applies to. Kenneth Whistler said: You could search in the Unicode email archives for "fallback". Much of that discussion will be about fallback display of glyphs, but there have also been discussions about fallback conversion of characters. There might be further examples or pointers somewhere in there. (I did that, but didn't find much which related to my purpose at the time. Don't remember if the matches would relate to your more general rules. URL . Note the user name and password at that page.) Anyway, I suggest that the draft should not specify exactly how these rules match, but just give a default rule such as suggested above and allow private amendments. How much to allow implementations to differ from the default would depend on the intended purpose of these matching rules. So what is the intended purpose of these rules? For example, - Are they only intended to be useful for Latin scripts, or could people who use other scripts add similar rules? - another suggestion at the Unicode mailinglist was: for Korean syllables (U+AC00 - U+Dxxx), you can use 'Hangul Syllable Short Names' that can be algorithmically derived with small tables. - What is the best trade-off between getting successful matches of strings intended to be equivalent, and not getting too many matches due to loss of semantics? For example, how about non-letters? Would it be useful to let some or all punctuation match each other, or to treat it all as space? That way "J. Doe" would match "J Doe". Once the intent is clarified, I suggest you take this to the Unicode mailinglist for advice. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A few other notes: - I'm not sure what the point of the ordering rule is. Even though I'd like =F6 to match o, they should be sorted as different characters (because =F6 usually means =F8 here). caseIgnoreOrderingMatch does not give the desired result either, but again we are just swapping one wrong rule with another wrong rule. - FYI, caseIgnoreMatch & co are about to be updated to do some string preparation, see and from the LDAPbis (LDAP revision) working group. --=20 Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 7 11:22:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23246 for ; Mon, 7 Jun 2004 11:22:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXLtK-0003Vh-GM; Mon, 07 Jun 2004 11:18:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXLhw-0000iT-SO for ldapext@megatron.ietf.org; Mon, 07 Jun 2004 11:06:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22388 for ; Mon, 7 Jun 2004 11:06:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXLhv-0003Kz-EA for ldapext@ietf.org; Mon, 07 Jun 2004 11:06:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXLgn-0002pz-00 for ldapext@ietf.org; Mon, 07 Jun 2004 11:05:29 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BXLfu-0001vq-00 for ldapext@ietf.org; Mon, 07 Jun 2004 11:04:34 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 07 Jun 2004 09:04:03 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 07 Jun 2004 09:03:41 -0600 From: "Steve Sonntag" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartB2933BDD.0__=" Subject: [ldapext] draft-ietf-ldapext-ldap-java-api-19.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB2933BDD.0__= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Draft 19 of the java ldap API has been submitted (attached). We have tried to address all the comments and suggestions made against the previous draft. Any review is appreciated. -Steve Sonntag --=__PartB2933BDD.0__= Content-Type: text/plain; name="draft-ietf-ldapext-ldap-java-api-19.txt" Content-Disposition: attachment; filename="draft-ietf-ldapext-ldap-java-api-19.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA22388 Content-Transfer-Encoding: quoted-printable Network Working Group Rob Weltman=20 INTERNET-DRAFT Netscape Communications Corp.=20 Intended Category: Standards Track Christine Tomlinson=20 June 7, 2004 Sun Microsystems, Inc.=20 Expires December 6, 2004 Steven Sonntag=20 Novell, Inc.=20 =20 =20 The Java LDAP Application Program Interface=20 draft-ietf-ldapext-ldap-java-api-19.txt=20 =20 =20 Status of this Memo=20 =20 By submitting this Internet-Draft, I certify that any applicable=20 patent or other IPR claims of which I am aware have been disclosed,=20 and any of which I become aware will be disclosed, in accordance with=20 RFC 3668.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as=20 Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 This Internet-Draft will expire on November 22, 2004.=20 =20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2004). All Rights Reserved.=20 =20 =20 Abstract=20 =20 This document defines a Java [JAVA] language application program=20 interface to the Lightweight Directory Access Protocol Version 3=20 (LDAP) [LDAPv3], in the form of a class library.=20 =20 =20 Conventions Used in this Document=20 =20 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"=20 =20 Expires December 6, 2004 [Page 1]=20 JAVA LDAP API April 2004=20 =20 =20 in this document are to be interpreted as defined in "Key words for=20 use in RFCs to Indicate Requirement Levels" [KEYWORDS].=20 =20 =20 =20 Expires December 6, 2004 [Page 2]=20 JAVA LDAP API April 2004=20 =20 =20 1. Overview...........................................................10=20 1.1 The LDAP model....................................................10=20 1.2 Package name......................................................11=20 1.3 The LDAP classes..................................................11=20 1.4 The LDAP asynchronous methods.....................................12=20 1.5 Interfaces........................................................12=20 1.6 Classes...........................................................12=20 1.7 Exceptions........................................................15=20 1.8 LDAP API use......................................................15=20 2. The Java LDAP classes..............................................17=20 2.1 public class LDAPAttribute........................................18=20 2.1.1 Constructors....................................................18=20 2.1.2 addValue........................................................19=20 2.1.3 compareTo.......................................................19=20 2.1.4 getBaseName.....................................................19=20 2.1.5 getByteValues...................................................20=20 2.1.6 getByteValueArray...............................................20=20 2.1.7 getLangSubtype..................................................20=20 2.1.8 getName.........................................................20=20 2.1.9 getStringValueArray.............................................20=20 2.1.10 getStringValues................................................20=20 2.1.11 getSubtypes....................................................21=20 2.1.12 hasSubtype.....................................................21=20 2.1.13 hasSubtypes....................................................21=20 2.1.14 removeValue....................................................21=20 2.1.15 size...........................................................22=20 2.2 public class LDAPAttributeSchema..................................22=20 2.2.1 Constructors....................................................22=20 2.2.2 getEqualityMatchingRule.........................................23=20 2.2.3 getOrderingMatchingRule.........................................24=20 2.2.4 getSubstringMatchingRule........................................24=20 2.2.5 getSuperior.....................................................24=20 2.2.6 getSyntaxString.................................................24=20 2.2.7 getUsage........................................................24=20 2.2.8 isCollective....................................................24=20 2.2.9 isSingleValued..................................................25=20 2.2.10 isUserModifiable...............................................25=20 2.2.11 Constants of LDAPAttributeSchema...............................25=20 2.3 public class LDAPAttributeSet.....................................25=20 2.3.1 Constructors....................................................26=20 2.3.2 clone...........................................................26=20 2.3.3 getAttribute....................................................26=20 2.3.4 getSubset.......................................................26=20 2.4 public interface LDAPAuthHandler..................................28=20 2.4.1 getAuthProvider.................................................28=20 2.5 public class LDAPAuthProvider.....................................28=20 2.5.1 Constructors....................................................28=20 2.5.2 getDN...........................................................29=20 2.5.3 getPassword.....................................................29=20 2.6 public interface LDAPBindHandler..................................29=20 2.6.1 bind............................................................29=20 2.7 public class LDAPCompareAttrNames.................................30=20 =20 Expires December 6, 2004 [Page 3]=20 JAVA LDAP API April 2004=20 =20 =20 2.7.1 Constructors....................................................30=20 2.7.2 compare.........................................................31=20 2.7.3 equals..........................................................31=20 2.7.4 getLocale.......................................................32=20 2.7.5 setLocale.......................................................32=20 2.8 public class LDAPConnection.......................................32=20 2.8.1 Constructors....................................................32=20 2.8.2 abandon.........................................................33=20 2.8.3 add.............................................................34=20 2.8.4 addUnsolicitedNotificationListener..............................34=20 2.8.5 bind............................................................35=20 2.8.6 clone...........................................................38=20 2.8.7 compare.........................................................39=20 2.8.8 connect.........................................................39=20 2.8.9 delete..........................................................40=20 2.8.10 disconnect.....................................................41=20 2.8.11 extendedOperation..............................................41=20 2.8.12 fetchSchema....................................................42=20 2.8.13 finalize.......................................................42=20 2.8.14 getAuthenticationDN............................................42=20 2.8.15 getAuthenticationMethod........................................43=20 2.8.16 getConstraints.................................................43=20 2.8.17 getHost........................................................43=20 2.8.18 getPort........................................................43=20 2.8.19 getProperty....................................................44=20 2.8.20 getProtocolVersion.............................................44=20 2.8.21 getResponseControls............................................45=20 2.8.22 getSaslBindCallbackHandler.....................................45=20 2.8.23 getSaslBindProperties..........................................45=20 2.8.24 getSchemaDN....................................................45=20 2.8.25 getSearchConstraints...........................................46=20 2.8.26 getSocketFactory...............................................46=20 2.8.27 isBound........................................................46=20 2.8.28 isConnected....................................................46=20 2.8.29 isTLS..........................................................46=20 2.8.30 modify.........................................................46=20 2.8.31 read...........................................................48=20 2.8.32 removeUnsolicitedNotificationListener..........................49=20 2.8.33 rename.........................................................50=20 2.8.34 search.........................................................51=20 2.8.35 setConstraints.................................................54=20 2.8.36 setSocketFactory...............................................54=20 2.8.37 startTLS.......................................................54=20 2.8.38 stopTLS........................................................55=20 2.8.39 Constants of LDAPConnection....................................55=20 2.9 public class LDAPConstraints......................................56=20 2.9.1 Constructors....................................................56=20 2.9.2 getControls.....................................................57=20 2.9.3 getHopLimit.....................................................57=20 2.9.4 getProperty.....................................................57=20 2.9.5 getReferralFollowing............................................57=20 2.9.6 getTimeLimit....................................................57=20 =20 Expires December 6, 2004 [Page 4]=20 JAVA LDAP API April 2004=20 =20 =20 2.9.7 setControls.....................................................58=20 2.9.8 setHopLimit.....................................................58=20 2.9.9 setProperty.....................................................58=20 2.9.10 setReferralFollowing...........................................59=20 2.9.11 setReferralHandler.............................................59=20 2.9.12 setTimeLimit...................................................59=20 2.10 public class LDAPControl.........................................59=20 2.10.1 Constructors...................................................60=20 2.10.2 clone..........................................................60=20 2.10.3 getID..........................................................60=20 2.10.4 getValue.......................................................60=20 2.10.5 isCritical.....................................................60=20 2.10.6 register.......................................................61=20 2.10.7 setValue.......................................................61=20 2.11 public class LDAPDITContentRuleSchema............................61=20 2.11.1 Constructors...................................................61=20 2.11.2 getAuxiliaryClasses............................................62=20 2.11.3 getOptionalAttributes..........................................62=20 2.11.4 getPrecludedAttributes.........................................63=20 2.11.5 getRequiredAttributes..........................................63=20 2.12 public class LDAPDITStructureRuleSchema..........................63=20 2.12.1 Constructors...................................................63=20 2.12.2 getNameForm....................................................64=20 2.12.3 getRuleID......................................................64=20 2.12.4 getSuperiors...................................................64=20 2.13 public class LDAPDN..............................................65=20 2.13.1 equals.........................................................65=20 2.13.2 escapeRDN......................................................65=20 2.13.3 explodeDN......................................................65=20 2.13.4 explodeRDN.....................................................66=20 2.13.5 isValid........................................................66=20 2.13.6 normalize......................................................66=20 2.13.7 unescapeRDN....................................................66=20 2.14 public class LDAPEntry...........................................67=20 2.14.1 Constructors...................................................67=20 2.14.2 compareTo......................................................67=20 2.14.3 getAttribute...................................................68=20 2.14.4 getAttributeSet................................................68=20 2.14.5 getDN..........................................................68=20 2.15 public class LDAPException.......................................69=20 2.15.1 Constructors...................................................69=20 2.15.2 getCause.......................................................70=20 2.15.3 getLDAPErrorMessage............................................70=20 2.15.4 getResultCode..................................................71=20 2.15.5 getMatchedDN...................................................71=20 2.15.6 resultCodeToString.............................................71=20 2.15.7 toString.......................................................72=20 2.15.8 Result codes...................................................72=20 2.16 public class LDAPExtendedOperation...............................73=20 2.16.1 Constructors...................................................73=20 2.16.2 getID..........................................................74=20 2.16.3 getValue.......................................................74=20 =20 Expires December 6, 2004 [Page 5]=20 JAVA LDAP API April 2004=20 =20 =20 2.16.4 setValue.......................................................74=20 2.17 public class LDAPExtendedResponse................................74=20 2.17.1 getID..........................................................74=20 2.17.2 getValue.......................................................74=20 2.17.3 register.......................................................75=20 2.18 public class LDAPLocalException..................................75=20 2.18.1 Constructors...................................................75=20 2.19 public class LDAPMatchingRuleSchema..............................76=20 2.19.1 Constructors...................................................76=20 2.19.2 getAttributes..................................................77=20 2.19.3 getSyntaxString................................................77=20 2.20 public class LDAPMatchingRuleUseSchema...........................77=20 2.20.1 Constructors...................................................77=20 2.20.2 getAttributes..................................................78=20 2.21 public class LDAPMessage.........................................78=20 2.21.1 getControls....................................................78=20 2.21.2 getMessageID...................................................79=20 2.21.3 getType........................................................79=20 2.22 public interface LDAPMessageQueue................................79=20 2.22.1 getMessageIDs..................................................79=20 2.22.2 getResponse....................................................80=20 2.22.3 isResponseReceived.............................................80=20 2.22.4 merge..........................................................81=20 2.23 public class LDAPModification....................................81=20 2.23.1 Constructors...................................................81=20 2.23.2 getAttribute...................................................82=20 2.23.3 getOp..........................................................82=20 2.23.4 Constants of LDAPModification..................................82=20 2.24 public class LDAPNameFormSchema..................................82=20 2.24.1 Constructors...................................................83=20 2.24.2 getObjectClass.................................................83=20 2.24.3 getOptionalNamingAttributes....................................84=20 2.24.4 getRequiredNamingAttributes....................................84=20 2.25 public class LDAPObjectClassSchema...............................84=20 2.25.1 Constructors...................................................84=20 2.25.2 getOptionalAttributes..........................................85=20 2.25.3 getRequiredAttributes..........................................85=20 2.25.4 getSuperiors...................................................85=20 2.25.5 getType........................................................85=20 2.25.6 Constants of LDAPObjectClassSchema.............................86=20 2.26 public class LDAPReferralException...............................86=20 2.26.1 Constructors...................................................86=20 2.26.2 getFailedReferral..............................................87=20 2.26.3 getReferrals...................................................87=20 2.26.4 setFailedReferral..............................................87=20 2.27 public interface LDAPReferralHandler.............................87=20 2.28 public class LDAPResponse........................................87=20 2.28.1 getErrorMessage................................................88=20 2.28.2 getMatchedDN...................................................88=20 2.28.3 getReferrals...................................................88=20 2.28.4 getResultCode..................................................88=20 2.29 public class LDAPResponseQueue...................................88=20 =20 Expires December 6, 2004 [Page 6]=20 JAVA LDAP API April 2004=20 =20 =20 2.29.1 getMessageIDs..................................................88=20 2.29.2 getResponse....................................................88=20 2.29.3 isResponseReceived.............................................88=20 2.29.4 merge..........................................................88=20 2.30 public class LDAPSchema..........................................88=20 2.30.1 Constructors...................................................88=20 2.30.2 getAttributeNames..............................................89=20 2.30.3 getAttributeSchema.............................................89=20 2.30.4 getAttributeSchemas............................................89=20 2.30.5 getDITContentRuleNames.........................................89=20 2.30.6 getDITContentRuleSchema........................................89=20 2.30.7 getDITContentRuleSchemas.......................................90=20 2.30.8 getDITStructureRuleNames.......................................90=20 2.30.9 getDITStructureRuleSchema......................................90=20 2.30.10 getDITStructureRuleSchemas....................................90=20 2.30.11 getMatchingRuleNames..........................................90=20 2.30.12 getMatchingRuleSchema.........................................90=20 2.30.13 getMatchingRuleSchemas........................................91=20 2.30.14 getMatchingRuleUseNames.......................................91=20 2.30.15 getMatchingRuleUseSchema......................................91=20 2.30.16 getMatchingRuleUseSchemas.....................................91=20 2.30.17 getNameFormNames..............................................91=20 2.30.18 getNameFormSchema.............................................91=20 2.30.19 getNameFormSchemas............................................92=20 2.30.20 getObjectClassNames...........................................92=20 2.30.21 getObjectClassSchema..........................................92=20 2.30.22 getObjectClassSchemas.........................................92=20 2.30.23 getSyntaxSchema...............................................92=20 2.30.24 getSyntaxSchemas..............................................93=20 2.31 public abstract class LDAPSchemaElement..........................93=20 2.31.1 getDescription.................................................93=20 2.31.2 getNames.......................................................93=20 2.31.3 getID..........................................................93=20 2.31.4 getQualifier...................................................93=20 2.31.5 getQualifierNames..............................................94=20 2.31.6 isObsolete.....................................................94=20 2.31.7 setQualifier...................................................94=20 2.31.8 toString.......................................................94=20 2.32 public class LDAPSearchConstraints...............................94=20 2.32.1 Constructors...................................................95=20 2.32.2 getBatchSize...................................................96=20 2.32.3 getDereference.................................................96=20 2.32.4 getMaxResults..................................................96=20 2.32.5 getServerTimeLimit.............................................97=20 2.32.6 setBatchSize...................................................97=20 2.32.7 setDereference.................................................97=20 2.32.8 setMaxResults..................................................97=20 2.32.9 setServerTimeLimit.............................................98=20 2.32.10 Constants of LDAPSearchConstraints............................98=20 2.33 public class LDAPSearchQueue.....................................98=20 2.33.1 getMessageIDs..................................................98=20 2.33.2 getResponse....................................................98=20 =20 Expires December 6, 2004 [Page 7]=20 JAVA LDAP API April 2004=20 =20 =20 2.33.3 isComplete.....................................................98=20 2.33.4 isResponseReceived.............................................98=20 2.33.5 merge..........................................................98=20 2.34 public class LDAPSearchResult....................................98=20 2.34.1 getEntry.......................................................98=20 2.35 public class LDAPSearchResultReference...........................98=20 2.35.1 getReferrals...................................................98=20 2.36 public class LDAPSearchResults...................................99=20 2.36.1 getCount.......................................................99=20 2.36.2 getResponseControls............................................99=20 2.36.3 hasMore........................................................99=20 2.36.4 next...........................................................99=20 2.37 public interface LDAPSocketFactory...............................99=20 2.37.1 createSocket...................................................99=20 2.38 public class LDAPSyntaxSchema....................................99=20 2.38.1 Constructors..................................................100=20 2.39 public interface LDAPTLSSocketFactory...........................100=20 2.39.1 createSocket..................................................100=20 2.40 public interface LDAPUnsolicitedNotificationListener............100=20 2.40.1 messageReceived...............................................100=20 2.41 public class LDAPUrl............................................101=20 2.41.1 Constructors..................................................101=20 2.41.2 decode........................................................102=20 2.41.3 encode........................................................102=20 2.41.4 getAttributeArray.............................................102=20 2.41.5 getAttributes.................................................103=20 2.41.6 getDN.........................................................103=20 2.41.7 getExtensions.................................................103=20 2.41.8 getFilter.....................................................103=20 2.41.9 getHost.......................................................103=20 2.41.10 getPort......................................................103=20 2.41.11 getScope.....................................................103=20 2.41.12 toString.....................................................104=20 3. Implementation considerations.....................................104=20 3.1 Controls.........................................................104=20 3.2 Referral handling and exceptions.................................104=20 3.3 Message IDs......................................................106=20 3.4 Notice of disconnection..........................................106=20 3.5 Level of compatibility...........................................107=20 3.6 Dependencies.....................................................107=20 3.7 Invalid responses................................................107=20 4. Security considerations...........................................108=20 5. Acknowledgements..................................................109=20 6. Bibliography......................................................109=20 6.1 Normative References.............................................109=20 6.2 Informative References...........................................110=20 7. Authors' addresses................................................110=20 8. Appendix A - Sample Java LDAP programs............................112=20 8.1 Java LDAP programs using synchronous methods.....................112=20 8.2 Java LDAP programs using asynchronous methods....................118=20 9. Appendix B - Revision history.....................................124=20 9.1 Changes from ldap-java-api-17.txt................................126=20 =20 Expires December 6, 2004 [Page 8]=20 JAVA LDAP API April 2004=20 =20 =20 9.2 Changes from ldap-java-api-16.txt................................128=20 9.3 Changes from ldap-java-api-15.txt................................128=20 9.4 Changes from ldap-java-api-14.txt................................132=20 9.5 Changes from ldap-java-api-13.txt................................133=20 9.6 Changes from ldap-java-api-12.txt................................134=20 9.7 Changes from ldap-java-api-11.txt................................136=20 9.8 Changes from ldap-java-api-10.txt................................138=20 9.9 Changes from ldap-java-api-09.txt................................139=20 9.10 Changes from ldap-java-api-08.txt...............................140=20 9.11 Changes from ldap-java-api-07.txt...............................140=20 9.12 Changes from ldap-java-api-06.txt...............................141=20 9.13 Changes from ldap-java-api-05.txt...............................142=20 9.14 Changes from ldap-java-api-04.txt...............................142=20 9.15 Changes from ldap-java-api-03.txt...............................143=20 9.16 Changes from ldap-java-api-02.txt...............................144=20 9.17 Changes from ldap-java-api-01.txt...............................144=20 =20 =20 Expires December 6, 2004 [Page 9]=20 JAVA LDAP API April 2004=20 =20 =20 =20 1. Overview=20 =20 The LDAP [LDAPv3] class library is designed to provide powerful, yet=20 simple, access to LDAP directory services. It defines both=20 asynchronous and synchronous APIs to LDAP that suit a wide variety of=20 client applications and is capable of generating all possible=20 protocol requests and interpreting all possible protocol responses as=20 defined by LDAP v3 [LDAPPROTO]. This API does not attempt to provide=20 compatibility with earlier versions of LDAP.=20 =20 This document gives a brief overview of the LDAP model, then an=20 overview of the constituents of the class library. The public class=20 methods are described in detail, followed by an appendix that=20 provides some example code demonstrating the use of the=20 classes, and an appendix listing changes from earlier drafts.=20 =20 =20 1.1 The LDAP model=20 =20 LDAP is the Lightweight Directory Access Protocol, described in=20 [LDAPv3]. It defines a lightweight access mechanism by which client=20 applications send requests to and receive responses from LDAP=20 servers.=20 =20 The LDAP information model comes from X.500 [X500] and is based on=20 the entry, which contains information about some object (e.g., a=20 person). Entries are composed of attributes, which have a type and=20 one or more values. Each attribute has a syntax that determines what=20 kinds of values are allowed in the attribute (e.g., ASCII characters,=20 a jpeg photograph, etc.) and how directory operations act upon these=20 values.=20 =20 Entries may be organized in a tree structure, usually based on=20 political, geographical, and organizational boundaries. Other=20 structures are possible, including a flat namespace. Each entry is=20 uniquely named relative to its sibling entries by its relative=20 distinguished name (RDN) consisting of one or more distinguished=20 attribute values from the entry. At most one value from each=20 attribute may be used in the RDN. For example, the entry for the=20 person Babs Jensen might be named with the "Barbara Jensen" value=20 from the cn attribute.=20 =20 A globally unique name for an entry, called a distinguished name or=20 DN, is constructed by concatenating the sequence of RDNs from the=20 entry up to the root of the tree. For example, if Babs worked for the=20 Example company, the DN of her entry might be "cn=3DBarbara=20 Jensen,dc=3Dexample,dc=3Dcom". The DN format used by LDAP is defined i= n=20 [DN].=20 =20 Objects in LDAP are identified by an Object Identifier in dot-decimal=20 format. Short names are often used as more readable aliases for=20 =20 Expires December 6, 2004 [Page 10]=20 JAVA LDAP API April 2004=20 =20 =20 Object Identifiers. Object Identifiers in dot-decimal format will be=20 referred to as an OID or as OIDs throughout this document.=20 =20 Operations are provided to authenticate, search for and retrieve=20 information, modify information, and add and delete entries from the=20 tree. The protocol is also extensible, allowing operations to be=20 extended by "controls" and new "extended" operations to be defined.=20 =20 An LDAP server may return referrals or search references if it cannot=20 completely service a request (for example if the request specifies a=20 directory base outside of the tree managed by the server, the server=20 may return a referral. If a search request spans multiple servers, it=20 may return one or more search references).=20 =20 1.2 Limitations=20 Before the API implementation encodes and sends a string value to a=20 server, the string values are converted from the Java 16-bit Unicode=20 format (UCS2) to UTF-8 format, which many LDAPv3 protocol elements=20 and valueencodings use. The integrity of double-byte and other non- ASCII character sets is fully preserved. Any characters to be sent or=20 received, which cannot be represented with Java 16-bit Unicode=20 strings must be processed as binary values by the client application.=20 Values received from a server which cannot be represented as UCS-2=20 characters must be handled as binary values, since they will produce=20 undefined results if converted to a Java String. =20 =20 The next sections give an overview of how the class library is used and=20 detailed descriptions of the LDAP class methods that implement all of=20 these functions.=20 =20 1.3 Package name=20 =20 The classes of the LDAP class library have the package name=20 org.ietf.ldap.=20 =20 1.4 The LDAP classes=20 =20 The central LDAP class is LDAPConnection. It provides methods to=20 establish an authenticated or anonymous connection to an LDAP server,=20 as well as methods to search for, modify, compare, delete entries in=20 the directory, and establish integrity and confidentiality protective=20 services.=20 =20 The LDAPConnection class also provides access to settings that are=20 specific to the LDAP session (such as limits on the number of results=20 returned or timeout limits). An LDAPConnection object can be cloned,=20 allowing objects to share a single network connection but use=20 different settings (using LDAPConstraints or LDAPSearchConstraints).=20 =20 A synchronous search conducted by an LDAPConnection object returns=20 results in an LDAPSearchResults object, which can be enumerated to=20 access the entries found. Each entry (represented by an LDAPEntry=20 =20 Expires December 6, 2004 [Page 11]=20 JAVA LDAP API April 2004=20 =20 =20 object) provides access to the attributes (represented by=20 LDAPAttribute objects) returned for that entry. Each attribute can=20 produce the values found as byte arrays or as Strings.=20 =20 =20 1.5 The LDAP asynchronous methods=20 =20 The LDAP protocol provides synchronous as well as asynchronous=20 directory access methods. All asynchronous methods are conducted by=20 an LDAPConnection object, take an LDAPMessageQueue object as input,=20 and return an LDAPMessageQueue object . The returned LDAPMessageQueue=20 object is a message queue associated with the request, and it is the=20 responsibility of the client application to read messages out of the=20 queue and process them.=20 =20 Messages retrieved from an LDAPMessageQueue are objects of type=20 LDAPResponse, LDAPSearchResult, or LDAPSearchResultReference. .=20 =20 An asynchronous search returns an LDAPMessageQueue object. Search=20 results are obtained from that object via the getResponse method. A=20 search result is typically an LDAPSearchResult object, which has a=20 getEntry method. The LDAPEntry returned by getEntry contains the DN=20 and attributes of a single search result.=20 =20 None of the ancillary asynchronous classes are intended to be=20 instantiated by a client application, so they lack public=20 constructors.=20 =20 =20 1.6 Interfaces=20 =20 =20 LDAPAuthHandler Interface used to provide credentials for simple bind=20 when following a referral. =20 LDAPBindHandler Interface used to do explicit bind processing=20 when following a referral. =20 =20 =20 =20 LDAPReferralHandler Interface that is a shared ancestor to=20 LDAPBindHandler and LDAPAuthHandler. =20 =20 =20 =20 LDAPUnsolicitedNotificationListener Interface that allows a client=20 application to be notified when=20 unsolicited messages arrive from a=20 server.=20 =20 =20 1.7 Classes=20 =20 =20 Expires December 6, 2004 [Page 12]=20 JAVA LDAP API April 2004=20 =20 =20 =20 LDAPAttribute Represents the name and values of one=20 attribute of a directory entry.=20 =20 =20 LDAPAttributeSchema Represents a definition of an attribute=20 in a Directory Server=92s subschema.=20 =20 =20 LDAPAttributeSet Represents a collection of=20 LDAPAttributes.=20 =20 =20 LDAPAuthProvider An encapsulation of reauthentication=20 credentials, used when automatically=20 following referrals.=20 =20 =20 LDAPCompareAttrNames An implementation of Comparator to=20 support sorting of search results by one=20 or more attributes.=20 =20 =20 LDAPConnection The central point for operations on an=20 LDAP Directory Server.=20 =20 =20 LDAPConstraints Defines options controlling all =20 operations on a Directory Server.=20 =20 =20 LDAPControl Encapsulates additional parameters for an=20 LDAP operation, sent to or received from=20 a server.=20 =20 =20 LDAPDITContentRuleSchema Represents a DIT content rule in a=20 Directory Server=92s subschema.=20 =20 =20 LDAPDITStructureRuleSchema Represents a DIT structure rule in a=20 Directory Server=92s subschema.=20 =20 =20 LDAPDN A utility class to facilitate composition=20 and decomposition of distinguished names=20 (DNs).=20 =20 =20 LDAPEntry Represents a single entry in a directory.=20 =20 =20 =20 Expires December 6, 2004 [Page 13]=20 JAVA LDAP API April 2004=20 =20 =20 LDAPExtendedOperation Encapsulates the OID and data associated=20 with the sending or receiving of an=20 extended operation.=20 =20 =20 LDAPExtendedResponse The response returned by an LDAP server=20 on an extended operation request. It=20 extends LDAPResponse.=20 =20 LDAPMatchingRuleSchema Represents the schematic definition of a=20 matching rule in a Directory Server=92s=20 subschema.=20 =20 =20 LDAPMatchingRuleUseSchema Represents a matching rule use in a=20 Directory Server=92s subschema.=20 =20 =20 LDAPMessage Base class for LDAP request and response=20 messages. Subclassed by response messages=20 used in asynchronous operations.=20 =20 LDAPMessageQueue Represents a queue of incoming=20 asynchronous messages from the server.=20 =20 =20 LDAPModification A single add/delete/replace operation to=20 an LDAPAttribute.=20 =20 =20 LDAPNameFormSchema Represents a name form in a Directory=20 Server=92s subschema.=20 =20 =20 LDAPObjectClassSchema Represents the schematic definition of an=20 object class in a Directory Server=92s=20 subschema.=20 =20 =20 LDAPResponse Represents a message received from an=20 LDAP server in response to an=20 asynchronous request. It extends=20 LDAPMessage.=20 =20 =20 LDAPSchema Represents the subschema controlling one=20 or more entries held by a Directory=20 Server.=20 =20 =20 LDAPSchemaElement Base class for representing LDAP=20 subschema elements.=20 =20 Expires December 6, 2004 [Page 14]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 LDAPSyntaxSchema Represents a syntax definition in a=20 Directory Server=92s subschema.=20 =20 =20 LDAPSearchConstraints Defines the options controlling search=20 operations.=20 =20 =20 LDAPSearchResult A single search result that is in=20 response to an asynchronous search=20 operation. It extends LDAPMessage.=20 =20 =20 LDAPSearchResultReference A continuation reference from an=20 asynchronous search operation. It extends=20 LDAPMessage.=20 =20 =20 LDAPSearchResults The enumerable results of a search=20 operation.=20 =20 =20 LDAPUrl Represents an LDAP Url [LDAPURL].=20 =20 =20 1.8 Exceptions=20 =20 =20 LDAPException General exception, which includes an error=20 message and an LDAP API local error code or=20 server result code.=20 =20 =20 LDAPLocalException Derived from LDAPException and is an exception=20 generated by the API implementation, i.e., an=20 exception not received from the server.=20 =20 =20 LDAPReferralException Derived from LDAPException and contains a list=20 of URLs corresponding to a single referral or=20 search continuation response received on an=20 LDAP operation.=20 =20 =20 1.9 LDAP API use=20 =20 An application generally uses the LDAP API in four steps.=20 =20 - Construct an LDAPConnection. Initialize an LDAP session with a=20 =20 Expires December 6, 2004 [Page 15]=20 JAVA LDAP API April 2004=20 =20 =20 Directory Server. Supplying an optional SocketFactory during=20 connection creation may enable an SSL or TLS session. The=20 LDAPConnection.connect() call establishes a handle to the=20 session, allowing multiple sessions to be open at once, on=20 different instances of LDAPConnection.=20 =20 - Optionally authenticate to the LDAP server with=20 LDAPConnection.bind().=20 =20 - Perform some LDAP operations and obtain some results.=20 The synchronous version of LDAPConnection.search() returns an=20 LDAPSearchResults object which can be enumerated to access all=20 entries found. The asynchronous version of=20 LDAPConnection.search() returns anLDAPMessageQueue, which is=20 used to read the results of the search. LDAPConnection.read()=20 returns a single entry. Other methods allow other operations=20 such as add, delete, and modify to be performed.=20 =20 - Close the connection. The LDAPConnection.disconnect() callcloses=20 the connection.=20 =20 There are both synchronous and asynchronous versions of the LDAP=20 protocol operations described in this specification. Synchronous=20 methods do not return until the operation has completed.=20 =20 Asynchronous methods take an LDAPMessageQueue parameter and return an=20 LDAPMessageQueue object which is used to enumerate the responses from=20 the server. A loop is typically used to read from the queue object,=20 which blocks until there is a response available, until the operation=20 has completed.=20 =20 An LDAPMessageQueue may be shared between operations for multiplexing=20 the results. In this case, the object returned on one operation is=20 passed in to one or more other operations, rather than passing in=20 null.=20 =20 For the asynchronous methods, exceptions are raised only for=20 connection errors and API errors (LDAPLocalException). LDAP result=20 messages are converted into LDAPResponse objects which are to be=20 checked by the client application for errors and referrals, whereas=20 the synchronous methods throw an LDAPException on result codes other=20 than success(0), compareTrue(5), and compareFalse(6).=20 =20 To facilitate user feedback during synchronous searches, intermediate=20 search results can be obtained before the entire search operation is=20 completed by specifying, in an LDAPSearchConstraints object, the=20 number of entries to return at a time.=20 =20 Errors result in the throwing of an LDAPException, with a specific=20 result code and context-specific textual information, if available.=20 =20 =20 Expires December 6, 2004 [Page 16]=20 JAVA LDAP API April 2004=20 =20 =20 Methods implemented by the API that return an array MUST return an=20 empty array if no values are present to return, unless otherwise=20 specified.=20 =20 If null is passed as the value of an LDAPConstraints or=20 LDAPSearchConstraints parameter to an operation, the default=20 constraints are used for that operation.=20 =20 If null is passed as the value of a DN to an operation it is treated=20 as if it was the empty string.=20 =20 =20 When using synchronous APIs, the client application doesn't=20 distinguish between LDAP search continuation references and LDAP=20 referrals, as the API presents a unified interface for handling the=20 two. This document generically refers to continuation references and=20 referrals as simply referrals or referral following. The API gives=20 the application two options for handling referrals.=20 =20 =20 =20 1.9.1 Default Referral Handling=20 =20 By default, referrals are not followed automatically. The application=20 receives a referral and either ignores it or explicitly issues a new=20 request to the referred-to servers.=20 =20 1.9.2 Automatic Referral Following=20 =20 The application, if using synchronous requests, can choose to let the=20 library automatically follow the referrals. When automatic referral=20 following is selected, a referral is followed by default with=20 anonymous credentials using the protocol version, socket factory, and=20 TLS [TLS][LDAPTLS] of the original connection. Socket factories=20 supplied by the client application can determine if and when TLS=20 client credentials are to be disclosed. =20 =20 If default referral following is not desired when automatically=20 following referrals, the application can instruct the library to=20 follow referrals with an authenticated connection by providing a=20 reauthentication object to supply credentials for a simple bind. =20 =20 For greater flexibility, the client application can provide an object=20 that creates, binds, and manages authenticated connections for use by=20 the API implementation when automatically following referrals.=20 =20 =20 2. The Java LDAP classes=20 =20 The following sections describe the LDAP classes in more detail.=20 =20 =20 =20 Expires December 6, 2004 [Page 17]=20 JAVA LDAP API April 2004=20 =20 =20 2.1 public class LDAPAttribute=20 implements Cloneable, Serializable, Comparable=20 =20 The LDAPAttribute class represents the name and values of an=20 attribute. It is used to specify an attribute to be added to, deleted=20 from, or modified in a Directory entry. It is also returned on a=20 search of a Directory.=20 =20 It should be noted that attribute name (called Attribute Description=20 in the LDAP Protocol [LDAPPROTO]) consists of an Attribute Type and=20 Attribute Options. Attribute Type can be expressed as an OID or as=20 one of its short names. The API implementation is not required to=20 make a mapping of short names and the OID. The Attribute Type MAY be=20 followed by one or more options. The implementation MUST treat the=20 name and options as case insensitive and return name and options as=20 lower case strings. No ordering can be implied on the options.=20 =20 =20 2.1.1 Constructors=20 =20 public LDAPAttribute(LDAPAttribute attr)=20 =20 =20 Constructs an attribute with copies of all values of the input=20 attribute.=20 =20 public LDAPAttribute(String attrName)=20 =20 =20 Constructs an attribute with no values.=20 =20 =20 public LDAPAttribute(String attrName,=20 byte[] attrBytes)=20 =20 Constructs an attribute with a byte-formatted value.=20 =20 =20 public LDAPAttribute(String attrName,=20 String attrString)=20 =20 Constructs an attribute that has a single string value.=20 =20 =20 public LDAPAttribute(String attrName,=20 String[] attrStrings)=20 =20 Constructs an attribute that has an array of string values.=20 =20 Parameters are:=20 =20 attr An attribute to use as template.=20 =20 Expires December 6, 2004 [Page 18]=20 JAVA LDAP API April 2004=20 =20 =20 =20 attrName Name of the attribute.=20 =20 attrBytes Value of the attribute as raw bytes.=20 =20 attrString Value of the attribute as a String.=20 =20 attrStrings Array of values as Strings.=20 =20 IllegalArgumentException is thrown if any of the attribute values is=20 null.=20 =20 =20 2.1.2 addValue=20 =20 public void addValue(String attrString)=20 =20 Adds a string value to the attribute.=20 =20 =20 public void addValue(byte[] attrBytes)=20 =20 Adds a byte[]-formatted value to the attribute.=20 =20 Parameters are:=20 =20 attrString Value of the attribute as a String.=20 =20 attrBytes Value of the attribute as raw bytes.=20 =20 Adding a value which is already present has no effect.=20 =20 =20 2.1.3 compareTo=20 =20 public int compareTo(Object obj)=20 =20 Compares this object with the specified object for order. Ordering is=20 determined by comparing normalized attribute names and options (see=20 getName()) using the compareTo() method of the String class. Returns=20 a negative integer, zero, or a positive integer as this object is=20 less than, equal to, or greater than the specified object.=20 =20 Parameters are:=20 =20 obj The object to be compared to this object.=20 =20 =20 2.1.4 getTypeName=20 =20 public String getTypeName()=20 =20 =20 Expires December 6, 2004 [Page 19]=20 JAVA LDAP API April 2004=20 =20 =20 public static String getTypeName(String attrName)=20 =20 Returns the type name of the attribute. For example, if the attribute=20 name is cn;lang-ja;phonetic, this method returns cn. The name may be=20 an OID.=20 =20 attrName Name of the attribute to extract the type name=20 from.=20 =20 =20 2.1.5 getByteValues=20 =20 public Enumeration getByteValues()=20 =20 Returns an enumerator for the values of the attribute in byte[]=20 format.=20 =20 =20 2.1.6 getByteValueArray=20 =20 public byte[][] getByteValueArray()=20 =20 Returns the values of the attribute as an array of byte[].=20 =20 =20 2.1.7 getName=20 =20 public String getName()=20 =20 Returns the normalized name of the attribute, i.e. the attribute=20 type, and its options, if any.=20 =20 =20 2.1.8 getStringValueArray=20 =20 public String[] getStringValueArray()=20 =20 Returns the values of the attribute as an array of Strings. This=20 method should only be called if the attribute values are known to be=20 strings. The returned Strings have undefined values if the attribute=20 values do not consist of valid UTF-8 character encodings.=20 =20 =20 2.1.9 getStringValues=20 =20 public Enumeration getStringValues()=20 =20 Returns an enumerator for the string values of an attribute. This=20 method should only be called if the attribute values are known to be=20 strings. The returned Stringvalues are undefined if the values do not=20 consist of valid UTF-8 character encodings.=20 =20 =20 Expires December 6, 2004 [Page 20]=20 JAVA LDAP API April 2004=20 =20 =20 =20 2.1.10 getOptions=20 =20 public String[] getOptions()=20 =20 public static String[] getOptions(String attrName)=20 =20 Extracts the options from the specified attribute name. For example,=20 if the attribute name is cn;lang-ja;phonetic, this method returns an=20 array containing lang-ja and phonetic. The options may be returned in=20 any order.=20 =20 Parameters are:=20 =20 attrName Name of the attribute to extract the options=20 from.=20 =20 =20 2.1.11 hasOption=20 =20 public boolean hasOption(String option)=20 =20 Reports if the attribute name contains the specified option. For=20 example, if you check for the option lang-en and the attribute name=20 is cn;lang-en;phonetic, this method returns true.=20 =20 Parameters are:=20 =20 option The single option to check for.=20 =20 =20 2.1.12 hasOptions=20 =20 public boolean hasOptions(String[] options)=20 =20 Reports if the attribute name contains at least the specified=20 options. For example, if you check for the options lang-en and=20 phonetic and if the attribute name is cn;lang-en;phonetic, this=20 method returns true. If the attribute name is cn;phonetic or cn;lang- en, this method returns false. The options may be specified in any=20 order.=20 =20 Parameters are:=20 =20 options An array of subtypes to check for.=20 =20 =20 2.1.13 removeValue=20 =20 public void removeValue(String attrString)=20 =20 Removes a string value from the attribute.=20 =20 Expires December 6, 2004 [Page 21]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 public void removeValue(byte[] attrBytes)=20 =20 Removes a byte[]-formatted value from the attribute. The value to be=20 removed must match, byte for byte, the specified value.=20 =20 Parameters are:=20 =20 attrString Value of the attribute as a String.=20 =20 attrBytes Value of the attribute as raw bytes.=20 =20 Removing a value which is not present in the attribute has no effect.=20 =20 =20 2.1.14 size=20 =20 public int size()=20 =20 Returns the number of values of the attribute.=20 =20 =20 2.2 public class LDAPAttributeSchema=20 extends LDAPSchemaElement=20 =20 The LDAPAttributeSchema class represents the definition of an=20 attribute. It is used to query attribute syntax, and to add or delete=20 an attribute definition in a Directory=92s subschema. See [ATTR] for a= =20 description of attribute representation in LDAP.=20 =20 =20 2.2.1 Constructors=20 =20 public LDAPAttributeSchema(String[] names,=20 String oid,=20 String description,=20 String syntaxString,=20 boolean single,=20 String superior,=20 boolean obsolete,=20 String equality,=20 String ordering,=20 String substring,=20 boolean collective,=20 boolean userMod,=20 int usage)=20 =20 Constructs an attribute definition for adding to or deleting from a=20 Directory=92s subschema.=20 =20 public LDAPAttributeSchema(String raw)=20 =20 Expires December 6, 2004 [Page 22]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Constructs an attribute definition from an encoding using the=20 AttributeTypeDescription syntax [ATTR].=20 =20 Parameters are:=20 =20 names Name(s) of the attribute.=20 =20 oid OID of the attribute.=20 =20 description Optional description of the attribute.=20 =20 syntaxString OID of the syntax of the attribute.=20 =20 single true if the attribute is to be single-valued.=20 =20 superior Optional name of the attribute type which this=20 attribute type derives from; null if there is no=20 superior attribute type.=20 =20 obsolete true if this attribute is obsolete.=20 =20 equality OID of the equality matching rule for the=20 attribute ; or null if none.=20 =20 ordering OID of the ordering matching rule for the, or=20 null if none.=20 =20 substring OID of the substring matching rule for the=20 attribute, or null if none.=20 =20 collective true if this is a collective attribute.=20 =20 userMod true if the attribute is modifiable by users.=20 =20 usage One of the following constants (see 2.2.11):=20 =20 USER_APPLICATIONS=20 DIRECTORY_OPERATION=20 DISTRIBUTED_OPERATION=20 DSA_OPERATION=20 =20 raw An attribute definition encoded using the=20 AttributeTypeDescription syntax [ATTR].=20 =20 =20 =20 2.2.2 getEqualityMatchingRule=20 =20 public String getEqualityMatchingRule ()=20 =20 =20 Expires December 6, 2004 [Page 23]=20 JAVA LDAP API April 2004=20 =20 =20 Returns the OID of the equality matching rule in effect for this=20 attribute, or null if there is none.=20 =20 =20 2.2.3 getOrderingMatchingRule=20 =20 public String getOrderingMatchingRule ()=20 =20 Returns the OID of the ordering matching rule in effect for this=20 attribute, or null if there is none.=20 =20 =20 2.2.4 getSubstringMatchingRule=20 =20 public String getSubstringMatchingRule ()=20 =20 Returns the OID of the substring matching rule in effect for this=20 attribute, or null if there is none.=20 =20 =20 2.2.5 getSuperior=20 =20 public String getSuperior()=20 =20 Returns the name of the attribute type which this attribute derives=20 from, or null if there is no superior attribute.=20 =20 =20 2.2.6 getSyntaxString=20 =20 public String getSyntaxString()=20 =20 Returns the OID of the syntax of the attribute.=20 =20 =20 2.2.7 getUsage=20 =20 public int getUsage ()=20 =20 Returns one of the following constants (see 2.2.11):=20 =20 USER_APPLICATIONS=20 DIRECTORY_OPERATION=20 DISTRIBUTED_OPERATION=20 DSA_OPERATION=20 =20 =20 2.2.8 isCollective=20 =20 public boolean isCollective ()=20 =20 Returns true if the attribute is collective.=20 =20 Expires December 6, 2004 [Page 24]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 2.2.9 isSingleValued=20 =20 public boolean isSingleValued()=20 =20 Returns true if the attribute is single-valued.=20 =20 =20 2.2.10 isUserModifiable=20 =20 public boolean isUserModifiable ()=20 =20 Returns true if the attribute is modifiable by users.=20 =20 =20 2.2.11 Constants of LDAPAttributeSchema=20 =20 The constants correspond to those defined in RFC 2252 [ATTR]:=20 userApplications, directoryOperation, distributedOperation, and=20 dSAOperation. The table below gives the constant name followed by=20 its value.=20 =20 USER_APPLICATIONS (0) An ordinary user attribute=20 =20 DIRECTORY_OPERATION (1) An operational attribute used for a=20 directory operation or which holds a=20 directory specific value=20 =20 DISTRIBUTED_OPERATION (2) An operational attribute used to hold=20 server (DSA) information that is shared=20 among servers holding replicas of the=20 entry=20 =20 DSA_OPERATION (3) An operational attribute used to hold=20 server (DSA) information that is local=20 to a server=20 =20 =20 2.3 public class LDAPAttributeSet=20 implements Cloneable, Serializable, Set=20 =20 An LDAPAttributeSet is a collection of LDAPAttributes, as returned in=20 an entry on a search or read operation, or is used to construct an=20 entry to be added to a directory. If add() or addAll() is called and=20 one or more of the objects to be added is not an LDAPAttribute,=20 ClassCastException is thrown (as discussed in the documentation for=20 java.util.Collection). To remove an attribute, remove() is called=20 with the LDAPAttribute object to remove.=20 =20 =20 =20 Expires December 6, 2004 [Page 25]=20 JAVA LDAP API April 2004=20 =20 =20 2.3.1 Constructors=20 =20 public LDAPAttributeSet()=20 =20 Constructs a new set of attributes. This set is initially empty.=20 =20 =20 2.3.2 clone=20 =20 public Object clone()=20 =20 Returns a deep copy of this attribute set.=20 =20 =20 2.3.3 getAttribute=20 =20 =20 public LDAPAttribute getAttribute(String attrDesc)=20 =20 Returns the attribute matching the specified attribute description. =20 The returned attribute has just the options specified for the given=20 attribute type or null if none. Note: no order is implied with=20 attribute options.Parameters are:=20 =20 attrDesc Description of the attribute. The description=20 consists of the attribute type and any attribute=20 options. Note: the attribute description is case=20 insensitive and the options are not ordered. The=20 options specify the exact set of attribute=20 options that must be present when selecting the=20 attribute.=20 =20 For example,=20 =20 getAttribute("cn") returns only the "cn" attribute=20 that has no options.=20 getAttribute("cn;lang-en") returns only the "cn;lang-en"=20 attribute.=20 getAttribute(=93cn;lang-en;lang-en-us=94)=20 returns the =93cn=94 attribute with the =93lang-en-us=94 option a= nd the=20 =93langen=94 option. Note: the optio= ns=20 can be in any=20 order.getAttribute("cn", null)=20 returns all the "cn" attributes,=20 without regard to options.=20 getAttribute("cn", new String[] {=93lang-en=94})=20 returns any "cn" attributes that=20 have the lang-en attribute.=20 2.3.4 getSubset=20 =20 public LDAPAttributeSet getSubset(String options)=20 =20 =20 Expires December 6, 2004 [Page 26]=20 JAVA LDAP API April 2004=20 =20 =20 Returns a new attribute set containing only the attributes that have=20 at least the specified options. If no attributes have the specified=20 options, an empty LDAPAttributeSet is returned.=20 =20 Public LDAPAttributeSet getSubset(String attrType, String options)=20 =20 Returns a new attribute set containing only the attributes that have=20 the specified attribute type and at least the specified options. If=20 no attributes have the specified type and options, an empty=20 LDAPAttributeSet is returned.=20 =20 =20 For example, suppose an attribute set contains the following=20 attributes: =20 =20 cn=20 cn;lang-ja=20 cn;lang-ja;phoentic sn;lang-ja;phonetic=20 sn;lang-us=20 =20 =20 Calling the getSubset method and passing lang-ja as the argument, the=20 method returns an attribute set containing the following attributes: =20 =20 cn;lang-ja=20 sn;lang-ja;phonetic=20 =20 Calling the getSubset method and passing type cn and lang-ja as the=20 argument returns an attribute set containing the following=20 attributes:=20 =20 cn;lang-ja=20 cn;lang-ja;phoentic=20 =20 =20 Parameters are:=20 =20 attrType =96 the attribute type of the attributes to include in the= =20 attribute set. Any options specified with this=20 parameter are ignored. If null, all attributes=20 matching the specified options are returned in=20 the subset.=20 =20 options - Semi-colon delimited list of subtypes to include. The=20 options can be specified in any order. If null,=20 all attributes of the specified type are=20 returned. For example:=20 =20 "lang-ja" // The lang-ja option=20 "binary;lang-ja" // The binary and the lang-ja=20 // options=20 =20 =20 Expires December 6, 2004 [Page 27]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 2.4 public interface LDAPAuthHandler=20 extends LDAPReferralHandler=20 =20 =20 Used by the API only if automatic referral handling is enabled in=20 LDAPConstraints. The API ignores instances of this class if referral=20 following is disabled (the default referral following behavior).=20 =20 2.4.1 LDAPAuthHandler is used by the API to obtain credentials for=20 reauthentication (simple bind) when automatically following a referral.=20 If set in an LDAPContraints instance, an application=92s implementation o= f=20 LDAPAuthHandler is called during referral processing and returns an=20 LDAPAuthProvider. An application may specify an instance of an=20 LDAPConstraints class to be used on a single operation (as a method=20 parameter) or for all operations (as connection=20 constraints).getAuthProvider=20 =20 public LDAPAuthProvider getAuthProvider(String host, int port)=20 =20 =20 Returns an object which can provide credentials to simple bind for=20 authenticating to a server at the provided host name and port number.=20 =20 Parameters are:=20 =20 host Contains a host identifier representing the IP=20 address of a host running an LDAP server. See=20 2.8.9 for a discussion of valid identifiers.=20 =20 port Contains the TCP port number to connect to.=20 =20 =20 2.5 public class LDAPAuthProvider=20 =20 2.5.1 Represents information the API uses to authenticate the=20 application in cases where the the application has set an=20 LDAPAuthHandler in LDAPContraints to facilitate automatic referral=20 following. Constructors=20 =20 public LDAPAuthProvider( String dn,=20 byte[] password )=20 =20 Constructs information that is used by the application for simple=20 bind authentication=20 when following referrals automatically.=20 =20 =20 Parameters are:=20 =20 =20 Expires December 6, 2004 [Page 28]=20 JAVA LDAP API April 2004=20 =20 =20 dn Distinguished name to use in authenticating to=20 the server.=20 =20 password The UTF-8 or binary representation of the=20 password to use in authenticating to the server,=20 represented as a byte array.=20 =20 =20 2.5.2 getDN=20 =20 public String getDN()=20 =20 Returns the distinguished name to be used for reauthentication on=20 automatic referral following.=20 =20 =20 2.5.3 getPassword=20 =20 public byte[] getPassword()=20 =20 Returns the password to be used for reauthentication on automatic=20 referral following.=20 =20 =20 2.6 public interface LDAPBindHandler=20 extends LDAPReferralHandler=20 =20 Used by the API to perform bind operations during the processing of a=20 referral inorder to follow it. If set in an LDAPContraints instance,=20 an application=92s implementation of LDAPBindHandler is called during=20 referral processing and returns an authenticated connection to the=20 referred server. An application may set an instance of this class in=20 an LDAPConstraints object to be used on a single LDAP operation (as a=20 method parameter) or for all LDAP operations (through connection=20 constraints). An application implementating LDAPBindHandler can=20 perform any sequence of valid LDAP operations before returning to the=20 API, as long as as it returns a connection to the referred server. If=20 LDAPAuthHandler or LDAPBindHandler are not specified, referrals and=20 search references followed automatically use anonymous=20 authentication.=20 =20 =20 =20 2.6.1 bind=20 =20 =20 public LDAPConnection bind(String[] ldapurl, LDAPConnection conn)=20 throws LDAPReferralException=20 =20 This method is called by LDAPConnection when a referral or search=20 continuation is received, and is responsible for binding to one of=20 the hosts in the list specified by the ldapurl parameter (which=20 =20 Expires December 6, 2004 [Page 29]=20 JAVA LDAP API April 2004=20 =20 =20 corresponds exactly to the list of hosts returned in a single=20 referral or search continuation response). An implementation may=20 access the host, port, socket factoryand other information in the=20 original LDAPConnection object to decide on an appropriate=20 authentication mechanism, and/or may interact with a user or external=20 module. The object implementing LDAPBindHandler creates a new=20 LDAPConnection object to perform its connect and bind calls. It =20 returns the new connection when both the connect and bind operations=20 succeed on one host from the list. The LDAPConnection object referral=20 following code uses the new LDAPConnection object when it resends the=20 search request, updated with the new search base and possibly search=20 filter. An LDAPReferralException is thrown on failure.=20 =20 The API implementation dereferences the new LDAPConnection when=20 referral following has finished, but does not call disconnect. This=20 allows the application=92s implementation of LDAPBindHandler to do=20 connection pooling when managing connections for referral following.=20 =20 Parameters are:=20 =20 ldapurl List of LDAP server URLs. There is no order=20 implied by the list.=20 =20 conn An established connection to an LDAP server.=20 =20 =20 2.7 public class LDAPCompareAttrNames=20 implements Comparator=20 =20 An object of this class defines ordering when sorting search results.=20 When using this Comparator, LDAPEntry objects are sorted by the=20 values of the attribute name(s) passed in the constructor, in=20 ascending or descending order. The object is typically supplied to an=20 implementation of the collection interfaces such as java.util.TreeSet=20 which performs the sort.=20 =20 =20 2.7.1 Constructors=20 =20 public LDAPCompareAttrNames(String attrName)=20 =20 =20 Constructs an object that will sort results by a single attribute, in=20 ascending order.=20 =20 =20 public LDAPCompareAttrNames(String attrName,=20 boolean ascendingFlag)=20 =20 Constructs an object that will sort results by a single attribute, in=20 either ascending or descending order.=20 =20 =20 Expires December 6, 2004 [Page 30]=20 JAVA LDAP API April 2004=20 =20 =20 =20 public LDAPCompareAttrNames(String[] attrNames)=20 =20 Constructs an object that will sort by one or more attributes, in the=20 order provided, in ascending order.=20 =20 =20 public LDAPCompareAttrNames(String[] attrNames,=20 boolean[] ascendingFlags)=20 throws LDAPException=20 =20 Constructs an object that will sort by one or more attributes in the=20 order provided, in either ascending or descending order for each=20 attribute.=20 =20 Parameters are:=20 =20 attrName Name of an attribute to sort by.=20 =20 attrNames Array of names of attributes to sort by.=20 =20 ascendingFlag true to sort in ascending order, false for=20 descending order.=20 =20 ascendingFlags Array of flags, one for each value in attrNames,=20 where each one is true to sort in ascending=20 order, false for descending order. An=20 LDAPException is thrown if the length of=20 ascendingFlags is not equal to the length of=20 attrNames.=20 =20 =20 2.7.2 compare=20 =20 public int compare(Object o1, Object o2)=20 =20 Compares its two arguments for order. Returns a negative integer,=20 zero, or a positive integer as the first argument is less than, equal=20 to, or greater than the second. Throws ClassCastException if o1 or o2=20 is not an LDAPEntry.=20 =20 Parameters are:=20 =20 o1 Target entry for comparison.=20 =20 o2 Entry to be compared to.=20 =20 =20 2.7.3 equals=20 =20 public boolean equals(Object obj)=20 =20 =20 Expires December 6, 2004 [Page 31]=20 JAVA LDAP API April 2004=20 =20 =20 Returns a value of true only if the specified object is also a=20 comparator and it imposes the same ordering as this comparator. =20 =20 Parameters are:=20 =20 obj The reference object with which to compare.=20 =20 =20 2.7.4 getLocale=20 =20 public Locale getLocale()=20 =20 Returns the Locale to be used for sorting, if a Locale has been=20 specified. If null, a basic String.compareTo() is used for collation.=20 If non-null, a Locale-specific collation is used.=20 =20 =20 2.7.5 setLocale=20 =20 public void setLocale(Locale locale)=20 =20 Sets the Locale to be used for sorting.=20 =20 Parameters are:=20 =20 locale The Locale to be used for sorting.=20 =20 =20 2.8 public class LDAPConnection=20 implements Cloneable=20 =20 LDAPConnection is the central class that encapsulates the connection=20 to a Directory Server through the LDAP protocol. An LDAPConnection=20 object is not connected on construction, and may only be connected to=20 one server at one port. Multiple threads may share this single=20 connection, and an application may have more than one LDAPConnection=20 object, connected to the same or different Directory Servers.=20 Implementations of the API MUST ensure that methods of the=20 LDAPConnection class are thread-safe. =20 =20 =20 =20 2.8.1 Constructors=20 =20 public LDAPConnection()=20 =20 Constructs a new LDAPConnection object, which represents a connection=20 to an LDAP server.=20 =20 Calling the constructor does not actually establish the connection.=20 The connect or bind methods are used to connect to the LDAP server.=20 =20 =20 Expires December 6, 2004 [Page 32]=20 JAVA LDAP API April 2004=20 =20 =20 =20 public LDAPConnection(SocketFactory factory)=20 =20 Constructs a new LDAPConnection object, which will use the supplied=20 SocketFactory class to construct a socket connection during=20 LDAPConnection.connect(). If a security manager exists and the=20 caller does not have permission to set a factory, SecurityException=20 is thrown.=20 =20 =20 Parameters are:=20 =20 factory An object capable of producing a Socket.=20 =20 =20 2.8.2 abandon=20 =20 public void abandon(LDAPSearchResults results)=20 throws LDAPException=20 =20 public void abandon(LDAPSearchResults results, LDAPConstraints cons)=20 throws LDAPException=20 =20 public void abandon(int id)=20 throws LDAPException=20 =20 public void abandon(int id, LDAPConstraints cons)=20 throws LDAPException=20 =20 public void abandon(LDAPMessageQueue queue)=20 throws LDAPException=20 =20 public void abandon(LDAPMessageQueue queue, LDAPConstraints cons)=20 throws LDAPException=20 =20 Either notifies the server to not send additional results associated=20 with this LDAPSearchResults object, and discards any results already=20 received, or abandons one or all operations for an asynchronous=20 response queue.=20 =20 If the application calls this method for a particular id or=20 LDAPSearchResults previously abandoned, the call is ignored. An API=20 implementation MUST ignore abandon requests for an id or=20 LDAPSearchResults which it does not recognize. The API implementation=20 SHOULD NOT send an additional abandon request if it can determine=20 that one has already been sent for an id or LDAPSearchResults.=20 =20 Parameters are:=20 =20 results An object returned from a synchronous search.=20 =20 =20 Expires December 6, 2004 [Page 33]=20 JAVA LDAP API April 2004=20 =20 =20 id The ID of the asynchronous operation to abandon.=20 The ID may be obtained from the response queue=20 for the operation.=20 =20 queue Handler returned from an asynchronous request.=20 All outstanding operations that are managed by=20 the queue are abandoned.=20 =20 cons Constraints specific to the operation.=20 =20 =20 2.8.3 add=20 =20 public void add(LDAPEntry entry)=20 throws LDAPException=20 =20 public void add(LDAPEntry entry,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 public LDAPMessageQueue add(LDAPEntry entry,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 =20 public LDAPMessageQueue add(LDAPEntry entry,=20 LDAPMessageQueue queue,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 Adds an entry to the directory.=20 =20 If the application does not specify attribute values which are valid=20 according to the syntax defined for the attributes, or does not=20 include all attributes which are required for the entry, the server=20 will return an error.=20 =20 Parameters are:=20 =20 entry LDAPEntry object specifying the distinguished=20 name and attributes of the new entry.=20 =20 queue Handler for messages returned from a server in=20 response to this request. If it is null, a queue=20 object is created internally.=20 =20 cons Constraints specific to the operation.=20 =20 =20 2.8.4 addUnsolicitedNotificationListener=20 =20 public void addUnsolicitedNotificationListener(=20 =20 Expires December 6, 2004 [Page 34]=20 JAVA LDAP API April 2004=20 =20 =20 LDAPUnsolicitedNotificationListener listener)=20 =20 Registers an object to be notified on arrival of an unsolicited=20 message from a server.=20 =20 Parameters are:=20 =20 listener An object to be notified on arrival of an=20 unsolicited message from a server.=20 =20 =20 2.8.5 bind (simple)=20 =20 =20 public void bind(int version,=20 String dn,=20 byte[] passwd)=20 throws LDAPException=20 =20 public void bind(int version,=20 String dn,=20 byte[] passwd,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 public LDAPMessageQueue bind(int version,=20 String dn,=20 byte[] passwd,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 public LDAPMessageQueue bind(int version,=20 String dn,=20 byte[] passwd,=20 LDAPMessageQueue queue,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 =20 Synchronously authenticates using simple authentication to the LDAP=20 server (that the object is currently connected to) using the=20 specified name and password, with the specified LDAP protocol=20 version. This API is specifically designed for use with LDAPv3. =20 Unless the API provides specific support (as defined in other=20 documents) for other versions of LDAP, version 3 should be used. If=20 the server does not support the requested protocol version, an=20 exception is thrown. If the object had already authenticated, the=20 old authentication is discarded. If the object has been disconnected=20 from an LDAP server, this method attempts to reconnect and=20 authenticate to the server. =20 =20 Parameters are:=20 =20 Expires December 6, 2004 [Page 35]=20 JAVA LDAP API April 2004=20 =20 =20 =20 version LDAP protocol version requested: currently 3.=20 =20 dn If the dn and passwd are non-null and non-empty,=20 the connection and all operations through it are=20 authenticated with dn as the distinguished name=20 and passwd as password. If dn and/or passwd are=20 null or empty, the connection is anonymous on=20 completion of the simple bind request.=20 =20 passwd The UTF-8 or binary representation of the=20 password to use in authenticating to the server,=20 represented as a byte array. If both the passwd=20 and dn are non-null and non-empty, the connection=20 and all operations through it are authenticated=20 with dn as the distinguished name and passwd as=20 password. If dn and/or passwd is null or empty,=20 the connection is anonymous on completion of the=20 simple bind request.=20 =20 queue Handler for asynchronous messages returned from a=20 server in response to this request. Ifnull, a=20 queue object is created internally.=20 =20 cons Constraints specific to the operation.=20 =20 2.8.6 bind (SASL)=20 =20 public void bind(String dn,=20 String authzId,=20 Map props,=20 javax.security.auth.callback.CallbackHandler cbh)=20 throws LDAPException=20 =20 =20 public void bind(String dn,=20 String authzId,=20 Map props,=20 javax.security.auth.callback.CallbackHandler cbh,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 =20 public void bind(String dn,=20 String authzId,=20 String[] mechanisms,=20 Map props,=20 javax.security.auth.callback.CallbackHandler cbh)=20 throws LDAPException=20 =20 public void bind(String dn,=20 String authzId,=20 =20 Expires December 6, 2004 [Page 36]=20 JAVA LDAP API April 2004=20 =20 =20 String[] mechanisms,=20 Map props,=20 javax.security.auth.callback.CallbackHandler cbh,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 =20 Synchronously authenticates using SASL authentication to the LDAP=20 server (that the object is currently connected to) using the=20 specified name and one of a specified set of mechanisms. If none of=20 the requested SASL [SASL][AUTH][JAVASASL] mechanisms is available, an=20 exception is thrown. If the object had already authenticated, the=20 old authentication is discarded. If the object has been disconnected=20 from an LDAP server, this method attempts to reconnect to the server.=20 A SASL bind call may involve multiple protocol requests and=20 responses. An attempt to invoke an operation other than bind or=20 unbind between bind requests in a multi-stage bind, results in an=20 LDAPException with the result code SASL_BIND_IN_PROGRESS.Parameters=20 are:=20 =20 dn The distinguished name to use as the bind name.=20 It may be null or empty. This value is not used=20 as either a SASL authentication nor authorization=20 identity. The application provides these=20 identities through the callback handler.=20 =20 authzId If not null and not empty, an LDAP authzID [AUTH]=20 to be passed to the SASL layer. If null or empty,=20 the authzId will be treated as an empty string=20 and processed as per RFC 2222 [SASL].=20 =20 mechanisms An array of IANA-registered SASL mechanisms which=20 the client application is willing to use for=20 authentication. Null or an empty array may be=20 specified to abort the negotiation, forcing the=20 server to return an AUTH_METHOD_NOT_SUPPORTED=20 result.=20 =20 props Optional qualifiers for the authentication=20 session.=20 =20 cbh A class which may be called by the SASL client=20 implementation to obtain additional information=20 required, such as additional credentials.=20 =20 cons Constraints specific to the operation.=20 =20 See [JAVASASL] for additional information about the above parameters.=20 =20 =20 =20 =20 Expires December 6, 2004 [Page 37]=20 JAVA LDAP API April 2004=20 =20 =20 2.8.7 clone=20 =20 public Object clone()=20 =20 Returns a copy of the object with a private context, but sharing the=20 network connection if there is one. The network connection remains=20 open until all clones have disconnected or gone out of scope. Any=20 connection opened after cloning is private to the object making the=20 connection.=20 =20 The clone can freely modify options and search constraints, and issue=20 requests, without affecting the source object or other clones. If the=20 clone disconnects or reconnects, it is completely dissociated from=20 the source object and other clones. Reauthenticating in a clone,=20 however, is a global operation which will affect the source object=20 and all associated clones, because it applies to the single shared=20 physical connection. Any request by an associated object after one=20 has reauthenticated will carry the new identity.=20 =20 Methods that are global in nature and which affect the source object=20 are:=20 =20 addUnsolicitedNotificationListener=20 bind=20 connect=20 disconnect=20 finalize=20 removeUnsolicitedNotificationListener=20 startTLS=20 =20 The following methods return data that is from the source object and=20 is the same for all clones of LDAPConnection:=20 =20 getAuthenticationDN=20 getAuthenticationMethod=20 getHost=20 getPort=20 getProtocolVersion=20 getSaslBindCallBackHandler=20 getSaslBindProperties=20 getSocketFactory=20 isBound=20 isConnected=20 isTLS=20 =20 The following methods manipulate or retrieve data that is unique to=20 each clone of LDAPConnection:=20 =20 getConstraints=20 getResponseControls=20 getSearchConstraints=20 setConstraints=20 =20 Expires December 6, 2004 [Page 38]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 2.8.8 compare=20 =20 public boolean compare(String dn,=20 LDAPAttribute attr)=20 throws LDAPException=20 =20 public boolean compare(String dn,=20 LDAPAttribute attr,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 public LDAPMessageQueue compare(String dn,=20 LDAPAttribute attr,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 public LDAPMessageQueue compare(String dn,=20 LDAPAttribute attr,=20 LDAPMessageQueue queue,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 Checks to see if an entry in the Directory Server contains an=20 attribute with a specified=20 value. The synchronous methods return a value of true if the entry=20 has the value, and false if the entry does not have the value or the=20 attribute. The method throws an IllegalArgumentException if=20 LDAPAttribute object specified by the attr parameter contains more=20 than one value.=20 Parameters are:=20 =20 dn The distinguished name of the entry to use in the=20 comparison.=20 =20 attr The attribute to compare against the entry. The=20 method checks to see if the entry has an=20 attribute with the same name and value as this=20 attribute.=20 =20 queue Handler for messages returned from a server in=20 response to this request. If it is null, a queue=20 object is created internally.=20 =20 cons Constraints specific to the operation.=20 =20 =20 2.8.9 connect=20 =20 public void connect(String host,=20 int port)=20 =20 Expires December 6, 2004 [Page 39]=20 JAVA LDAP API April 2004=20 =20 =20 throws LDAPException=20 =20 Connects to the specified host and port. If this LDAPConnection=20 object represents an open connection, the connection is closed first=20 before the new connection is opened. At this point there is no=20 authentication, and any operations will be conducted as an anonymous=20 client.=20 =20 Parameters are:=20 =20 host Contains a host identifier consisting of a=20 hostname, an IPv4 dotted string, or an IPv6=20 reference [IPv6] representing the IP address of a=20 host running an LDAP server to connect to.=20 Alternatively, it may contain a list of host=20 identifiers, space-delimited. Each host=20 identifier may include a trailing colon and port=20 number. IPv6 identifiers with a port number are=20 represented with square brackets around the IP=20 address part as per [IPv6URL]. In the case where=20 more than one host identifier is specified, each=20 host identifier in turn will be contacted until a=20 connection can be established. Examples:=20 =20 "directory.example.com"=20 "192.0.2.0"=20 "[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:4389"=20 "directory.example.com:1050 people.catalog.com 192.0.2.0"=20 =20 port Port number for LDAP server (use=20 LDAPConnection.DEFAULT_PORT for default port).=20 "port" is ignored for any host identifier which=20 includes a colon and port number.=20 =20 =20 2.8.10 delete=20 =20 public void delete(String dn) throws LDAPException=20 =20 public void delete(String dn,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 public LDAPMessageQueue delete(String dn,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 public LDAPMessageQueue delete(String dn,=20 LDAPMessageQueue queue,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 =20 Expires December 6, 2004 [Page 40]=20 JAVA LDAP API April 2004=20 =20 =20 Deletes the entry for the specified DN from the directory.=20 =20 =20 Parameters are:=20 =20 dn Distinguished name of the entry to delete.=20 =20 queue Handler for messages returned from a server in=20 response to this request. If it is null, a queue=20 object is created internally.=20 =20 cons Constraints specific to the operation.=20 =20 =20 2.8.11 disconnect=20 =20 public void disconnect() throws LDAPException=20 =20 public void disconnect(LDAPConstraints cons) throws LDAPException=20 =20 =20 Disassociates the LDAPConnection object from clones and any physical=20 connection to an LDAP server. If the object is the last clone sharing=20 a physical connection, the method closes the connection with the LDAP=20 server. The API implementation sends an Unbind request to the server=20 with any controls specified by the LDAPConstraints object before=20 closing the connection. Before the application can perform LDAP=20 operations again, it MUST reconnect to a server by calling either=20 connect or bind (bind will attempt to reconnect to the previous=20 server).=20 =20 Parameters are:=20 =20 cons Constraints to be sent with the unbind request.=20 =20 =20 2.8.12 extendedOperation=20 =20 public LDAPExtendedResponse extendedOperation(=20 LDAPExtendedOperation op )=20 throws LDAPException=20 =20 public LDAPExtendedResponse extendedOperation(=20 LDAPExtendedOperation op,=20 LDAPConstraints cons )=20 throws LDAPException=20 =20 public LDAPMessageQueue extendedOperation(=20 LDAPExtendedOperation op,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 =20 Expires December 6, 2004 [Page 41]=20 JAVA LDAP API April 2004=20 =20 =20 public LDAPMessageQueue extendedOperation(=20 LDAPExtendedOperation op,=20 LDAPConstraints cons,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 Provides a means to access extended, non-mandatory operations offered=20 by a particular LDAP version 3 compliant server.=20 =20 Returns an operation-specific object, containing an OID and an Octet=20 String or BER-encoded value(s).=20 =20 Parameters are:=20 =20 op Object which contains the OID of the extended=20 operation and any operation-specific data.=20 =20 cons Constraints specific to the operation.=20 =20 =20 2.8.13 fetchSchema=20 =20 public LDAPSchema fetchSchema(String schemaDN)=20 throws LDAPException=20 =20 Retrieves the schema associated with a particular schema DN in the=20 Directory Server. The schema DN for a particular entry is obtained by=20 calling the getSchemaDN method of LDAPConnection (see 2.8.25).=20 =20 An LDAPException is thrown if the schema cannot be retrieved.=20 =20 Parameters are:=20 =20 schemaDN The schema DN used to fetch the schema.=20 =20 =20 2.8.14 finalize=20 =20 protected void finalize() throws LDAPException=20 =20 Closes the connection if open and releases any other resources held=20 by the object.=20 =20 =20 2.8.15 getAuthenticationDN=20 =20 public String getAuthenticationDN()=20 =20 Returns the distinguished name (DN) used as the bind name during the=20 last successful bind operation. null is returned if no authentication=20 has been performed or if the bind resulted in an anonymous=20 connection.=20 =20 Expires December 6, 2004 [Page 42]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 2.8.16 getAuthenticationMethod=20 =20 public String getAuthenticationMethod()=20 =20 Returns the method used to authenticate the connection. The return=20 value is one of the following:=20 =20 "none" The current authentication state has not been=20 established by use of the bind operation. This=20 is the initial state upon connect(), as well as=20 if the last bind failed.=20 =20 "simple" Simple bind has completed successfully=20 (anonymous, unauthenticated, or authenticated)=20 =20 "sasl" The current authentication state was established=20 by the successful completion of a SASL bind=20 =20 =20 2.8.17 getConstraints=20 =20 public LDAPConstraints getConstraints()=20 =20 Returns a copy of the set of constraints associated with this=20 connection. These constraints apply to all operations performed=20 through this connection (unless a different set of constraints is=20 specified when calling an operation method). If no constraints have=20 been assigned with setConstraints, a copy of the default constraints=20 is returned.=20 =20 =20 2.8.18 getHost=20 =20 public String getHost()=20 =20 Returns the host name of the LDAP server to which the object is or=20 was last connected, in the format originally specified. If no=20 connection attempt has been made, null is returned.=20 =20 =20 2.8.19 getPort=20 =20 public int getPort()=20 =20 Returns the port number of the LDAP server to which the object is or=20 was last connected. If no connection attempt has been made,=20 LDAPConnection.DEFAULT_PORT is returned.=20 =20 =20 =20 Expires December 6, 2004 [Page 43]=20 JAVA LDAP API April 2004=20 =20 =20 2.8.20 getProperty=20 =20 public Object getProperty(String name)=20 =20 Gets a property of a connection object. The properties are defined by=20 the API implementation and not modifiable by the client application.=20 =20 Parameters are:=20 =20 name Name of the property to be returned.=20 =20 The following read-only properties are available=20 for any given connection:=20 =20 =20 LDAP_PROPERTY_SDK ("version.sdk") The version of=20 this SDK, as a=20 String data type.=20 =20 =20 LDAP_PROPERTY_PROTOCOL ("version.protocol") The=20 highest supported=20 version of the LDAP=20 protocol, as an=20 Integer data type.=20 =20 =20 LDAP_PROPERTY_SECURITY ("security.types") A=20 comma-separated=20 list of the types=20 of authentication=20 supported, as a=20 String. See 2.8.16.=20 =20 Other properties MAY be available in particular implementations=20 of the class.=20 =20 A deep copy of the property is provided where applicable; the=20 client application does not need to clone the object received.=20 =20 null is returned if the requested property is not available.=20 =20 =20 2.8.21 getProtocolVersion=20 =20 public int getProtocolVersion ()=20 =20 Returns the protocol version that the connection is bound to (which=20 currently is 3). If the connection is not bound, it returns 3.=20 =20 =20 =20 Expires December 6, 2004 [Page 44]=20 JAVA LDAP API April 2004=20 =20 =20 2.8.22 getResponseControls=20 =20 public LDAPControl[] getResponseControls()=20 =20 Returns the latest Server Controls returned by a Directory Server =20 with a response to an LDAP request from the current thread. For=20 asynchronous requests, the response controls are available in=20 LDAPMessage instead. Returns null if none or if using asynchronous=20 requests.=20 =20 =20 2.8.23 getSaslBindCallbackHandler=20 =20 public javax.security.auth.callback.CallbackHandler=20 getSaslBindCallbackHandler()=20 =20 Returns the callback handler, if any, specified on binding with a=20 SASL mechanism, or null if none.=20 =20 =20 2.8.24 getSaslBindProperties=20 =20 public Map getSaslBindProperties()=20 =20 Returns the properties, if any, specified on binding with a SASL=20 mechanism, or null if none.=20 =20 =20 2.8.25 getSchemaDN=20 =20 public String getSchemaDN() throws LDAPException=20 =20 Retrieves the DN for the schema at the root DSE of the Directory=20 Server.=20 =20 Throws LDAPException if the schema DN cannot be retrieved, or if the=20 subschemaSubentry attribute associated with the root DSE contains=20 multiple values. =20 =20 =20 public String getSchemaDN(String dn) throws LDAPException=20 =20 Retrieves the DN of the schema associated with a particular entry=20 in the directory. Used with LDAPConnection.fetchSchema(), see 2.8.13.=20 =20 Throws LDAPException if the schema DN cannot be retrieved, or if a=20 null or empty value is passed as dn, or if the subschemaSubentry=20 attribute associated with the root DSE contains multiple values.=20 =20 Parameters are:=20 =20 =20 Expires December 6, 2004 [Page 45]=20 JAVA LDAP API April 2004=20 =20 =20 dn Distinguished name of the entry for which the=20 schema DN is to be retrieved.=20 =20 =20 2.8.26 getSearchConstraints=20 =20 public LDAPSearchConstraints getSearchConstraints()=20 =20 Returns a clone of the search constraints associated with this=20 connection. These constraints apply to search operations performed=20 through this connection (unless a different set of constraints is=20 specified when calling the search operation method). The search=20 constraints include the base constraints returned by=20 getConstraints(). If no constraints have been assigned with=20 setConstraints, a clone of the default constraints is returned.=20 =20 =20 2.8.27 getSocketFactory=20 =20 public SocketFactory getSocketFactory()=20 =20 Returns the SocketFactory used to establish a connection to a server.=20 =20 =20 2.8.28 isBound=20 =20 public boolean isBound()=20 =20 Indicates whether the object has authenticated to the connected LDAP=20 server (other than anonymously with simple bind). It returns false=20 initially, false upon a bind request, and true after successful=20 completion of the last outstanding non-anonymous simple bind.=20 =20 =20 2.8.29 isConnected=20 =20 public boolean isConnected()=20 =20 Indicates if the connection represented by this object is open at=20 this time.=20 =20 =20 2.8.30 isTLS=20 =20 public boolean isTLS ()=20 =20 Indicates the session is currently protected by TLS. Themethod=20 provides no indication of the level of protection provided.=20 =20 =20 2.8.31 modify=20 =20 =20 Expires December 6, 2004 [Page 46]=20 JAVA LDAP API April 2004=20 =20 =20 public void modify(String dn,=20 LDAPModification mod)=20 throws LDAPException=20 =20 public void modify(String dn,=20 LDAPModification mod,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 public LDAPMessageQueue modify(String dn,=20 LDAPModification mod,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 public LDAPMessageQueue modify(String dn,=20 LDAPModification mod,=20 LDAPMessageQueue queue,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 Makes a single change to an existing entry in the directory (for=20 example, changes the value of an attribute, adds a new attribute=20 value, or removes an existing attribute value).=20 =20 The LDAPModification object specifies both the change to be made and=20 the LDAPAttribute value to be changed.=20 =20 The application is responsible for specifying attribute values which=20 are valid according to the syntax defined for the attributes.=20 =20 =20 public void modify(String dn,=20 LDAPModification[] mods)=20 throws LDAPException=20 =20 public void modify(String dn,=20 LDAPModification[] mods,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 public LDAPMessageQueue modify(String dn,=20 LDAPModification[] mods,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 public LDAPMessageQueue modify(String dn,=20 LDAPModification[] mods,=20 LDAPMessageQueue queue,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 Makes multiple changes to an existing entry in the directory (for=20 =20 Expires December 6, 2004 [Page 47]=20 JAVA LDAP API April 2004=20 =20 =20 example, changes attribute values, adds new attribute values, or=20 removes existing attribute values).=20 =20 =20 The application is responsible for specifying attribute values which=20 are valid according to the syntax defined for the attributes.=20 =20 Parameters are:=20 =20 dn Distinguished name of the entry to modify.=20 =20 mod A single change to be made to the entry.=20 =20 mods An array specifying multiple changes to be made=20 to the entry. The changes are made in the order=20 specified.=20 =20 queue Handler for messages returned from a server in=20 response to this request. If it is null, a queue=20 object is created internally.=20 =20 cons Constraints specific to the operation.=20 =20 =20 2.8.32 read=20 =20 public LDAPEntry read(String dn) throws LDAPException=20 =20 public LDAPEntry read(String dn,=20 LDAPSearchConstraints cons)=20 throws LDAPException=20 =20 Reads the entry from the directory for the specified distiguished=20 name (DN) and=20 retrieves all attributes for the entry.=20 =20 =20 public LDAPEntry read(String dn,=20 String[] attrs)=20 throws LDAPException=20 =20 public LDAPEntry read(String dn,=20 String[] attrs,=20 LDAPSearchConstraints cons)=20 throws LDAPException=20 =20 Reads the entry for the specified distinguished name (DN) and=20 retrieves only the specified attributes from the entry.=20 =20 =20 public static LDAPEntry read(LDAPUrl toGet) throws LDAPException=20 =20 =20 Expires December 6, 2004 [Page 48]=20 JAVA LDAP API April 2004=20 =20 =20 public static LDAPEntry read(LDAPUrl toGet,=20 LDAPSearchConstraints cons)=20 throws LDAPException=20 =20 Reads the entry specified by the LDAP URL and=20 retrieves all attributes for the entry.=20 =20 When this method is called, a new connection is created=20 automatically, using the host and port specified in the URL. After=20 reading the entry, the method closes the connection (in other words,=20 it disconnects from the LDAP server).=20 =20 If the URL specifies a scope other than base,=20 IllegalArgumentException is thrown. Any critical extensions specified=20 in the URL must be processed or else an LDAPException is thrown with=20 the result code UNSUPPORTED_OPERATION.=20 =20 The method returns the entry specified by the base DN.=20 =20 =20 Parameters are:=20 =20 dn Distinguished name of the entry to retrieve.=20 =20 cons Constraints specific to the operation.=20 =20 attrs Names of attributes to retrieve.=20 =20 toGet LDAP URL specifying the entry to read.=20 =20 =20 If the server does not return exactly one entry, an LDAPException is=20 thrown with a result code of AMBIGIOUS_RESPONSE.=20 =20 Note: read is simply a helper method and uses the ldap search=20 operation to achieve the results. As such, there is no asynchronous=20 interface.=20 =20 =20 2.8.33 removeUnsolicitedNotificationListener=20 =20 public void removeUnsolicitedNotificationListener(=20 LDAPUnsolicitedNotificationListener listener)=20 =20 Deregisters an object so that it will no longer be notified on=20 arrival of an unsolicited message from a server. If the object is=20 null or was not previously registered for unsolicited notifications,=20 the method does nothing.=20 =20 Parameters are:=20 =20 =20 Expires December 6, 2004 [Page 49]=20 JAVA LDAP API April 2004=20 =20 =20 listener An object to no longer be notified on arrival of=20 an unsolicited message from a server.=20 =20 =20 2.8.34 rename=20 =20 public void rename(String dn,=20 String newRdn,=20 boolean deleteOldRdn)=20 throws LDAPException=20 =20 public void rename(String dn,=20 String newRdn,=20 boolean deleteOldRdn,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 public LDAPMessageQueue rename(String dn,=20 String newRdn,=20 boolean deleteOldRdn,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 public LDAPMessageQueue rename(String dn,=20 String newRdn,=20 boolean deleteOldRdn,=20 LDAPMessageQueue queue,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 Renames an existing entry in the directory.=20 =20 =20 public void rename(String dn,=20 String newRdn,=20 String newParentdn,=20 boolean deleteOldRdn)=20 throws LDAPException=20 =20 public void rename(String dn,=20 String newRdn,=20 String newParentdn,=20 boolean deleteOldRdn,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 public LDAPMessageQueue rename(String dn,=20 String newRdn,=20 String newParentdn,=20 boolean deleteOldRdn,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 Expires December 6, 2004 [Page 50]=20 JAVA LDAP API April 2004=20 =20 =20 =20 public LDAPMessageQueue rename(String dn,=20 String newRdn,=20 String newParentdn,=20 boolean deleteOldRdn,=20 LDAPMessageQueue queue,=20 LDAPConstraints cons)=20 throws LDAPException=20 =20 Renames an existing entry or subtree in the directory, possibly=20 repositioning it in the directory tree.=20 =20 Parameters are:=20 =20 dn Current distinguished name of the entry.=20 =20 newRdn New relative distinguished name for the entry.=20 =20 newParentdn Distinguished name of the existing entry which is=20 to be the new parent of the entry. If newParentdn=20 is null, the request is treated as if the method=20 without newParentdn is called.=20 =20 deleteOldRdn If true, the old name is not retained as an=20 attribute value.=20 =20 queue Handler for messages returned from a server in=20 response to this request. If it is null, a queue=20 object is created internally.=20 =20 cons Constraints specific to the operation.=20 =20 =20 2.8.35 search=20 =20 public LDAPSearchResults search(String base,=20 int scope,=20 String filter,=20 String[] attrs,=20 boolean typesOnly)=20 throws LDAPException=20 =20 public LDAPMessageQueue search(String base,=20 int scope,=20 String filter,=20 String[] attrs,=20 boolean typesOnly,=20 LDAPMessageQueue queue)=20 throws LDAPException=20 =20 Performs the search specified by the parameters.=20 =20 =20 Expires December 6, 2004 [Page 51]=20 JAVA LDAP API April 2004=20 =20 =20 =20 public LDAPSearchResults search(String base,=20 int scope,=20 String filter,=20 String[] attrs,=20 boolean typesOnly,=20 LDAPSearchConstraints cons)=20 throws LDAPException=20 =20 public LDAPMessageQueue search(String base,=20 int scope,=20 String filter,=20 String[] attrs,=20 boolean typesOnly,=20 LDAPMessageQueue queue,=20 LDAPSearchConstraints cons)=20 throws LDAPException=20 =20 Performs the search specified by the parameters, also allowing=20 specification of operation specific constraints for the search (such=20 as the maximum=20 number of entries to find or the maximum time to wait for search=20 results).=20 =20 As part of the operation or default search constraints, a choice can=20 be made as to =20 whether or not the results are to be delivered all at once or in=20 smaller batches. If specified that the results are to be delivered in=20 smaller batches, each iteration blocks only until the next batch of=20 results is received from the server.=20 =20 =20 public static LDAPSearchResults search(LDAPUrl toGet)=20 throws LDAPException=20 =20 Performs the search specified by the LDAP URL, returning an=20 enumerable LDAPSearchResults object.=20 =20 =20 public static LDAPSearchResults search(LDAPUrl toGet,=20 LDAPSearchConstraints cons)=20 throws LDAPException=20 =20 Perfoms the search specified by the LDAP URL. This method also allows=20 specifying operation specific constraints for the search (such as the=20 maximum number of entries to find or the maximum time to wait for=20 search results).=20 =20 When the methods using the LDAPUrl parameter are called, a new=20 connection is created automatically, using the host and port=20 specified in the URL. After all search results have been received=20 =20 Expires December 6, 2004 [Page 52]=20 JAVA LDAP API April 2004=20 =20 =20 from the server, the method closes the connection (in other words, it=20 disconnects from the LDAP server).=20 =20 As part of operation or default search constraints, a choice can be=20 made as to whether to have the results delivered all at once or in=20 smaller batches. If the results are to be delivered in smaller=20 batches, each iteration blocks only until the next batch of results=20 is received from the server.=20 =20 =20 Parameters are:=20 =20 base The base distinguished name to search from.=20 =20 scope The scope of the entries to search. The following=20 are the valid options:=20 =20 SCOPE_BASE Search only the base DN=20 =20 SCOPE_ONE Search only entries directly under the base=20 DN=20 =20 SCOPE_SUB Search the base DN and all entries within=20 its subtree=20 =20 filter Search filter specifying the search criteria, as=20 defined in [FILTER]. The value null can be passed=20 to indicate that the filter "(objectclass=3D*)"=20 which matches all entries is to be used.=20 =20 attrs Names of attributes to retrieve. If null or an=20 empty array is specified, all attributes are=20 retrieved.=20 =20 typesOnly If true, returns the names but not the values of=20 the attributes found. If false, returns the=20 names and values for attributes found.=20 =20 toGet LDAP URL specifying the entry to read.=20 =20 queue Handler for messages returned from a server in=20 response to this request. If it is null, a queue=20 object is created internally.=20 =20 cons Constraints specific to the search.=20 =20 Note: RFC 2251 [LDAPPROTO] indicates that extendedResponses on search=20 requests may be defined in future versions of the LDAP protocol.=20 There is no support for extendedResponses on search requests in this=20 version of the Java LDAP API.=20 =20 =20 =20 Expires December 6, 2004 [Page 53]=20 JAVA LDAP API April 2004=20 =20 =20 2.8.36 setConstraints=20 =20 public void setConstraints(LDAPConstraints cons)=20 =20 Sets the constraints that apply to all operations performed through=20 this connection (unless a different set of constraints is specified=20 when calling an operation method). An LDAPSearchConstraints object=20 which is passed to this method will override all constraints (search=20 and base), while an LDAPConstraints object will only affect the base=20 constraints.=20 =20 Parameters are:=20 =20 cons Non-null constraints object.=20 =20 =20 2.8.37 setSocketFactory=20 =20 public static void setSocketFactory(SocketFactory factory)=20 =20 Establishes the default SocketFactory used when LDAPConnection=20 objects are constructed unless an SocketFactory is specified in the=20 LDAPConnection object constructor.=20 =20 This method sets the default SocketFactory used for all subsequent=20 LDAPConnection objects constructed. If called after LDAPConnection=20 objects are created, those already created are not affected even if=20 they disconnect and establish a new connection. It affects=20 LDAPConnection objects only as they are constructed.=20 =20 If a security manager exists and the caller does not have permission=20 to set a factory, SecurityException is thrown.=20 =20 To use the setSocketFactory method, the caller needs the following=20 permission: =20 =20 java.lang.RuntimePermission("setFactory");=20 =20 Parameters are:=20 =20 factory A factory object which can construct socket=20 connections for an LDAPConnection. If null, the=20 default factory of the API implementation is=20 selected.=20 =20 =20 2.8.38 startTLS=20 =20 public void startTLS()=20 throws LDAPException=20 =20 =20 Expires December 6, 2004 [Page 54]=20 JAVA LDAP API April 2004=20 =20 =20 Begin using the Transport Layer Security (TLS) protocol for session=20 privacy [TLS][LDAPTLS]. If the socket factory of the connection is=20 not capable of initiating a TLS session, an LDAPException is thrown=20 with the error code TLS_NOT_SUPPORTED. If the server does not support=20 the transition to a TLS session, an LDAPException is thrown with the=20 error code returned by the server. If there are outstanding LDAP=20 operations on the connection, an LDAPException is thrown.=20 =20 =20 2.8.39 stopTLS=20 =20 public void stopTLS ()=20 throws LDAPException=20 =20 Stop using the Transport Layer Security (TLS) protocol for session=20 privacy [LDAPTLS]. If the server does not support the termination of=20 a TLS session, an LDAPException is thrown with the error code=20 returned by the server. If there are outstanding LDAP operations on=20 the connection, an LDAPException is thrown.=20 =20 =20 =20 2.8.40 Constants of LDAPConnection=20 =20 ALL_USER_ATTRS ("*") Used with search in an attribute list to=20 indicate that all attributes (other than=20 operational attributes) are to be returned.=20 =20 NO_ATTRS ("1.1") Used with search instead of an attribute list=20 to indicate that no attributes are to be=20 returned.=20 =20 DEFAULT_PORT (389) Used with connect to indicate the default LDAP=20 port number.=20 =20 SCOPE_BASE (0) Used with search to indicate that only the entry=20 corresponding to the base DN is to be returned.=20 =20 SCOPE_ONE (1) Used with search to indicate that only immediate=20 subordinates of the entry corresponding to the=20 base DN, and not the entry corresponding to the=20 base DN, are to be returned.=20 =20 SCOPE_SUB (2) Used with search to indicate that the entry=20 corresponding to the base DN as well as all=20 direct and indirect subordinate entries are to be=20 returned.=20 =20 LDAP_PROPERTY_SDK ("version.sdk") Used with=20 getProperty to retrieve the version of the SDK.=20 =20 =20 Expires December 6, 2004 [Page 55]=20 JAVA LDAP API April 2004=20 =20 =20 LDAP_PROPERTY_PROTOCOL ("version.protocol") Used with=20 getProperty to retrieve the highest supported=20 LDAP protocol version.=20 =20 LDAP_PROPERTY_SECURITY ("security.types") Used with=20 getProperty to retrieve a list of the=20 authentication types supported.=20 =20 =20 2.9 public class LDAPConstraints=20 implements Cloneable, Serializable=20 =20 A set of options to control any operation. There is always an=20 LDAPConstraints associated with an LDAPConnection object; its=20 values can be changed with LDAPConnection.setConstraints, or=20 overridden by passing an LDAPConstraints object to an operation.=20 =20 =20 2.9.1 Constructors=20 =20 public LDAPConstraints()=20 =20 Constructs an LDAPConstraints object that specifies the default=20 set of constraints.=20 =20 =20 public LDAPConstraints(int msLimit,=20 boolean doReferrals,=20 LDAPReferralHandler handler,=20 int hop_limit)=20 =20 Constructs a new LDAPConstraints object and allows specifying=20 the operational constraints in that object.=20 =20 Parameters are:=20 =20 msLimit Maximum time in milliseconds to wait for results=20 (0 by default, which means that there is no=20 maximum time limit). This is an interface- enforced limit.=20 =20 doReferrals Specify true to follow referrals automatically,=20 or false to throw an LDAPReferralException error=20 if the server sends back a referral (false by=20 default). It is ignored for asynchronous=20 operations.=20 =20 handler Custom authentication processor, called when the=20 LDAPConnection needs to authenticate, typically=20 on following a referral. The value null indicates=20 default authentication processing, which is, to=20 use anonymous authentication if automatically=20 =20 Expires December 6, 2004 [Page 56]=20 JAVA LDAP API April 2004=20 =20 =20 following referrals. This parameter ignored if=20 doReferrals is set to false. The handler object=20 may implement either the LDAPBindHandler or the=20 LDAPAuthHandler interface. Any settings for=20 following referrals are ignored for asynchronous=20 operations.=20 =20 hop_limit Maximum number of referrals to follow in a=20 sequence when attempting to resolve a request,=20 when doing automatic referral following. It is=20 ignored for asynchronous operations.=20 =20 =20 2.9.2 getControls=20 =20 public LDAPControl[] getControls() =20 =20 Returns controls to be sent to the server. =20 =20 =20 2.9.3 getHopLimit=20 =20 public int getHopLimit()=20 =20 Returns the maximum number of hops to follow during automatic=20 referral following.=20 =20 =20 2.9.4 getProperty=20 =20 public Object getProperty(String name)=20 =20 Gets a property of a constraints object which has been assigned with=20 setProperty. null is returned if the property is not defined.=20 =20 Parameters are:=20 =20 name Name of the property to be returned.=20 =20 =20 2.9.5 getReferralFollowing=20 =20 public boolean getReferralFollowing()=20 =20 Specifies whether or not referrals are followed automatically.=20 Returns true if referrals are to be followed automatically, or false=20 if receipt of referrals causes the API to throw an=20 LDAPReferralException.=20 =20 =20 2.9.6 getTimeLimit=20 =20 =20 Expires December 6, 2004 [Page 57]=20 JAVA LDAP API April 2004=20 =20 =20 public int getTimeLimit()=20 =20 Returns the maximum number of milliseconds the client application=20 waits for any operation under these constraints. If 0, there is no=20 maximum time limit on waiting for the operation results. The time=20 limit is enforced by the API, and the actual granularity of the=20 timeout depends on the implementation.=20 =20 =20 2.9.7 setControls=20 =20 public void setControls( LDAPControl control ) =20 =20 public void setControls( LDAPControl[] controls ) =20 =20 Sets controls to be sent to the server.If controls are not set by=20 calling this method, no controls are sent to the server.=20 =20 Parameters are: =20 =20 control A single control to be sent to the server. =20 =20 controls An array of controls to be sent to the server. =20 =20 =20 2.9.8 setHopLimit=20 =20 public void setHopLimit(int hop_limit)=20 =20 Sets the maximum number of hops to follow in sequence during=20 automatic referral following. The default is 10. 0 means no limit.=20 =20 Parameters are:=20 =20 hop_limit Maximum number of chained referrals to follow=20 automatically.=20 =20 =20 2.9.9 setProperty=20 =20 public void setProperty(String name, Object value)=20 =20 Sets a property of the constraints object.=20 =20 No property names have been defined at this time, but the mechanism=20 is in place in order to support revisional as well as dynamic and=20 proprietary extensions to operation modifiers. Throws=20 IllegalArgumentException if the property name is not defined in the=20 API.=20 =20 Parameters are:=20 =20 =20 Expires December 6, 2004 [Page 58]=20 JAVA LDAP API April 2004=20 =20 =20 name Name of the property to set.=20 =20 value Value to assign to the property.=20 =20 =20 2.9.10 setReferralFollowing=20 =20 public void setReferralFollowing(boolean doReferrals)=20 =20 Specifies whether nor not referrals are followed automatically, or if=20 referrals throw an LDAPReferralException. The default is false, i.e.,=20 do not follow referrals=20 =20 Parameters are:=20 =20 doReferrals True to follow referrals automatically.=20 =20 =20 2.9.11 setReferralHandler=20 =20 public void setReferralHandler (LDAPReferralHandler handler)=20 =20 Specifies the object that will process authentication requests. The=20 default is null.=20 =20 Parameters are:=20 =20 handler An object that implements LDAPBindHandler or=20 LDAPAuthHandler.=20 =20 =20 2.9.12 setTimeLimit=20 =20 public void setTimeLimit(int msLimit)=20 =20 Sets the maximum number of milliseconds to wait for any operation=20 under these constraints. If 0, there is no maximum time limit=20 on waiting for the operation results. The time limit is enforced by=20 the API, and the actual granularity of the=20 time limit depends on the implementation.=20 =20 Parameters are:=20 =20 msLimit Maximum milliseconds to wait.=20 =20 =20 2.10 public class LDAPControl=20 implements Serializable, Cloneable=20 =20 An LDAPControl encapsulates optional additional parameters or=20 constraints to be applied to LDAP operations. When included with=20 LDAPConstraints or LDAPSearchConstraints on an LDAPConnection or on a=20 =20 Expires December 6, 2004 [Page 59]=20 JAVA LDAP API April 2004=20 =20 =20 specific operation request, it is sent to the server along with=20 operation requests.=20 =20 =20 2.10.1 Constructors=20 =20 public LDAPControl(String oid,=20 boolean critical,=20 byte[] value)=20 =20 Parameters are:=20 =20 oid The type of the Control, as an OID.=20 =20 critical If true, the LDAP operation will fail with=20 UNAVAILABLE_CRITICAL_EXTENSION if the server does=20 not support this Control.=20 =20 value BER-Encoded control-specific data. The API=20 implementation does not interpret or convert the=20 value.=20 =20 =20 2.10.2 clone=20 =20 public Object clone()=20 =20 Returns a deep copy of the object.=20 =20 =20 2.10.3 getID=20 =20 public String getID()=20 =20 Returns the OID of the control.=20 =20 =20 2.10.4 getValue=20 =20 public byte[] getValue()=20 =20 Returns the control-specific data of the object.=20 =20 =20 2.10.5 isCritical=20 =20 public boolean isCritical()=20 =20 Returns true if the control must be supported for an associated=20 operation to be executed.=20 =20 =20 =20 Expires December 6, 2004 [Page 60]=20 JAVA LDAP API April 2004=20 =20 =20 2.10.6 register =20 =20 public static void register(String oid, Class controlClass)=20 =20 Registers an application class to be instantiated on receipt of a=20 control with the given OID. Any previous registration for the OID is=20 overridden. The controlClass MUST be an extension of LDAPControl.=20 =20 Parameters are:=20 =20 oid The OID of the Control.=20 =20 controlClass A class which can instantiate an LDAPControl.=20 =20 =20 2.10.7 setValue=20 =20 protected void setValue(byte[] value)=20 =20 Sets the BER-Encoded control-specific data of the object. This method=20 is for use by extensions of LDAPControl.=20 =20 Parameters are:=20 =20 value The value to be assigned to the Control.=20 =20 =20 2.11 public class LDAPDITContentRuleSchema=20 extends LDAPSchemaElement=20 =20 The LDAPDITContentRuleSchema class represents the definition of a DIT=20 Content Rule. It is used to discover or modify additional auxiliary=20 classes, mandatory and optional attributes, and restricted attributes=20 in effect for an object class. See [ATTR] for a description of DIT=20 content rule representation in LDAP.=20 =20 2.11.1 Constructors=20 =20 public LDAPDITContentRuleSchema(String[] names,=20 String oid,=20 String description,=20 boolean obsolete,=20 String[] auxiliary,=20 String[] required,=20 String[] optional,=20 String[] precluded)=20 =20 Constructs a DIT content rule for adding to or deleting from the=20 schema. [LDAPPROTO] defines which parameters are optional (may be=20 null).=20 =20 =20 =20 Expires December 6, 2004 [Page 61]=20 JAVA LDAP API April 2004=20 =20 =20 public LDAPDITContentRuleSchema(String raw)=20 =20 Constructs a DIT content rule from an encoding using the=20 ditContentRules syntax [ATTR].=20 =20 Parameters are:=20 =20 names Name(s) of the content rule.=20 =20 oid OID of the content.=20 =20 description Optional description of the content rule.=20 =20 obsolete true if the content rule is obsolete. =20 =20 auxiliary A list of auxiliary object classes allowed for=20 an entry to which this content rule applies.=20 These may either be specified by name or by=20 OID.=20 =20 required A list of user attribute types that an entry=20 to which this content rule applies must=20 contain in addition to its normal set of=20 mandatory attributes. These may either be=20 specified by name or OID.=20 =20 optional A list of user attribute types that an entry=20 to which this content rule applies may contain=20 in addition to its normal set of optional=20 attributes. These may either be specified by=20 name or OID.=20 =20 precluded A list, consisting of a subset of the optional=20 user attribute types of the structural and=20 auxiliary object classes which are precluded=20 from an entry to which this content rule=20 applies. These may either be specified by name=20 or OID.=20 =20 =20 raw A DIT content rule encoded using the=20 ditContentRules syntax [ATTR].=20 =20 2.11.2 getAuxiliaryClasses=20 =20 public String[] getAuxiliaryClasses()=20 =20 Returns the list of allowed auxiliary classes.=20 =20 2.11.3 getOptionalAttributes=20 =20 public String[] getOptionalAttributes()=20 =20 Expires December 6, 2004 [Page 62]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Returns the list of additional optional attributes for an entry=20 controlled by this content rule.=20 =20 =20 2.11.4 getPrecludedAttributes=20 =20 public String[] getPrecludedAttributes()=20 =20 Returns the list of precluded attributes for an entry controlled by=20 this content rule.=20 =20 =20 2.11.5 getRequiredAttributes=20 =20 public String[] getRequiredAttributes()=20 =20 Returns the list of additional required attributes for an entry=20 controlled by this content rule.=20 =20 =20 2.12 public class LDAPDITStructureRuleSchema=20 extends LDAPSchemaElement=20 =20 The LDAPDITStructureRuleSchema class represents the definition of a=20 DIT Structure Rule. It is used to discover or modify which object=20 classes a particular object class may be subordinate to in the DIT.=20 See [ATTR] for a description of DIT structure rule representation in=20 LDAP.=20 =20 2.12.1 Constructors=20 =20 public LDAPDITStructureRuleSchema(String[] names,=20 int ruleID,=20 String description,=20 boolean obsolete,=20 String nameForm,=20 String[] superiorIDs)=20 =20 Constructs a DIT structure rule for adding to or deleting from the=20 schema. [LDAPPROTO] defines which parameters are optional (may be=20 null).=20 =20 =20 public LDAPDITStructureRuleSchema(String raw)=20 =20 Constructs a DIT structure rule from an encoding=20 using the dITStructureRules syntax [ATTR].=20 =20 Parameters are:=20 =20 names Name(s) of the structure rule.=20 =20 Expires December 6, 2004 [Page 63]=20 JAVA LDAP API April 2004=20 =20 =20 =20 ruleID Unique identifier of the structure rule. NOTE:=20 this is an integer, not an OID. Structure=20 rules aren't identified by OID.=20 =20 description Optional description of the structure rule.=20 =20 obsolete true if the structure rule is obsolete. =20 =20 nameForm Either the OID or the name of a name form.=20 This is used to indirectly refer to the object=20 class that this structure rule applies to.=20 =20 superiorIDs List of superior structure rules - specified=20 by their integer ID, or null if none. The=20 object class specified by this structure rule=20 (via the nameForm parameter) may only be=20 subordinate in the DIT to object classes of=20 those represented by the structure rules here=20 .=20 =20 raw A DIT structure rule encoded using the=20 dITStructureRules syntax [ATTR].=20 =20 2.12.2 getNameForm=20 =20 public String getNameForm()=20 =20 Returns the NameForm that this structure rule controls. You can get=20 the actual object class that this structure rule controls by calling=20 getNameForm(ditStructRule.getNameForm()).getObjectClass().=20 =20 =20 2.12.3 getRuleID=20 =20 public int getRuleID()=20 =20 Returns the rule ID for this structure rule. Note that this returns=20 an integer rather than an OID. Objects of this class do not have an=20 OID, thus getID will return null.=20 =20 =20 2.12.4 getSuperiors=20 =20 public String[] getSuperiors()=20 =20 Returns a list of all structure rules that are superior to this=20 structure rule. To resolve to an object class, you need to first=20 resolve the superior id to another structure rule, then call=20 getNameForm().getObjectClass() on that structure rule.=20 =20 =20 =20 Expires December 6, 2004 [Page 64]=20 JAVA LDAP API April 2004=20 =20 =20 2.13 public class LDAPDN=20 =20 A utility class used to manipulate a distinguished name (DN).=20 =20 =20 2.13.1 equals=20 =20 public static boolean equals(String dn1, String dn2)=20 =20 Compares the two strings per the distinguishedNameMatch matching rule=20 [ATTR]. An API implementation MUST use caseIgnoreMatch equality=20 matching for the attributes listed in section 2 of [ATTR].=20 IllegalArgumentException is thrown if one or both DNs are invalid.=20 UnsupportedOperationException is thrown if the API implementation is=20 not able to determine if the DNs match or not.=20 =20 Parameters are:=20 =20 dn1 String form of first DN to compare.=20 =20 dn2 String form of second DN to compare.=20 =20 =20 2.13.2 escapeRDN=20 =20 public static String escapeRDN(String rdn)=20 =20 Returns the RDN after escaping the characters requiring escaping=20 [DN]. For example, for the rdn "cn=3DExample, Inc", "cn=3DExample\, In= c"=20 is returned.=20 =20 Parameters are:=20 =20 rdn The RDN to escape.=20 =20 =20 2.13.3 explodeDN=20 =20 public static String[] explodeDN(String dn,=20 boolean noTypes)=20 =20 Returns the individual components of a distinguished name (DN).=20 =20 Parameters are:=20 =20 dn Distinguished name, e.g. "cn=3DBabs=20 Jensen,ou=3DAccounting,dc=3Dexample,dc=3Dcom"=20 =20 noTypes If true, returns only the values of the=20 components, and not the names, e.g. "Babs=20 Jensen", "Accounting", "Example", "com" - instead=20 =20 Expires December 6, 2004 [Page 65]=20 JAVA LDAP API April 2004=20 =20 =20 of "cn=3DBabs Jensen","ou=3DAccounting","dc=3DExamp= le",=20 and "dc=3Dcom".=20 =20 =20 2.13.4 explodeRDN=20 =20 public static String[] explodeRDN(String rdn,=20 boolean noTypes)=20 =20 Returns the individual components of a relative distinguished name=20 (RDN).=20 =20 Parameters are:=20 =20 rdn Relative distinguished name, i.e. the left-most=20 component of a distinguished name.=20 =20 noTypes If true, returns only the values of the=20 components, and not the names.=20 =20 2.13.5 isValid=20 =20 public static boolean isValid(String dn)=20 =20 Returns true if the string conforms to distinguished name syntax=20 (section 3 of [DN], or if the string conforms to section 4 of [DN].=20 =20 Parameters are:=20 =20 dn String to evaluate for distinguished name syntax.=20 =20 =20 2.13.6 normalize=20 =20 public static String normalize(String dn)=20 =20 Returns the DN normalized by removal of non-significant space=20 characters as per RFC 2253, section 4 [DN].=20 =20 Parameters are:=20 =20 dn The DN to normalize.=20 =20 =20 2.13.7 unescapeRDN=20 =20 public static String unescapeRDN(String rdn)=20 =20 Returns the RDN after unescaping the characters requiring escaping=20 [DN]. For example, for the rdn "cn=3DExample\, Inc", "cn=3DExample, In= c"=20 is returned. IllegalArgumentException is thrown if the RDN cannot be=20 parsed.=20 =20 Expires December 6, 2004 [Page 66]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Parameters are:=20 =20 rdn The RDN to unescape.=20 =20 =20 2.14 public class LDAPEntry=20 implements Serializable, Comparable=20 =20 An LDAPEntry represents a single entry in a directory, consisting of=20 a distinguished name (DN) and zero or more attributes. An instance of=20 LDAPEntry is created in order to add an entry to a Directory, and=20 instances are returned on a search by either enumerating an=20 LDAPSearchResults, or calling LDAPSearchResult.getEntry.=20 =20 =20 2.14.1 Constructors=20 =20 public LDAPEntry()=20 =20 Constructs an empty entry.=20 =20 public LDAPEntry(String dn)=20 =20 Constructs a new entry with the specified distinguished name and with=20 an empty attribute set.=20 =20 =20 public LDAPEntry(String dn,=20 LDAPAttributeSet attrs)=20 =20 Constructs a new entry with the specified distinguished name and set=20 of attributes.=20 =20 Parameters are:=20 =20 dn The distinguished name of the new entry. The=20 value is not validated. An invalid distinguished=20 name will cause adding of the entry to a=20 directory to fail.=20 =20 attrs The initial set of attributes assigned to the=20 entry.=20 =20 =20 2.14.2 compareTo=20 =20 public int compareTo(Object obj)=20 =20 Compares this object with the specified object for order. Ordering is=20 determined by comparing normalized DN values (see LDAPEntry.getDN()=20 2.14.5 and LDAPDN.normalize() 2.13.6) using the compareTo() method of=20 =20 Expires December 6, 2004 [Page 67]=20 JAVA LDAP API April 2004=20 =20 =20 the String class. Returns a negative integer, zero, or a positive=20 integer as this object is less than, equal to, or greater than the=20 specified object.=20 =20 Parameters are:=20 =20 obj The object to be compared to this object.=20 =20 =20 2.14.3 getAttribute=20 =20 public LDAPAttribute getAttribute(String attrName)=20 =20 Returns a copy of the attribute matching the specified attrName or=20 null if none.=20 =20 Parameters are:=20 =20 attrName The name of the attribute. See 2.3.3 for the=20 syntax and semantics relevant to this parameter.=20 =20 =20 2.14.4 getAttributeSet=20 =20 public LDAPAttributeSet getAttributeSet()=20 =20 Returns a copy of the attribute set of the entry. Copies of all base=20 and option variants of all attributes are returned. The=20 LDAPAttributeSet returned is empty if there are no attributes in the=20 entry.=20 =20 =20 public LDAPAttributeSet getAttributeSet(String options)=20 =20 Returns an attribute set from the entry, consisting of copies of only=20 those attributes matching the specified options(s). "option" may be,=20 for example, "lang-ja", "binary", or "lang-ja;phonetic". If more than=20 one option is specified, separated with a semicolon, only those=20 attributes with all of the named options will be returned. The=20 LDAPAttributeSet returned may be empty if there are no matching=20 attributes in the entry.=20 =20 Parameters are:=20 =20 option One or more option specification(s), separated=20 with semicolons. "lang-ja" and=20 "lang-en;phonetic" are valid option=20 specifications.=20 =20 =20 2.14.5 getDN=20 =20 =20 Expires December 6, 2004 [Page 68]=20 JAVA LDAP API April 2004=20 =20 =20 public String getDN()=20 =20 Returns the distinguished name of the entry.=20 =20 =20 2.15 public class LDAPException=20 extends Exception=20 =20 Thrown to indicate an error has occurred. An LDAPException typically=20 results from errors reported by the directory server. Errors not=20 reported by the directory server (such as network errors, or invalid=20 usage of the API) are thrown as LDAPLocalException objects (see also=20 2.18 and 2.26).=20 =20 The=20 getLDAPResultCode() method returns the specific LDAP result code.=20 =20 =20 2.15.1 Constructors=20 =20 public LDAPException()=20 =20 Constructs a default exception with no specific error information.=20 =20 =20 public LDAPException(String message,=20 int resultCode,=20 String serverMessage)=20 =20 Constructs an exception with a string describing the error, a result=20 code, and optionally a message from the server.=20 =20 public LDAPException(String message,=20 int resultCode,=20 String serverMessage,=20 Throwable rootException)=20 =20 Constructs an exception with a string describing the error, a result=20 code, an optional message from the server, and an embedded root=20 exception as additional information.=20 =20 public LDAPException(String message,=20 int resultCode,=20 String serverMessage,=20 String matchedDN)=20 =20 Constructs an exception with a string describing the error, a result=20 code, an optional message from the server, and the maximal subset of=20 a specified DN which could be matched by the server on a search=20 operation.=20 =20 =20 =20 Expires December 6, 2004 [Page 69]=20 JAVA LDAP API April 2004=20 =20 =20 Parameters are:=20 =20 message The descriptive error string or null if none=20 =20 resultCode The result code returned=20 =20 serverMessage Error message specifying additional information=20 from the server or null if none=20 =20 matchedDN The DN of the most immediate ancestor of a=20 specified search DN which could be found by the=20 server on a search operation or null if none=20 =20 rootException An exception which caused the failureor null if=20 none=20 =20 =20 2.15.2 getCause=20 =20 public Throwable getCause()=20 =20 Returns the lower level Exception which caused the failure, or null=20 if none. For example, an IOException with additional information may=20 be returned on a CONNECT_ERROR failure. =20 =20 =20 2.15.3 getLDAPErrorMessage=20 =20 public String getLDAPErrorMessage()=20 =20 Returns the error message returned by the server, if this message is=20 available (that is, if this message was set). If the message was not=20 set, this method=20 returns null.=20 =20 2.15.4 getResponse=20 =20 public LDAPMessage getResponse()=20 =20 Returns the LDAPMessage of a response received as a result of an LDAP=20 Intermediate Response message, or from a response received with an=20 unknown LDAP Message Type. If this exception does not have the result=20 code of INTERMEDIATE_RESPONSE or UNKNOWN_TYPE, this method returns=20 null.=20 =20 =20 2.15.5 getMatchedDN=20 =20 public String getMatchedDN()=20 =20 =20 Expires December 6, 2004 [Page 70]=20 JAVA LDAP API April 2004=20 =20 =20 Returns the matchedDN value provided by the server in the response=20 which generated this exception (it may be empty). If the exception is=20 not due to a server response, null is returned.=20 =20 =20 2.15.6 getResultCode=20 =20 public int getResultCode()=20 =20 Returns the result code from the exception. The codes are defined as=20 public final static int members of this class. If the exception is a=20 result of error information returned from a directory operation, the=20 code will be one of those defined in [LDAPPROTO]. Otherwise, if the=20 exception was generated by the API implementation, a local error code=20 is returned (see "Result codes" at 2.15.9) and the exception class is=20 an instance of LDAPLocalException, see 2.18.=20 =20 =20 =20 2.15.7 resultCodeToString=20 =20 public String resultCodeToString()=20 =20 Returns a String representing the result code in the default Locale.=20 =20 =20 public static String resultCodeToString( int code )=20 =20 Returns a String representing the specified result code in the=20 default Locale, or null if there is no such code known to the API.=20 =20 =20 public String resultCodeToString( Locale locale )=20 =20 Returns a String representing the result code in the specified=20 Locale, or null if a String representation is not available for the=20 requested Locale.=20 =20 =20 public static String resultCodeToString( int code, Locale locale )=20 =20 Returns a String representing the specified result code in the=20 specified Locale, or null if there is no such code or if a String=20 representation is not available for the requested Locale.=20 =20 =20 Parameters are:=20 =20 code One of the result codes listed in "Result codes"=20 below.=20 =20 locale A Locale in which to render the String.=20 =20 Expires December 6, 2004 [Page 71]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 2.15.8 toString=20 =20 public String toString()=20 =20 Overrides the default toString implementation. It expands all the=20 nested exceptions.=20 =20 =20 2.15.9 Result codes=20 =20 See [LDAPPROTO] for a discussion of the meanings and values of the=20 codes. The corresponding ASN.1 name from [LDAPPROTO] is provided in=20 parentheses. Applications should not use the result code to=20 distinguish between server exceptions and local exceptions, but=20 instead should use instanceof LDAPLocalException (see 2.18). All of=20 the following are constants of LDAPException.=20 =20 ADMIN_LIMIT_EXCEEDED (adminLimitExceeded)=20 AFFECTS_MULTIPLE_DSAS (affectsMultipleDSAs)=20 ALIAS_DEREFERENCING_PROBLEM (aliasDereferencingProblem)=20 ALIAS_PROBLEM (aliasProblem)=20 ATTRIBUTE_OR_VALUE_EXISTS (attributeOrValueExists)=20 AUTH_METHOD_NOT_SUPPORTED (authMethodNotSupported)=20 BUSY (busy)=20 COMPARE_FALSE (compareFalse)=20 COMPARE_TRUE (compareTrue)=20 CONFIDENTIALITY_REQUIRED (confidentialityRequired)=20 CONSTRAINT_VIOLATION (constraintViolation)=20 ENTRY_ALREADY_EXISTS (entryAlreadyExists)=20 INAPPROPRIATE_AUTHENTICATION (inappropriateAuthentication)=20 INAPPROPRIATE_MATCHING (inappropriateMatching)=20 INSUFFICIENT_ACCESS_RIGHTS (insufficientAccessRights)=20 INVALID_ATTRIBUTE_SYNTAX (invalidAttributeSyntax)=20 INVALID_CREDENTIALS (invalidCredentials)=20 INVALID_DN_SYNTAX (invalidDNSyntax)=20 IS_LEAF (isLeaf)=20 LOOP_DETECT (loopDetect)=20 NAMING_VIOLATION (namingViolation)=20 NO_SUCH_ATTRIBUTE (noSuchAttribute)=20 NO_SUCH_OBJECT (noSuchObject)=20 NOT_ALLOWED_ON_NONLEAF (notAllowedOnNonLeaf)=20 NOT_ALLOWED_ON_RDN (notAllowedOnRDN)=20 OBJECT_CLASS_MODS_PROHIBITED (objectClassModsProhibited)=20 OBJECT_CLASS_VIOLATION (objectClassViolation)=20 OPERATIONS_ERROR (operationsError)=20 OTHER (other)=20 PROTOCOL_ERROR (protocolError)=20 REFERRAL (referral)=20 SASL_BIND_IN_PROGRESS (saslBindInProgress)=20 SIZE_LIMIT_EXCEEDED (sizeLimitExceeded)=20 =20 Expires December 6, 2004 [Page 72]=20 JAVA LDAP API April 2004=20 =20 =20 STRONG_AUTH_REQUIRED (strongAuthRequired)=20 SUCCESS (success)=20 TIME_LIMIT_EXCEEDED (timeLimitExceeded)=20 UNAVAILABLE (unavailable)=20 UNAVAILABLE_CRITICAL_EXTENSION (unavailableCriticalExtension)=20 UNDEFINED_ATTRIBUTE_TYPE (undefinedAttributeType)=20 UNWILLING_TO_PERFORM (unwillingToPerform)=20 =20 Local errors, resulting from actions other than an operation on a=20 server, are among the following:=20 =20 AMBIGUOUS_RESPONSE (0x65)=20 AUTH_UNKNOWN (0x56)=20 CLIENT_LOOP (0x60)=20 CONNECT_ERROR (0x5b)=20 CONTROL_NOT_FOUND (0x5d)=20 DECODING_ERROR (0x54)=20 ENCODING_ERROR (0x53)=20 FILTER_ERROR (0x57)=20 INTERMEDIATE_RESPONSE (0x71)=20 INVALID_RESPONSE (0x64)=20 LDAP_NOT_SUPPORTED (0x5c)=20 LDAP_TIMEOUT (0x55)=20 LOCAL_ERROR (0x52)=20 MORE_RESULTS_TO_RETURN (0x5f)=20 NO_MEMORY (0x5a)=20 NO_RESULTS_RETURNED (0x5e)=20 REFERRAL_LIMIT_EXCEEDED (0x61)=20 SERVER_DOWN (0x51)=20 TLS_NOT_SUPPORTED (0x70)=20 UNKNOWN_TYPE (072)=20 USER_CANCELLED (0x58)=20 =20 =20 2.16 public class LDAPExtendedOperation=20 implements Cloneable, Serializable=20 =20 An LDAPExtendedOperation encapsulates an OID which uniquely=20 identifies a particular extended operation, known to a particular=20 server, and the data associated with the operation.=20 =20 =20 2.16.1 Constructors=20 =20 public LDAPExtendedOperation(String oid,=20 byte[] value)=20 =20 Constructs a new object with the specified OID and data.=20 =20 Parameters are:=20 =20 oid The OID of the operation.=20 =20 Expires December 6, 2004 [Page 73]=20 JAVA LDAP API April 2004=20 =20 =20 =20 value The BER-encoded operation-specific data of the=20 operation. The API implementation does not=20 interpret or convert the value.=20 =20 =20 2.16.2 getID=20 =20 public String getID()=20 =20 Returns the OID of the operation.=20 =20 =20 2.16.3 getValue=20 =20 public byte[] getValue()=20 =20 Returns the operation-specific data (not a copy, a reference).=20 =20 =20 2.16.4 setValue=20 =20 protected void setValue(byte[] value)=20 =20 Sets the operation-specific data of the object. This method is for=20 use by extensions of LDAPExtendedOperation.=20 =20 Parameters are:=20 =20 value The BER-encoded operation-specific data of the=20 operation to be assigned to the object (as a=20 reference) The API implementation does not=20 interpret or convert the value.=20 =20 =20 2.17 public class LDAPExtendedResponse=20 extends LDAPResponse implements Serializable=20 An LDAPExtendedResponse object encapsulates a server response to an=20 extended operation request. Objects extending this class can be=20 registered by OID (see 2.17.3), and are instantiated by the API=20 implementation on receipt of an extended response with the given OID.=20 =20 2.17.1 getID=20 =20 public String getID()=20 =20 Returns the OID of the response.=20 =20 =20 2.17.2 getValue=20 =20 public byte[] getValue()=20 =20 Expires December 6, 2004 [Page 74]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Returns the raw bytes of the value part of the response.=20 =20 =20 2.17.3 register =20 =20 public static void register(String oid, Class extendedResponseClass)=20 =20 Registers an application class to be instantiated on receipt of an=20 extended response with the given oid. Any previous registration for=20 the oid is overridden. The extendedResponseClass object MUST be an=20 extension of LDAPExtendedResponse.=20 =20 Parameters are:=20 =20 oid The OID of the extended response=20 =20 extendedResponseClass A class which can instantiate an=20 LDAPExtendedResponse. The class must=20 implement the following constructor=20 signature:=20 =20 public (String oid, byte[] value)=20 =20 oid The OID of the extended response=20 =20 value Response-specific data; the API=20 implementation does not interpret or=20 convert the value=20 =20 =20 2.18 public class LDAPLocalException=20 extends LDAPException=20 =20 This exception, derived from LDAPException, is thrown to report an=20 LDAP error that does not originate from the server, and is not=20 covered by other Exception classes such as IllegalArgumentException. =20 For example, LDAPLocalException is thrown when network errors occur,=20 when calling LDAPConnection.StartTLS() and operations are outstanding=20 on the connection, or when a REFERRAL_LIMIT_EXCEEDED error occurs=20 when following referrals.=20 =20 =20 2.18.1 Constructors=20 =20 public LDAPLocalException()=20 =20 Constructs a default exception with no specific error information.=20 =20 =20 public LDAPLocalException(String message,=20 int resultCode)=20 =20 Expires December 6, 2004 [Page 75]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Constructs an exception with a string describing the error and a=20 result code.=20 =20 public LDAPException(String message,=20 int resultCode,=20 Throwable rootException)=20 =20 Constructs an exception with a result code, a string describing the=20 error, and an embedded root exception as additional information.=20 =20 =20 Parameters are:=20 =20 message The additional error information=20 =20 resultCode The result code returned=20 =20 rootException An exception which caused the failure, if any=20 =20 =20 2.19 public class LDAPMatchingRuleSchema=20 extends LDAPSchemaElement=20 =20 The LDAPMatchingRuleSchema class represents the definition of a=20 matching rule. It is used to query matching rule syntax, and to add=20 or delete a matching rule definition in a Directory=92s subschema. See= =20 [ATTR] for a description of matching rule representation in LDAP.=20 =20 =20 2.19.1 Constructors=20 =20 public LDAPMatchingRuleSchema(String[] names,=20 String oid,=20 String description,=20 String[] attributes,=20 boolean obsolete,=20 String syntaxString)=20 =20 Constructs a matching rule definition for adding to or deleting from=20 a Directory=92s subschema. [LDAPPROTO] defines which parameters are=20 optional (may be null).=20 =20 =20 public LDAPMatchingRuleSchema(String rawMatchingRule,=20 String rawMatchingRuleUse)=20 =20 Constructs a matching rule definition from values encoded=20 using the matchingRule syntax and the matchingRuleUse syntax [ATTR]=20 for the same rule.=20 =20 =20 =20 Expires December 6, 2004 [Page 76]=20 JAVA LDAP API April 2004=20 =20 =20 Parameters are:=20 =20 name Name of the attribute.=20 =20 oid OID of the.=20 =20 description Optional description of the attribute.=20 =20 attributes OIDs of attributes to which the rule applies,=20 or null if none.=20 =20 obsolete true if this matching rule is obsolete.=20 =20 syntaxString OID of the syntax that this matching rule is=20 valid for.=20 =20 rawMatchingRule A matching rule definition encoded using the=20 matchingRule syntax [ATTR].=20 =20 =20 rawMatchingRuleUse A matching rule use definition encoded using=20 the matchingRuleUse syntax [ATTR], or null if=20 none.=20 =20 =20 2.19.2 getAttributes=20 =20 public String[] getAttributes()=20 =20 Returns the OIDs of the attributes to which this rule applies.=20 =20 =20 2.19.3 getSyntaxString=20 =20 public String getSyntaxString()=20 =20 Returns the OID of the syntax that this matching rule is valid for.=20 =20 =20 2.20 public class LDAPMatchingRuleUseSchema=20 extends LDAPSchemaElement=20 =20 The LDAPMatchingRuleUseSchema class represents the definition of a=20 matching rule use. It is used to discover or modify which attributes=20 are suitable for use with an extensible matching rule. It contains=20 the name and OID of a matching rule, and a list of attributes that it=20 applies to. See [ATTR] for a description of matching rule use=20 representation in LDAP.=20 =20 2.20.1 Constructors=20 =20 public LDAPMatchingRuleUseSchema(String[] names,=20 =20 Expires December 6, 2004 [Page 77]=20 JAVA LDAP API April 2004=20 =20 =20 String oid,=20 String description,=20 boolean obsolete,=20 String[] attributes)=20 =20 Constructs a matching rule use definition for adding to or deleting=20 from the schema. [LDAPPROTO] defines which parameters are optional=20 (may be null).=20 =20 =20 public LDAPMatchingRuleUseSchema(String raw)=20 =20 Constructs a matching rule use definition from an encoding=20 using the matchingRuleUse syntax [ATTR].=20 =20 Parameters are:=20 =20 names Name(s) of the matching rule.=20 =20 oid OID of the matching rule.=20 =20 description Optional description of the matching rule use.=20 =20 obsolete true if the matching rule use is obsolete. =20 =20 attributes List of attributes that this matching rule=20 applies to. These values may be either the=20 names or OIDs of the attributes=20 =20 raw A matching rule use definition using the=20 matchingRuleUse syntax [ATTR].=20 =20 2.20.2 getAttributes=20 =20 public String[] getAttributes()=20 =20 Returns an array of all the attributes that this matching rule=20 applies to. =20 =20 =20 2.21 public class LDAPMessage=20 implements Serializable=20 =20 Base class for asynchronous LDAP request and response messages and=20 for LDAPExtendedResponse.=20 =20 =20 2.21.1 getControls=20 =20 public LDAPControl[] getControls()=20 =20 Returns any controls in the message.=20 =20 Expires December 6, 2004 [Page 78]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 2.21.2 getMessageID=20 =20 public int getMessageID()=20 =20 Returns the message ID. Message IDs are defined in section 4.1.1.1 of=20 [LDAPPROTO].=20 =20 =20 2.21.3 getType=20 =20 public int getType()=20 =20 Returns the LDAP operation type of the message. The type is one of=20 the following:=20 =20 BIND_REQUEST (0x0)=20 BIND_RESPONSE (0x1)=20 UNBIND_REQUEST (0x2)=20 SEARCH_REQUEST (0x3)=20 SEARCH_RESPONSE (0x4)=20 SEARCH_RESULT (0x5)=20 MODIFY_REQUEST (0x6)=20 MODIFY_RESPONSE (0x7)=20 ADD_REQUEST (0x8)=20 ADD_RESPONSE (0x9)=20 DEL_REQUEST (0xa)=20 DEL_RESPONSE (0xb)=20 MODIFY_RDN_REQUEST (0xc)=20 MODIFY_RDN_RESPONSE (0xd)=20 COMPARE_REQUEST (0xe)=20 COMPARE_RESPONSE (0xf)=20 ABANDON_REQUEST (0x10)=20 SEARCH_RESULT_REFERENCE (0x13)=20 EXTENDED_REQUEST (0x17)=20 EXTENDED_RESPONSE (0x18)=20 INTERMEDIATE_RESPONSE (0x19)=20 =20 Each of the above types is a constant of LDAPMessage.=20 =20 =20 2.22 public class LDAPMessageQueue implements Serializable=20 =20 Represents the message queue associated with a particular=20 asynchronous LDAP operation or operations.=20 2.22.1 getMessageIDs=20 =20 public int[] getMessageIDs()=20 =20 Returns the message IDs for all outstanding requests, i.e. requests=20 for which a response has not been received from the server or which=20 =20 Expires December 6, 2004 [Page 79]=20 JAVA LDAP API April 2004=20 =20 =20 still have messages to be retrieved with getResponse. The last ID in=20 the array is the messageID of the latest submitted request. Message=20 IDs are defined in section 4.1.1.1 of [LDAPPROTO].=20 =20 =20 2.22.2 getResponse=20 =20 public LDAPMessage getResponse() throws LDAPException=20 =20 Blocks until a response is available, or until all operations=20 associated with the object have completed or been canceled, and=20 returns the response.=20 =20 public LDAPMessage getResponse(int msgid) throws LDAPException=20 =20 Blocks until a response is available for a particular message ID, or=20 until all operations associated with the message ID have completed or=20 been canceled, and returns the response. If there is no outstanding=20 operation for the message ID (or if msgid is zero or a negative=20 number), IllegalArgumentException is thrown.=20 =20 Parameters are:=20 =20 msgid A particular message ID to query for responses=20 available.=20 =20 2.22.3 isComplete=20 =20 =20 public boolean isComplete(int msgid)=20 =20 Reports true if all results for a particular message ID have been=20 received by the API implementation. For requests that return multiple=20 results (for example search) there may still be messages queued in=20 the object for retrieval by the application. If there is no=20 outstanding operation for the message ID (or if msgid is zero or a=20 negative number), IllegalArgumentException is thrown.=20 =20 =20 Parameters are:=20 =20 msgid A particular message ID to query for completion.=20 2.22.4 isResponseReceived=20 =20 public boolean isResponseReceived()=20 =20 Reports true if any response has been received from the server and=20 not yet retrieved with getResponse. If getResponse has been used to=20 retrieve all messages received to this point, then isResponseReceived=20 returns false.=20 =20 =20 =20 Expires December 6, 2004 [Page 80]=20 JAVA LDAP API April 2004=20 =20 =20 public boolean isResponseReceived(int msgid)=20 =20 Reports true if a response has been received from the server for a=20 particular message ID but not retrieved with getResponse. If there is=20 no outstanding operation for the message ID (or if msgid is zero or a=20 negative number), IllegalArgumentException is thrown.=20 =20 =20 Parameters are:=20 =20 msgid A particular message to query for responses=20 available. =20 2.22.5 merge=20 =20 public void merge(LDAPMessageQueue queue2)=20 =20 Merges two queues. Moves/appends the content from the specified queue=20 to this one. After the operation, queue2.getMessageIDs() returns an=20 empty array and its outstanding responses have been removed (and=20 appended to this queue).=20 =20 =20 2.23 public class LDAPModification=20 implements Serializable=20 =20 Encapsulates a single change specification for an LDAPAttribute.=20 =20 =20 2.23.1 Constructors=20 =20 public LDAPModification(int op,=20 LDAPAttribute attr)=20 =20 Specifies a modification to be made to an attribute.=20 =20 =20 Parameters are:=20 =20 op The type of modification to make, which can be=20 one of the following:=20 =20 ADD The value should be added to=20 the attribute, creating the=20 attribute if necessary.=20 =20 DELETE The value should be removed=20 from the attribute, removing=20 the entire attribute if no=20 values are listed, or if all=20 current values of the attribute=20 are listed for deletion.=20 =20 =20 Expires December 6, 2004 [Page 81]=20 JAVA LDAP API April 2004=20 =20 =20 REPLACE The value should replace all=20 existing values of the=20 attribute with the new values=20 listed, creating the attribute=20 if it did not already exist. A=20 replace with no value will=20 delete the entire attribute if=20 it exists, and is ignored if=20 the attribute does not exist.=20 =20 attr The attribute (possibly with values) to be=20 modified.=20 =20 =20 2.23.2 getAttribute=20 =20 public LDAPAttribute getAttribute()=20 =20 Returns the attribute (possibly with values) to be modified.=20 =20 =20 2.23.3 getOp=20 =20 public int getOp()=20 =20 Returns the type of modification specified by this object.=20 =20 =20 2.23.4 Constants of LDAPModification=20 =20 ADD (0) The value should be added to the attribute,=20 creating the attribute if necessary.=20 =20 DELETE (1) The value should be removed from the attribute,=20 removing the entire attribute if no values are=20 listed, or if all current values of the attribute=20 are listed for deletion.=20 =20 REPLACE (2) The value should replace all existing values of=20 the attribute with the new values listed,=20 creating the attribute if it did not already=20 exist. A replace with no value will delete the=20 entire attribute if it exists, and is ignored if=20 the attribute does not exist.=20 =20 =20 2.24 public class LDAPNameFormSchema=20 extends LDAPSchemaElement=20 =20 The LDAPNameFormSchema class represents the definition of a Name=20 Form. It is used to discover or modify the allowed naming attributes=20 =20 Expires December 6, 2004 [Page 82]=20 JAVA LDAP API April 2004=20 =20 =20 for a particular object class. See [ATTR] for a description of name=20 form representation in LDAP.=20 =20 2.24.1 Constructors=20 =20 public LDAPNameFormSchema(String[] names,=20 String oid,=20 String description,=20 boolean obsolete,=20 String objectClass,=20 String[] required,=20 String[] optional)=20 =20 Constructs a name form for adding to or deleting from the schema.=20 [LDAPPROTO] defines which parameters are optional (may be null).=20 =20 =20 public LDAPNameFormSchema(String raw)=20 =20 Constructs a DIT content rule from an encoding=20 using the nameForms syntax [ATTR].=20 =20 Parameters are:=20 =20 names Name(s) of the name form.=20 =20 oid OID of the name form.=20 =20 description Optional description of the name form.=20 =20 obsolete true if the name form is obsolete. =20 =20 objectClass The object to which this name form applies.=20 This may either be specified by name or OID.=20 =20 required A list of the attributes that must be present=20 in the RDN of an entry that this name form=20 controls. These may either be specified by=20 name or OID.=20 =20 optional A list of the attributes that may be present=20 in the RDN of an entry that this name form=20 controls. These may either be specified by=20 name or OID.=20 =20 raw A name form definition encoded using the=20 nameForms syntax [ATTR].=20 =20 =20 2.24.2 getObjectClass=20 =20 =20 Expires December 6, 2004 [Page 83]=20 JAVA LDAP API April 2004=20 =20 =20 public String getObjectClass()=20 =20 Returns the name of the object class that this name form applies to.=20 =20 =20 2.24.3 getOptionalNamingAttributes=20 =20 public String[] getOptionalNamingAttributes()=20 =20 Returns the list of optional naming attributes for an entry=20 controlled by this content rule.=20 =20 =20 2.24.4 getRequiredNamingAttributes=20 =20 public String[]getRequiredNamingAttributes()=20 =20 Returns the list of required naming attributes for an entry=20 controlled by this name form.=20 =20 =20 2.25 public class LDAPObjectClassSchema=20 extends LDAPSchemaElement=20 =20 The LDAPObjectClassSchema class represents the definition of an=20 object class. It is used to query the syntax of an object class, and=20 to add or delete an object class definition in a Directory=92s=20 subschema. See [ATTR] for a description of object class=20 representation in LDAP.=20 =20 =20 2.25.1 Constructors=20 =20 public LDAPObjectClassSchema(String[] names,=20 String oid,=20 String[] superiors,=20 String description,=20 String[] required,=20 String[] optional,=20 int type,=20 boolean obsolete)=20 =20 Constructs an object class definition for adding to or deleting from=20 a Directory=92s subschema. [LDAPPROTO] defines which parameters are=20 optional (i.e., which may be null).=20 =20 =20 public LDAPObjectClassSchema(String raw)=20 =20 Constructs an object class definition from an encoding=20 using the ObjectClassDescription syntax [ATTR].=20 =20 =20 Expires December 6, 2004 [Page 84]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Parameters are:=20 =20 names Name(s) of the object class.=20 =20 oid OID of the object class.=20 =20 description Optional description of the object class.=20 =20 superiors The object classes this one derives from.=20 =20 required A list of attributes required for an entry with=20 this object class.=20 =20 optional A list of attributes acceptable but not required=20 for an entry with this object class.=20 =20 type One of ABSTRACT, AUXILIARY, or STRUCTURAL (See=20 2.25.6). =20 obsolete true if this object class is obsolete.=20 =20 raw An object class definition encoded using the=20 ObjectClassDescription syntax [ATTR].=20 =20 =20 2.25.2 getOptionalAttributes=20 =20 public String[] getOptionalAttributes()=20 =20 Returns a list of attributes acceptable but not required of an entry=20 with this object class.=20 =20 =20 2.25.3 getRequiredAttributes=20 =20 public String[] getRequiredAttributes()=20 =20 Returns a list of attributes required of an entry with this object=20 class.=20 =20 =20 2.25.4 getSuperiors=20 =20 public String[] getSuperiors()=20 =20 Returns the object classes which this one derives from.=20 =20 =20 2.25.5 getType=20 =20 public int getType()=20 =20 =20 Expires December 6, 2004 [Page 85]=20 JAVA LDAP API April 2004=20 =20 =20 Returns one of ABSTRACT, AUXILIARY, or STRUCTURAL (See 2.25.6). =20 =20 2.25.6 Constants of LDAPObjectClassSchema=20 =20 ABSTRACT (0) identifies an abstract schema class=20 STRUCTURAL (1) identifies a structural schema class=20 AUXILIARY (2) identifies an auxiliary schema class=20 =20 =20 2.26 public class LDAPReferralException=20 extends LDAPException=20 =20 This exception, derived from LDAPException, is thrown when a server=20 returns a referral or search reference on a synchronous request and=20 when automatic referral following has not been enabled. The=20 exception may also be thrown when automatic referral following is=20 enabled, but only if there was an error while attempting to follow=20 the referral.=20 =20 2.26.1 Constructors=20 =20 public LDAPReferralException()=20 =20 Constructs a default exception with no specific error information.=20 =20 =20 public LDAPReferralException(String message)=20 =20 Constructs a default exception with a specified string as additional=20 information. This form is used for lower-level errors.=20 =20 =20 public LDAPReferralException(String message,=20 Throwable rootException)=20 =20 Constructs a default exception with a specified string as additional=20 information and an exception that indicates a failure to follow a=20 referral.=20 =20 =20 public LDAPReferralException(String message,=20 int resultCode,=20 String serverMessage)=20 =20 public LDAPReferralException(String message,=20 int resultCode,=20 String serverMessage,=20 Throwable rootException)=20 =20 Parameters are:=20 =20 message The additional error information.=20 =20 Expires December 6, 2004 [Page 86]=20 JAVA LDAP API April 2004=20 =20 =20 =20 resultCode The result code returned=20 =20 serverMessage Error message specifying additional information=20 from the server.=20 =20 rootException An exception which caused referral following to=20 fail=20 =20 =20 2.26.2 getFailedReferral=20 =20 public String getFailedReferral()=20 =20 Gets the referral URL that could not be followed. If multiple URLs=20 are in the list, and none could be followed, the method returns one=20 of them.=20 =20 =20 2.26.3 getReferrals=20 =20 public String[] getReferrals()=20 =20 Gets the list of referral URLs (URLs to other servers) returned by=20 the LDAP server. If the scope field of a referral of type=20 SearchResultReference must be modified in order to follow the=20 referral, the API implementation MUST modify the scope field of the=20 URL before returning the URL to the application.=20 =20 The referral list may include URLs of a type other than LDAP server=20 (i.e. a referral URL other than ldap://something).=20 =20 =20 =20 2.26.4 setFailedReferral=20 =20 public void setFailedReferral(String url)=20 =20 Sets a referral URL that could not be followed.=20 =20 =20 2.27 public interface LDAPReferralHandler=20 =20 Shared ancestor to the two types of referral objects -=20 LDAPBindHandler and LDAPAuthHandler.=20 =20 =20 2.28 public class LDAPResponse=20 extends LDAPMessage=20 =20 =20 Expires December 6, 2004 [Page 87]=20 JAVA LDAP API April 2004=20 =20 =20 Represents the response to a particular asynchronous LDAP operation.=20 LDAPExtendedResponse extends LDAPResponse and is returned on a=20 synchronous extended request.=20 =20 =20 =20 2.28.1 getErrorMessage=20 =20 public String getErrorMessage()=20 =20 Returns any error message in the response.=20 =20 =20 2.28.2 getMatchedDN=20 =20 public String getMatchedDN()=20 =20 Returns the partially matched DN field, if any, in a server response.=20 =20 =20 2.28.3 getReferrals=20 =20 public String[] getReferrals()=20 =20 Returns list of all referral URLs, if any, in a server response.=20 =20 =20 2.28.4 getResultCode=20 =20 public int getResultCode()=20 =20 Returns the result code in a server response, as defined in=20 [LDAPPROTO].=20 =20 =20 =20 =20 2.29 public class LDAPSchema=20 extends LDAPEntry=20 implements Serializable=20 =20 The LDAPSchema class provides methods to parse schema attributes=20 associated with an LDAPEntry. Schema is retrieved from a Directory=20 Server=92s subschema using the fetchSchema method of LDAPConnection=20 (see 2.8.13). =20 =20 2.29.1 Constructors=20 =20 public LDAPSchema(LDAPEntry entry)=20 =20 Constructs an LDAPSchema object from attributes of an LDAPEntry. The=20 object is empty if the entry parameter contains no schema attributes.=20 =20 Expires December 6, 2004 [Page 88]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Parameters are:=20 =20 entry An LDAPEntry containing schema information.=20 =20 =20 2.29.2 getAttributeNames=20 =20 public Enumeration getAttributeNames()=20 =20 Returns an enumeration of attribute names.=20 =20 =20 2.29.3 getAttributeSchema=20 =20 public LDAPAttributeSchema getAttributeSchema( String name )=20 =20 Returns a particular attribute definition, or null if not found.=20 =20 Parameters are:=20 =20 name Name or OID of the attribute for which a=20 definition is to be returned.=20 =20 =20 2.29.4 getAttributeSchemas=20 =20 public Enumeration getAttributeSchemas()=20 =20 Returns an enumeration of attribute definitions.=20 =20 =20 2.29.5 getDITContentRuleNames=20 =20 public Enumeration getDITContentRuleNames()=20 =20 Returns an enumeration of content rule names.=20 =20 =20 2.29.6 getDITContentRuleSchema=20 =20 public =20 LDAPDITContentRuleSchema getDITContentRuleSchema(String name )=20 Returns a particular content rule definition, or null if not found.=20 =20 Parameters are:=20 =20 name Name or OID of the content rule for which a=20 definition is to be returned.=20 =20 =20 =20 Expires December 6, 2004 [Page 89]=20 JAVA LDAP API April 2004=20 =20 =20 2.29.7 getDITContentRuleSchemas=20 =20 public Enumeration getDITContentRuleSchemas()=20 =20 Returns an enumeration of LDAPDITContentRuleSchema objects.=20 =20 =20 2.29.8 getDITStructureRuleNames=20 =20 public Enumeration getDITStructureRuleNames ()=20 =20 Returns an enumeration of structure rule names.=20 =20 =20 2.29.9 getDITStructureRuleSchema=20 =20 public =20 LDAPDITStructureRuleSchema getDITStructureRuleSchema( String name )=20 =20 public LDAPDITStructureRuleSchema getDITStructureRuleSchema( int id )=20 =20 =20 Returns a particular structure rule definition, or null if not found.=20 =20 Parameters are:=20 =20 name Name or OID of the structure rule for which a=20 definition is to be returned.=20 =20 id Identifier of the structure rule for which a=20 definition is to be returned.=20 =20 =20 2.29.10 getDITStructureRuleSchemas=20 =20 public Enumeration getDITStructureRuleSchemas()=20 =20 Returns an enumeration of LDAPDITStructureRuleSchema objects.=20 =20 =20 2.29.11 getMatchingRuleNames=20 =20 public Enumeration getMatchingRuleNames()=20 =20 Returns an enumeration of matching rule names.=20 =20 =20 2.29.12 getMatchingRuleSchema=20 =20 public LDAPMatchingRuleSchema getMatchingRuleSchema( String name )=20 =20 Returns a particular matching rule definition, or null if not found.=20 =20 Expires December 6, 2004 [Page 90]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Parameters are:=20 =20 name Name or OID of the matching rule for which a=20 definition is to be returned.=20 =20 2.29.13 getMatchingRuleSchemas=20 =20 public Enumeration getMatchingRuleSchemas()=20 =20 Returns an enumeration of matching rule definitions.=20 =20 =20 2.29.14 getMatchingRuleUseNames=20 =20 public Enumeration getMatchingRuleUseNames()=20 =20 Returns an enumeration of matching rule use names.=20 =20 =20 2.29.15 getMatchingRuleUseSchema=20 =20 public =20 LDAPMatchingRuleUseSchema getMatchingRuleUseSchema( String name )=20 =20 Returns a particular matching rule use definition, or null if not=20 found.=20 =20 Parameters are:=20 =20 name Name or OID of the matching rule use for which a=20 definition is to be returned.=20 =20 =20 2.29.16 getMatchingRuleUseSchemas=20 =20 public Enumeration getMatchingRuleUseSchemas()=20 =20 Returns an enumeration of LDAPMatchingRuleUseSchema objects.=20 =20 =20 2.29.17 getNameFormNames=20 =20 public Enumeration getNameFormNames ()=20 =20 Returns an enumeration of name form names.=20 =20 =20 2.29.18 getNameFormSchema=20 =20 public LDAPNameFormSchema getNameFormSchema( String name )=20 =20 =20 Expires December 6, 2004 [Page 91]=20 JAVA LDAP API April 2004=20 =20 =20 Returns a particular name form definition, or null if not found.=20 =20 Parameters are:=20 =20 name Name or OID of the name form for which a=20 definition is to be returned.=20 =20 =20 2.29.19 getNameFormSchemas=20 =20 public Enumeration getNameFormSchemas()=20 =20 Returns an enumeration of LDAPNameFormSchema objects.=20 =20 =20 2.29.20 getObjectClassNames=20 =20 public Enumeration getObjectClassNames()=20 =20 Returns an enumeration of object class names.=20 =20 =20 2.29.21 getObjectClassSchema=20 =20 public LDAPObjectClassSchema getObjectClassSchema( String name )=20 =20 Returns a particular object class definition, or null if not found.=20 =20 Parameters are:=20 =20 name Name or OID of the object class for which a=20 definition is to be returned.=20 =20 =20 2.29.22 getObjectClassSchemas=20 =20 public Enumeration getObjectClassSchemas()=20 =20 Returns an enumeration of object class definitions.=20 =20 =20 2.29.23 getSyntaxSchema=20 =20 public LDAPSyntaxSchema getSyntaxSchema( String oid )=20 =20 Returns a particular syntax definition, or null if not found.=20 =20 Parameters are:=20 =20 oid OID of the syntax for which a definition is to be=20 returned.=20 =20 =20 Expires December 6, 2004 [Page 92]=20 JAVA LDAP API April 2004=20 =20 =20 =20 2.29.24 getSyntaxSchemas=20 =20 public Enumeration getSyntaxSchemas()=20 =20 Returns an enumeration of LDAPSyntaxSchema objects.=20 =20 =20 =20 2.30 public abstract class LDAPSchemaElement=20 extends LDAPAttribute implements Serializable=20 =20 The LDAPSchemaElement class is the base class for representing schema=20 elements in LDAP. All classes representing schema elements are=20 read-only and thus do not support the addValue and removeValue=20 methods from LDAPAttribute. This class overrides those methods and=20 throws UnsupportedOperationException if addValue or removeValue is=20 invoked.=20 =20 =20 2.30.1 getDescription=20 =20 public String getDescription()=20 =20 Returns the description of the element. With respect to the protocol- level schema element syntax definition of [ATTR], the value is that=20 of the DESC qualifier.=20 =20 =20 2.30.2 getNames=20 =20 public String[] getNames()=20 =20 Returns the name(s) of the element.=20 =20 =20 2.30.3 getID=20 =20 public String getID()=20 =20 Returns the OID of the element.=20 =20 =20 2.30.4 getQualifier=20 =20 public String[] getQualifier(String name)=20 =20 Returns an array of all values of a qualifier of the element which is=20 not defined in [ATTR]. This method may be used to access the values=20 of vendor-specific qualifiers (which begin with "X-" [ATTR]).=20 =20 Parameters are:=20 =20 Expires December 6, 2004 [Page 93]=20 JAVA LDAP API April 2004=20 =20 =20 =20 name The name of the qualifier, case-sensitive.=20 =20 =20 2.30.5 getQualifierNames=20 =20 public Enumeration getQualifierNames()=20 =20 Returns an enumeration of all qualifiers of the element which are not=20 defined in [ATTR].=20 =20 =20 2.30.6 isObsolete=20 =20 public boolean isObsolete()=20 =20 Returns true if the element has the OBSOLETE qualifier in its LDAP=20 definition [ATTR].=20 =20 =20 2.30.7 setQualifier=20 =20 public void setQualifier(String name, String[] values)=20 =20 Sets the values of a specified optional or experimental qualifier of=20 the element. This method may be used to set the values of vendor- specific qualifiers (which begin with "X-" [ATTR]).=20 =20 Parameters are:=20 =20 name The name of the qualifier, case-sensitive.=20 =20 values The values to set for the qualifier.=20 =20 =20 2.30.8 toString=20 =20 public String toString()=20 =20 Returns a String in a format suitable for directly adding to a=20 Directory (defined in [ATTR], as a value of the particular schema=20 element attribute. See the format definition for each derived class.=20 =20 =20 2.31 public class LDAPSearchConstraints=20 extends LDAPConstraints=20 =20 A set of options to control a search operation. There is always an=20 LDAPSearchConstraints object associated with an LDAPConnection=20 object; it bcan be changed with LDAPConnection.setConstraints, or=20 overridden by passing an LDAPSearchConstraints object to a search=20 operation.=20 =20 Expires December 6, 2004 [Page 94]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 2.31.1 Constructors=20 =20 public LDAPSearchConstraints()=20 =20 Constructs an LDAPSearchConstraints object that specifies the default=20 set of search constraints.=20 =20 =20 public LDAPSearchConstraints(LDAPConstraints cons)=20 =20 Constructs an LDAPSearchConstraints object initialized with values=20 from an existing constraints object (LDAPConstraints or=20 LDAPSearchConstraints).=20 =20 =20 public LDAPSearchConstraints(int msLimit,=20 int serverTimeLimit,=20 int dereference,=20 int maxResults,=20 boolean doReferrals,=20 int batchSize,=20 LDAPReferralHandler handler,=20 int hop_limit)=20 =20 Constructs a new LDAPSearchConstraints object and allows specifying=20 the operational constraints in that object.=20 =20 Parameters are:=20 =20 cons Constraints object to use as template.=20 =20 msLimit Maximum time in milliseconds to wait for results=20 The default of 0 means that there is no maximum=20 time limit. This is an interface-enforced limit.=20 =20 serverTimeLimit Maximum time in seconds that the server should=20 spend returning results. This is a server- enforced limit. The default of 0 means no time=20 limit.=20 =20 dereference Specifies when aliases should be dereferenced.=20 The value MUST be either DEREF_NEVER,=20 DEREF_FINDING, DEREF_SEARCHING, or DEREF_ALWAYS=20 (DEREF_NEVER by default).=20 =20 maxResults Maximum number of search results to return (1000=20 by default).=20 =20 doReferrals Specify true to follow referrals automatically,=20 or false to throw an LDAPReferralException error=20 =20 Expires December 6, 2004 [Page 95]=20 JAVA LDAP API April 2004=20 =20 =20 if the server sends back a referral (false by=20 default). It is ignored for asynchronous=20 operations.=20 =20 batchSize Specify the number of results to block on during=20 enumeration. 0 means to block until all results=20 are in (1 by default). It is ignored for=20 asynchronous operations.=20 =20 handler Custom authentication processor, called when the=20 LDAPConnection needs to authenticate, typically=20 on following a referral. The default of null =20 specifies default authentication processing, i.e.=20 anonymous authentication if doReferrals is true.=20 The object implements either the LDAPBindHandler=20 or the LDAPAuthHandler interface. It is ignored=20 for asynchronous operations.=20 =20 hop_limit Maximum number of referrals to follow in a=20 sequence when attempting to resolve a request,=20 when doing automatic referral following. It is=20 ignored for asynchronous operations. The value is=20 10 by default.=20 =20 =20 2.31.2 getBatchSize=20 =20 public int getBatchSize()=20 =20 Returns the blocking factor for synchronous searches. When retrieving=20 results from the LDAPSearchResults object, a blocking factor of 0=20 indicates that the next() method blocks until all results are=20 received from the server. A value of 1 indicates that next() returns=20 each result when it is received. A value of 2 blocks until 2 results=20 are received from the server or until the final result is received.=20 =20 2.31.3 getDereference=20 =20 public int getDereference()=20 =20 Specifies when aliases should be dereferenced. Returns one of=20 DEREF_NEVER, DEREF_FINDING, DEREF_SEARCHING, or=20 DEREF_ALWAYS.=20 =20 =20 2.31.4 getMaxResults=20 =20 public int getMaxResults()=20 =20 Returns the maximum number of search results to be returned; 0 means=20 no limit.=20 =20 =20 Expires December 6, 2004 [Page 96]=20 JAVA LDAP API April 2004=20 =20 =20 =20 2.31.5 getServerTimeLimit=20 =20 public int getServerTimeLimit()=20 =20 Reports the maximum number of seconds that the server is to wait when=20 returning search results while using this constraint object=20 =20 =20 2.31.6 setBatchSize=20 =20 public void setBatchSize(int batchSize)=20 =20 Sets the blocking factor for synchronous searches. When retrieving=20 results from the LDAPSearchResults object, a blocking factor of 0=20 indicates that the next() method blocks until all results are=20 received from the server. A value of 1 indicates that next() returns=20 each result when it is received. A value of 2 blocks until 2 results=20 are received from the server or until the final result is received.=20 The default is 1.=20 =20 Parameters are:=20 =20 batchSize Blocking size on search enumerations.=20 =20 =20 2.31.7 setDereference=20 =20 public void setDereference(int dereference)=20 =20 Sets a preference indicating whether or not aliases should be=20 dereferenced, and if so, when.=20 =20 Parameters are:=20 =20 dereference Either DEREF_NEVER, DEREF_FINDING,=20 DEREF_SEARCHING, or DEREF_ALWAYS.=20 =20 =20 2.31.8 setMaxResults=20 =20 public void setMaxResults(int maxResults)=20 =20 Sets the maximum number of search results to be returned; 0 means no=20 limit. The default is 1000.=20 =20 Parameters are:=20 =20 maxResults Maximum number of search results to return.=20 =20 =20 =20 Expires December 6, 2004 [Page 97]=20 JAVA LDAP API April 2004=20 =20 =20 2.31.9 setServerTimeLimit=20 =20 public void setServerTimeLimit(int seconds)=20 =20 Sets the maximum number of seconds that the server is to wait when=20 returning search results. The parameter is only recognized on search=20 operations. The default of 0 means no time limt.=20 =20 =20 2.31.10 Constants of LDAPSearchConstraints=20 =20 DEREF_NEVER (0) Aliases are never dereferenced.=20 =20 DEREF_SEARCHING (1) Aliases are dereferenced when searching the=20 entries beneath the starting point of the search=20 (but not when finding the starting entry).=20 =20 DEREF_FINDING (2) Aliases are dereferenced when finding the=20 starting point for the search (but not when=20 searching under that starting entry).=20 =20 DEREF_ALWAYS (3) Aliases are always dereferenced (both when=20 finding the starting point for the search and=20 when searching under that starting entry).=20 =20 =20 =20 2.32 public class LDAPSearchResult=20 extends LDAPMessage=20 =20 An LDAPSearchResult object encapsulates a single asynchronous search=20 result.=20 =20 =20 2.32.1 getEntry=20 =20 public LDAPEntry getEntry()=20 =20 Returns the entry of a server search response.=20 =20 =20 2.33 public class LDAPSearchResultReference=20 extends LDAPMessage=20 =20 An LDAPSearchResultReference object encapsulates a continuation=20 reference from an asynchronous search operation.=20 =20 =20 2.33.1 getReferrals=20 =20 public String[] getReferrals()=20 =20 =20 Expires December 6, 2004 [Page 98]=20 JAVA LDAP API April 2004=20 =20 =20 Returns the list of any continuation reference URLs in the object.=20 =20 =20 2.34 public class LDAPSearchResults=20 =20 An LDAPSearchResults object is returned from a synchronous search=20 operation. It provides access to all results received during the=20 operation (entries and exceptions).=20 =20 =20 2.34.1 getCount=20 =20 public int getCount()=20 =20 Returns a count of the entries and exceptions in the object. If the=20 search was submitted with a batch size greater than 0, this reports=20 the number of results received so far but not enumerated with next().=20 =20 =20 2.34.2 getResponseControls=20 =20 public LDAPControl[] getResponseControls()=20 =20 Returns the latest Server Controls returned by a Directory Server=20 in the context of this search request.=20 =20 =20 2.34.3 hasMore=20 =20 public boolean hasMore()=20 =20 Reports if there are more search results. If true, there are more=20 search results.=20 =20 =20 2.34.4 next=20 =20 public LDAPEntry next() throws LDAPException=20 =20 Returns the next search result as an LDAPEntry. If=20 automatic referral following is disabled or a referral was not=20 followed, next() will throw an LDAPReferralException when the=20 referral is received. See also 2.31.6.=20 =20 =20 2.35 public class LDAPSyntaxSchema=20 extends LDAPSchemaElement=20 =20 The LDAPSyntaxSchema class represents the definition of a syntax. It=20 is used to discover the known set of syntaxes in effect for the=20 subschema. See [ATTR] for a description of syntax representation in=20 LDAP.=20 =20 Expires December 6, 2004 [Page 99]=20 JAVA LDAP API April 2004=20 =20 =20 Note, that though this extends LDAPSchemaElement, it does not use the=20 name or obsolete members, subsequently calls to getName always return=20 null and isObsolete always returns false. There is also no matching=20 getSyntaxNames method in LDAPSchema.=20 Note also, that adding and removing syntaxes is not typically a=20 supported feature of LDAP servers.=20 =20 =20 2.35.1 Constructors=20 =20 public LDAPSyntaxSchema(String oid,=20 String description)=20 =20 Constructs a syntax for adding to or deleting from the schema.=20 =20 =20 public LDAPSyntaxSchema(String raw)=20 =20 Constructs a syntax from an encoding using the ldapSyntaxes syntax=20 [ATTR].=20 =20 Parameters are:=20 =20 oid OID of the syntax.=20 =20 description Optional description of the syntax.=20 =20 raw A definition of a syntax encoded using the=20 ldapSyntaxes syntax [ATTR].=20 =20 =20 2.36 public interface LDAPUnsolicitedNotificationListener=20 =20 An object that implements this interface can be notified when=20 unsolicited messages arrive from the server. The Application=20 registers the object with=20 LDAPConnection.addUnsolicitedNotificationListener. Unsolicited=20 messages have a message ID of 0. An implementation of the Java LDAP=20 API SHOULD NOT generate messages with an ID of 0.=20 =20 =20 2.36.1 messageReceived=20 =20 public void messageReceived(LDAPExtendedResponse msg)=20 =20 The method is called when an unsolicited message arrives from a=20 server, if the object has registered with=20 LDAPConnection.addUnsolicitedNotificationListener.=20 =20 Parameters are:=20 =20 msg An unsolicited message received from the server.=20 =20 Expires December 6, 2004 [Page 100]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 2.37 public class LDAPUrl=20 implements Cloneable, Serializable=20 =20 Encapsulates parameters of an LDAP Url query, as defined in=20 [LDAPURL]. An LDAPUrl object can be passed to LDAPConnection.search=20 to retrieve search results.=20 =20 =20 2.37.1 Constructors=20 =20 public LDAPUrl(String url) throws MalformedURLException=20 =20 Constructs a URL object with the specified string as URL.=20 =20 =20 public LDAPUrl(String host,=20 int port,=20 String dn)=20 =20 Constructs a URL object with the specified host, port, and DN. This=20 form is used to create URL references to a particular object in the=20 directory.=20 =20 public LDAPUrl(String host,=20 int port,=20 String dn,=20 String[] attrNames,=20 int scope,=20 String filter,=20 String[] extensions)=20 =20 Constructs an LDAP URL with all fields explicitly assigned, to=20 specify an LDAP search operation.=20 =20 Parameters are:=20 =20 url An LDAP URL string, e.g.=20 "ldap://ldap.example.com:80/dc=3Dexample,dc=3Dcom?c= n, sn?sub?(objectclass=3DinetOrgPerson)".=20 =20 host Host identifier of LDAP server, or null for=20 "localhost". See 2.8.9 for a discussion of valid=20 identifiers.=20 =20 port Port number for LDAP server (use=20 LDAPConnection.DEFAULT_PORT for default port).=20 =20 dn Distinguished name of the base object of the=20 search.=20 =20 =20 Expires December 6, 2004 [Page 101]=20 JAVA LDAP API April 2004=20 =20 =20 attrNames Names or OIDs of attributes to retrieve. Passing=20 a null array signifies that all user attributes=20 are to be retrieved. Passing a value of "*" as an=20 element of the array signifies that all user=20 attributes are to be retrieved.=20 =20 scope Depth of search (in DN namespace). Use one of=20 SCOPE_BASE, SCOPE_ONE, SCOPE_SUB from=20 LDAPConnection.=20 =20 filter Search filter specifying the search criteria, as=20 defined in [FILTER].=20 =20 extensions LDAP URL extensions specified; may be null or=20 empty. Each extension is a type=3Dvalue expression.= =20 The =3Dvalue part can be omitted. Prefix the=20 expression with '!' if the extension is mandatory=20 for evaluation of the URL.=20 =20 =20 2.37.2 decode=20 =20 public static String decode(String URLEncoded)=20 throws MalformedURLException=20 =20 Decodes a URL-encoded string. Any occurrences of %HH are decoded to=20 the hex value represented. However, this method does NOT decode "+"=20 into " ". See [URL] for details on URL encoding/decoding.=20 =20 Parameters are:=20 =20 URLEncoded String to decode.=20 =20 =20 2.37.3 encode=20 =20 public static String encode(String toEncode)=20 =20 Encodes the specified string. Any illegal characters are encoded as=20 %HH.=20 =20 Parameters are:=20 =20 toEncode String to encode.=20 =20 =20 2.37.4 getAttributeArray=20 =20 public String[] getAttributeArray()=20 =20 Returns an array of attribute names specified in the URL.=20 =20 =20 Expires December 6, 2004 [Page 102]=20 JAVA LDAP API April 2004=20 =20 =20 =20 2.37.5 getAttributes=20 =20 public Enumeration getAttributes()=20 =20 Returns an enumerator for the attribute names specified in the URL.=20 The enumerator is empty if the URL contains no attribute names.=20 =20 =20 2.37.6 getDN=20 =20 public String getDN()=20 =20 Returns the distinguished name encapsulated in the URL, or null if=20 none is specified.=20 =20 =20 2.37.7 getExtensions=20 =20 public String[] getExtensions ()=20 =20 Returns any LDAP URL extensions specified, or null if none are=20 specified. Each extension is a type=3Dvalue expression. The =3Dvalue p= art=20 can be omitted. Prefix the expression with '!' if the extension is=20 mandatory for evaluation of the URL.=20 =20 =20 2.37.8 getFilter=20 =20 public String getFilter()=20 =20 Returns the search filter [LDAPURL], or null if none was specified.=20 =20 =20 2.37.9 getHost=20 =20 public String getHost()=20 =20 Returns the host name of the LDAP server to connect to.=20 =20 =20 2.37.10 getPort=20 =20 public int getPort()=20 =20 Returns the port number of the LDAP server to connect to.=20 =20 =20 2.37.11 getScope=20 =20 public int getScope()=20 =20 =20 Expires December 6, 2004 [Page 103]=20 JAVA LDAP API April 2004=20 =20 =20 Returns the depth of search (in DN namespace) - one of SCOPE_BASE,=20 SCOPE_ONE, SCOPE_SUB from LDAPConnection.=20 =20 =20 2.37.12 toString=20 =20 public String toString()=20 =20 Returns a valid string representation of this LDAP URL.=20 =20 =20 =20 3. Implementation considerations=20 =20 3.1 Controls=20 =20 LDAPv3 operations can be extended through the use of controls.=20 Controls can be sent to a server or returned to the application with=20 any LDAP message. These controls are represented by LDAPControl=20 objects.=20 =20 Controls are set and retrieved in LDAPConnection with the=20 setConstraints and getConstraints methods. Either a single=20 LDAPControl or an array can be specified, e.g.=20 =20 LDAPControl control =3D new LDAPControl( type, critical, vals );=20 LDAPConstraints cons =3D ld.getConstraints();=20 cons.setControls( control );=20 ld.setConstraints( cons );=20 or=20 LDAPControl[] controls =3D new LDAPControl[2];=20 controls[0] =3D new LDAPControl( type0, critical0, vals0 );=20 controls[1] =3D new LDAPControl( type1, critical1, vals1 );=20 LDAPConstraints cons =3D ld.getConstraints();=20 cons.setControls( controls );=20 ld.setConstraints( cons );=20 =20 Server controls returned to an application as part of the response to=20 a synchronous operation can be obtained with=20 LDAPConnection.getResponseControls() or=20 LDAPSearchResults.getResponseControls(). Controls returned on an=20 asynchronous operation are available with LDAPMessage.getControls().=20 =20 =20 3.2 Referral handling and exceptions=20 =20 Asynchronous requests=20 =20 No automatic referral following is supported for asynchronous=20 requests.=20 =20 =20 Expires December 6, 2004 [Page 104]=20 JAVA LDAP API April 2004=20 =20 =20 No LDAPExceptions are thrown for asynchronous requests except in the=20 case of LDAPLocalException. The Throwable causing the local error can=20 be retrieved with LDAPConnection.getCause().=20 =20 When a referral is received, the application receives an LDAPResponse=20 object with a result code of REFERRAL. If a continuation reference is=20 received the application receives an LDAPSearchResultReference=20 object.=20 =20 =20 Synchronous requests=20 =20 Referral-following behavior depends on two things: if automatic=20 referral following is enabled, and when enabled if an=20 LDAPReferralHandler is provided by the application.=20 =20 - Behavior if automatic referral following is "false" (not enabled):=20 =20 An LDAPException is thrown for any non-zero result code.=20 =20 An LDAPException is thrown for local failures.=20 =20 An LDAPReferralException is thrown if the result code is=20 REFERRAL. The object contains the referral URL strings. This=20 ends the request, i.e., LDAPSearchResults.hasMore() will return=20 false since there are noresults to retrieve.=20 =20 An LDAPReferralException is thrown for each=20 SearchResultReference received during a synchronous search=20 request. The object contains the referral URL strings. The=20 exception is not an error, LDAPSearchResults.hasMore() will=20 indicate ifthere are more results to retrieve.=20 =20 - Behavior if automatic referral following is "true" and either no=20 LDAPReferralHandler is registered in LDAPConstraints, or an=20 LDAPAuthHandler object is registered in LDAPConstraints:=20 =20 Exception handling is the same whether or not an LDAPAuthHandler=20 object is registered, but authentication to the server is not=20 the same. The registration of an LDAPAuthHandler object allows=20 connections to be authenticated. No handler registered results=20 in an anonymous (unauthenticated) connection.=20 =20 LDAPExceptions are thrown if errors occur during the normal=20 processing of the command, i.e. NO_SUCH_OBJECT,=20 NO_SUCH_ATTRIBUTE, etc.=20 =20 An LDAPReferralException is thrown only if the API=20 implementation could not connect and bind to any referral URL in=20 the list of URLs included in an individual REFERRAL result or=20 LDAPSearchResultReference.=20 =20 =20 Expires December 6, 2004 [Page 105]=20 JAVA LDAP API April 2004=20 =20 =20 When problems occur during the establishment of an authenticated=20 connection by the API implementation during automatic referral=20 following, the LDAPReferralException will contain the last tried=20 URL String of the server the API attempted to connect/bind to=20 (the referral can be retrieved with getFailedReferral()), and=20 the Throwable that caused the Exception (which can be retrieved=20 with getCause()).Some possible failures are IOException on the=20 connection, MalformedURLException on the referral string, or=20 authentication failures on the bind.=20 =20 Upon receipt of an LDAPReferralException, the application knows=20 that the API implementation was not able to connect to any of=20 the servers in the referral list (which can be retrieved with=20 getReferrals()) and was not able to follow the referral. The=20 error indicated by getCause() occurred on the referral indicated=20 with getFailedReferral(). In the case of search, any results=20 starting at the indicated base of the referred to server are=20 missing from the search results.=20 =20 - behavior if automatic referral following is "true", and an=20 LDAPBindHandler object is registered in LDAPConstraints:=20 =20 LDAPExceptions are thrown if errors occur during the normal=20 processing of the command, i.e. NO_SUCH_OBJECT,=20 NO_SUCH_ATTRIBUTE, etc.=20 =20 An LDAPReferralException is thrown only if the LDAPBindHandler=20 object throws an exception.=20 =20 Upon receipt of an LDAPReferralException, the application knows=20 that the LDAPBindHandler object was not able or not willing to=20 connect to any of the servers in the referral list and so was=20 not able to follow the referral. The list of referrals that=20 failed is available with getReferrals() and the last failed=20 referral with getFailedReferral(). The exception thrown by the=20 LDAPBindHandler object is available with getCause().=20 =20 The API implementation MAY follow referrals of types other than LDAP=20 URLs [LDAPURL] on automatic referral following if access to the referred=20 servers is through the LDAP protocol [LDAPv3]. To successfully follow=20 such referral URLs, the application MUST provide an LDAPBindHandler that=20 can interpret the URL and perform an appropriate connect and bind=20 operation to the server. The application MAY follow such referrals=20 through application specific code.=20 3.3 Message IDs=20 =20 An implementation of the Java LDAP API SHOULD NOT generate messages=20 with an ID of 0.=20 =20 =20 3.4 Notice of disconnection=20 =20 =20 Expires December 6, 2004 [Page 106]=20 JAVA LDAP API April 2004=20 =20 =20 If a notice of disconnection is received by a connection object, the=20 API implementation MUST close the connection without accepting or=20 sending additional messages. Any clones of the object are=20 disconnected as a consequence of closing the connection.=20 =20 =20 3.5 Level of compatibility=20 =20 Implementations of the API MUST include all classes and interfaces=20 described in this document and thus are to be binary compatible, i.e.=20 any application with its classpath including the jar or class files=20 implementing this API will exhibit consistant behavior when using the=20 API as defined by this document.=20 =20 =20 3.6 Dependencies=20 =20 The Java LDAP API is dependent on the following:=20 =20 - JDK 1.2 or higher=20 - JAAS 1.0 or higher (for the interfaces in the=20 javax.security.auth.callback package)=20 =20 =20 3.7 Invalid responses=20 =20 If a message is received by an API implementation from the server and=20 the message cannot be interpreted as an LDAP PDU, an LDAPException=20 MUST be thrown with a result code of INVALID_RESPONSE.=20 =20 3.8 Java Unicode Limitations=20 =20 Any Unicode characters which cannot be represented with Java 16-bit=20 Unicode strings (UCS2) cannot be used with this API, unless those=20 characters are handled as binary UTF-8 data. If changes are=20 introduced into the Java Language to accommodate these characters,=20 implementations of the Java LDAP API SHOULD also accommodate these=20 characters.=20 =20 3.9 Intermediate Response Messages=20 =20 =20 Applications may receive messages with a response type of=20 LDAP_INTERMEDIATE_RESPONSE from any operation [LDAPINT].=20 =20 Applications using synchronous interfaces will receive an=20 INTERMEDIATE_RESPONSE exception upon receipt of an LDAP Intermediate=20 Response Message; the operation will not be terminated, but will=20 continue until an LDAPResponse message is received from the server or=20 until the application abandons the operation. The application can=20 obtain the actual message through the getResponse() method of the=20 LDAPException class.=20 =20 Expires December 6, 2004 [Page 107]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Applications using asynchronous interfaces receive an LDAPMessage=20 class with the response type set to LDAP_INTERMEDIATE_RESPONSE.=20 =20 It is up to the application to determine how to interpret the data in=20 the message.=20 =20 =20 3.10 Extensibility=20 =20 To accommodate additions to the LDAP protocol [LDAPINT], LDAP=20 messages with types not defined in [LDAPPROTO] MUST be returned to=20 the application. Responses with unknown types that do not match the=20 Message ID of an outstanding request or that are not an unsolicited=20 notification message, SHOULD be discarded.=20 =20 Applications using synchronious interfaces will receive an=20 UNKNOWN_TYPE exception upon receipt of an LDAP message containing an=20 unknown response type; the operation will not be terminated but will=20 continue until an LDAPResponse message is received from the server or=20 until the application abandons the operation. The application can=20 obtain the actual message through the getResponse() method of the=20 LDAPException class. =20 =20 Applications using asynchronous interfaces will receive an=20 LDAPMessage class with the response type set to the type of the=20 message received.=20 =20 It is up to the application to determine how to interpret the data in=20 the message.=20 =20 =20 4. Security considerations=20 =20 LDAP supports security through protocol-level authentication, using=20 clear-text passwords or other more secure mechanisms. It also=20 supports running over TLS, which provides strong security at the=20 transport layer.=20 =20 If a TLS session is terminated by the server but the client TLS=20 provider and LDAP API implementation continue to use the socket=20 rather than closing it, the application is notified through an=20 LDAPException on the first operation request subsequent to=20 termination of the TLS session.=20 =20 An interface to using SASL for configurable authentication and=20 session protection is provided, but implementations are outside the=20 scope of this document. Implementations of this API MUST ensure that=20 a SASL provider is configured to comply with the minimal security=20 guidelines of RFC 2829 [AUTH].=20 =20 Implementations of this API SHOULD be cautious when handling=20 =20 Expires December 6, 2004 [Page 108]=20 JAVA LDAP API April 2004=20 =20 =20 authentication credentials. In particular, keeping long-lived copies=20 of credentials without the application's knowledge is discouraged.=20 =20 Implementations of this API MUST discard information about the server=20 obtained prior to negotiation of security protections provided by=20 SASL and/or TLS [AUTH].=20 =20 =20 5. Acknowledgements=20 =20 The proposed API builds on earlier work done in collaboration with=20 Thomas Kwan and Stephan Gudmundson, then of NCware Technologies Corp.=20 It also includes suggestions by Steven Merrill of Novell, Inc, and=20 benefited from extensive review and comments by Kurt Zeilenga of=20 OpenLDAP, Rosanna Lee of Sun Microsystems, Mark Smith of Netscape=20 Communications Corp., and Jim Sermersheim of Novell, Inc. Parts of=20 the overview of the LDAP model are taken from draft-ietf-ldapext- ldap-c-api.=20 =20 =20 6. Bibliography=20 =20 6.1 Normative References=20 =20 [ATTR] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight=20 Directory Access Protocol: Attribute Syntax Definitions",=20 RFC 2252, December 1997=20 =20 [AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication=20 Methods for LDAP", RFC 2829, May 2000=20 =20 [DN] S. Kille, " UTF-8 String Representation of Distinguished=20 Names," RFC 2253, December 1997.=20 =20 [FILTER] T. Howes, "A String Representation of LDAP Search Filters,"=20 RFC 2254, December 1997.=20 =20 =20 [LDAPINT] R. Harrison, K. Zeilenga, =93The Lightweight Directory Acces= s=20 Protocol (LDAP) Itermediate Response Message=94, RFC 3771, April=20 2004=20 [LDAPLANG] M. Wahl, T. Howes, "Use of Language Codes in LDAP", RFC=20 2596, May 1999=20 =20 [LDAPPROTO] J. Hodges & R. Morgan, "LDAPv3: Technical=20 Specification=94, RFC 3377, September 2002=20 =20 [LDAPTLS] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory=20 Access Protocol (v3): Extension for Transport Layer Security",=20 RFC 2830, May 2000.=20 =20 =20 Expires December 6, 2004 [Page 109]=20 JAVA LDAP API April 2004=20 =20 =20 [LDAPURL] T. Howes, M. Smith, "An LDAP URL Format", RFC 2255,=20 December 1997.=20 =20 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access=20 Protocol (v3)", RFC 2251, December 1997.=20 =20 [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)",=20 RFC 2222, October 1997.=20 =20 [TLS] T. Dierks, C. Allen, "The TLS Protocol", RFC 2246, January=20 1999.=20 =20 [URL] T. Berners-Lee, R. Fielding, L. Masinter, " Uniform Resource=20 Identifiers (URI): Generic Syntax", RFC 2396, August 1998.=20 =20 6.2 Informative References=20 =20 [IPv6] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",=20 RFC 2373, July 1998=20 =20 [IPv6URL] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal=20 IPv6 Addresses in URL's", RFC 2732, December 1999=20 =20 [JAVA] B. Joy, G. Steele, J. Gosling, G. Bracha, "The Java Language=20 Specification", Second Edition, Addison-Wesley, June 2000=20 =20 [JAVASASL] "Java SASL Specification", Java Community Process, JSR28=20 =20 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement=20 Levels", Bradner, S., RFC 2119, March 1997=20 =20 [LANG] H. Alvestrans, "Tags for the Identification of Languages", RFC=20 3066, January 2001.=20 =20 [X500] The Directory: Overview of Concepts, Models, and Services. =20 CCITT, Recommendation X.500, 2nd edition, 1993=20 =20 =20 =20 7. Authors' addresses=20 =20 Rob Weltman=20 Netscape Communications Corp.=20 466 Ellis Street=20 Mountain View, CA 94043=20 USA=20 +1 650 937-3194=20 rweltman@netscape.com=20 =20 Christine Tomlinson=20 Sun Microsystems, Inc.=20 8911 Capital of Texas Highway=20 =20 Expires December 6, 2004 [Page 110]=20 JAVA LDAP API April 2004=20 =20 =20 Suite 4140=20 Austin, TX US 78759=20 +1 512 231 1600=20 christine.tomlinson@sun.com=20 =20 Steven Sonntag=20 Novell, Inc.=20 1800 South Novell Place=20 Provo, UT 84606=20 USA=20 +1 801 861 7097=20 vtag@novell.com=20 =20 =20 Expires December 6, 2004 [Page 111]=20 JAVA LDAP API April 2004=20 =20 =20 8. Appendix A - Sample Java LDAP programs=20 =20 8.1 Java LDAP programs using synchronous methods=20 =20 import org.ietf.ldap.*;=20 import java.util.*;=20 =20 public class SearchJensen {=20 public static void main( String[] args ) {=20 LDAPConnection ld =3D new LDAPConnection();=20 try {=20 /* Connect to server */=20 String MY_HOST =3D "localhost";=20 int MY_PORT =3D LDAPConnection.DEFAULT_PORT;=20 ld.connect( MY_HOST, MY_PORT );=20 /* Authentication not required for an anonymous=20 connection */=20 =20 /* search for all entries with surname of Jensen */=20 String MY_FILTER =3D "(sn=3DJensen)";=20 String MY_SEARCHBASE =3D "dc=3Dexample,dc=3Dcom";=20 =20 LDAPSearchConstraints cons =3D ld.getSearchConstraints();=20 /* Setting the batchSize to one will cause the result=20 enumeration below to block on one result at a time,=20 allowing us to update a list or do other things as=20 results come in. */=20 /* We could set it to 0 if we just wanted to get all=20 results and were willing to block until then */=20 cons.setBatchSize( 1 );=20 ld.setSearchConstraints(cons);=20 LDAPSearchResults res =3D ld.search( MY_SEARCHBASE,=20 ld.SCOPE_ONE,=20 MY_FILTER,=20 null,=20 false,=20 cons );=20 =20 /* Loop on results until finished */=20 while ( res.hasMore() ) {=20 =20 /* Next directory entry */=20 LDAPEntry findEntry =3D res.next ();=20 System.out.println( findEntry.getDN() );=20 =20 /* Get the attributes of the entry */=20 LDAPAttributeSet findAttrs =3D=20 findEntry.getAttributeSet();=20 Iterator enumAttrs =3D findAttrs.iterator(); =20 System.out.println( "Attributes: " ); =20 /* Loop on attributes */ =20 while ( enumAttrs.hasNext() ) { =20 =20 Expires December 6, 2004 [Page 112]=20 JAVA LDAP API April 2004=20 =20 =20 LDAPAttribute anAttr =3D =20 (LDAPAttribute)enumAttrs.next();=20 String attrName =3D anAttr.getName();=20 System.out.println( " " + attrName );=20 /* Loop on values for this attribute.=20 Note: we are assuming all values are UTF-8=20 strings=20 */=20 Enumeration enumVals =3D anAttr.getStringValues();= =20 while ( enumVals.hasMoreElements() ) {=20 String aVal =3D (String)enumVals.nextElement()= ;=20 System.out.println( " " + aVal );=20 }=20 }=20 }=20 =20 /* Done, so disconnect */=20 ld.disconnect();=20 } catch( LDAPException e ) {=20 System.out.println( "Error: " + e.toString() );=20 }=20 }=20 }=20 =20 Expires December 6, 2004 [Page 113]=20 JAVA LDAP API April 2004=20 =20 =20 import org.ietf.ldap.*;=20 import java.io.*;=20 import java.util.*;=20 import javax.security.auth.callback.*;=20 =20 public class ModifyEmail {=20 public static void main( String[] args ) {=20 LDAPConnection ld =3D new LDAPConnection();=20 try {=20 /* Connect to server */=20 String MY_HOST =3D "localhost";=20 int MY_PORT =3D LDAPConnection.DEFAULT_PORT;=20 ld.connect( MY_HOST, MY_PORT );=20 String MY_NAME =3D=20 "uid=3Dbjensen,ou=3Dpeople,dc=3Dexample,dc=3Dcom= ";=20 =20 /* Callback handler to supply credentials for SASL */=20 CallbackHandler cbh =3D new CallbackHandler() {=20 public void handle( Callback[] callbacks )=20 throws IOException, UnsupportedCallbackException {=20 for ( int i =3D 0; i < callbacks.length; i++ ) {=20 if ( callbacks[i] instanceof NameCallback ){=20 ((NameCallback)callbacks[i]).setName(=20 "bjensen" );=20 } else if ( callbacks[i] instanceof=20 PasswordCallback ) {=20 ((PasswordCallback)callbacks[i]).setPassword(=20 "MysteryLady".toCharArray() );=20 =20 } else {=20 throw new UnsupportedCallbackException (=20 callbacks[i],=20 "Unrecognized Callback" );=20 }=20 }=20 }=20 };=20 /* SASL bind */=20 ld.bind( "cn=3DBarbara Jensen,dc=3Dexample,dc=3Dcom",=20 "bjensen", null, cbh );=20 =20 /* Prepare to change my email address */=20 LDAPAttribute attrEmail =3D=20 new LDAPAttribute( "mail", "babs@example.com" );=20 LDAPModification mod =3D=20 new LDAPModification( LDAPModification.REPLACE,=20 attrEmail );=20 =20 /* Now modify the entry in the directory */=20 ld.modify( MY_NAME, mod );=20 System.out.println( "Entry modified" );=20 =20 =20 Expires December 6, 2004 [Page 114]=20 JAVA LDAP API April 2004=20 =20 =20 /* Done, so disconnect */=20 ld.disconnect();=20 } catch( LDAPException e ) {=20 System.out.println( "Error: " + e.toString() );=20 }=20 }=20 }=20 =20 Expires December 6, 2004 [Page 115]=20 JAVA LDAP API April 2004=20 =20 =20 import org.ietf.ldap.*;=20 import java.util.*;=20 =20 public class ShowSchema {=20 public static void main( String[] args ) {=20 LDAPConnection ld =3D new LDAPConnection();=20 try {=20 /* Connect to server */=20 String MY_HOST =3D "localhost";=20 int MY_PORT =3D LDAPConnection.DEFAULT_PORT;=20 ld.connect( MY_HOST, MY_PORT );=20 =20 /* Fetch the schema */=20 LDAPSchema schema =3D ld.fetchSchema( ld.getSchemaDN() );=20 =20 /* What is the definition of "userPassword"? */=20 LDAPAttributeSchema a =3D=20 schema.getAttributeSchema( "userpassword" );=20 if ( a !=3D null ) {=20 String syntax =3D a.getSyntaxString();=20 String syntaxString =3D "string";=20 if ( syntax.equals(BINARY_SYNTAX) )=20 syntaxString =3D "binary";=20 else if (syntax.equals(INTEGER_SYNTAX) )=20 syntaxString =3D "integer";=20 String single =3D "multi-valued";=20 if ( a.isSingleValued() )=20 single =3D "single-valued";=20 System.out.println( "userPassword. " +=20 "OID =3D " + a.getID() +=20 ", type =3D " + syntaxString +=20 ", " + single );=20 }=20 =20 /* What are the possible attributes for "person"? */=20 LDAPObjectClassSchema o =3D=20 schema.getObjectClassSchema( "person" );=20 if ( o !=3D null ) {=20 Enumeration required =3D o.getRequiredAttributes();=20 Enumeration optional =3D o.getOptionalAttributes();=20 System.out.println(=20 "Required attributes for person:" );=20 while( required.hasMoreElements() ) {=20 System.out.println( " " +=20 required.nextElement() );=20 }=20 System.out.println(=20 "Optional attributes for person:" );=20 while( optional.hasMoreElements() ) { =20 System.out.println( " " + =20 optional.nextElement() ); =20 }=20 =20 Expires December 6, 2004 [Page 116]=20 JAVA LDAP API April 2004=20 =20 =20 }=20 =20 /* Done, so disconnect */=20 ld.disconnect();=20 } catch( LDAPException e ) {=20 System.out.println( "Error: " + e.toString() );=20 }=20 }=20 protected static final String BINARY_SYNTAX =3D=20 "1.3.6.1.4.1.1466.115.121.1.5";=20 protected static final String INTEGER_SYNTAX =3D=20 "1.3.6.1.4.1.1466.115.121.1.27";=20 }=20 =20 =20 =20 Expires December 6, 2004 [Page 117]=20 JAVA LDAP API April 2004=20 =20 =20 8.2 Java LDAP programs using asynchronous methods=20 =20 import org.ietf.ldap.*;=20 import java.util.*;=20 import java.io.UnsupportedEncodingException;=20 =20 public class SearchJensen {=20 public static void main( String[] args ) {=20 try {=20 LDAPConnection ld =3D new LDAPConnection();=20 /* Connect to server */=20 String MY_HOST =3D "localhost";=20 int MY_PORT =3D 389;=20 byte[] MY_PASSWORD =3D null;=20 try {=20 MY_PASSWORD =3D "password".getBytes( "UTF8" );=20 } catch (UnsupportedEncodingException ex ) {=20 }=20 ld.connect( MY_HOST, MY_PORT );=20 =20 /* Asynchronous authentication */=20 LDAPMessageQueue r =3D=20 ld.bind( 3, "uid=3Dadmin,ou=3Dpeople,dc=3Dexample,dc=3D= com",=20 MY_PASSWORD, (LDAPMessageQueue)null );=20 =20 /* Do something else, just to show that we're not=20 blocked yet */=20 System.out.println( "Started authenticating" );=20 =20 /* Wait until it completes */=20 LDAPResponse response =3D (LDAPResponse)r.getResponse();=20 int resultCode =3D response.getResultCode();=20 if (resultCode !=3D LDAPException.SUCCESS) {=20 throw new LDAPException ( "error result",=20 resultCode,=20 response.getMatchedDN() );=20 }=20 =20 /* search for all entries with surname of Jensen */=20 String MY_FILTER =3D "(sn=3DJensen)";=20 String MY_SEARCHBASE =3D "dc=3Dexample,dc=3Dcom";=20 =20 LDAPMessageQueue l =3D=20 ld.search( MY_SEARCHBASE,=20 ld.SCOPE_ONE,=20 MY_FILTER,=20 null,=20 false,=20 (LDAPMessageQueue)null );=20 =20 /* Loop on results until finished */=20 LDAPMessage msg;=20 =20 Expires December 6, 2004 [Page 118]=20 JAVA LDAP API April 2004=20 =20 =20 while( (msg =3D l.getResponse()) !=3D null ) {=20 if ( msg instanceof LDAPSearchResultReference ) {=20 String[] urls =3D=20 ((LDAPSearchResultReference)msg).getReferrals();=20 // Do something with the referrals...=20 } else if ( msg instanceof LDAPSearchResult ) {=20 LDAPEntry entry =3D=20 ((LDAPSearchResult)msg).getEntry();=20 // The rest of the processing is the same as for=20 // a synchronous search=20 System.out.println( entry.getDN() );=20 } else {=20 // A search response=20 LDAPResponse res =3D (LDAPResponse)msg;=20 int status =3D res.getResultCode();=20 if ( status =3D=3D LDAPException.SUCCESS ) {=20 // Nothing to do=20 } else {=20 String err =3D=20 LDAPException.resultCodeToString(status);=20 throw new LDAPException(err,=20 status,=20 res.getMatchedDN());=20 }=20 }=20 }=20 =20 /* Done, so disconnect */=20 ld.disconnect();=20 } catch ( LDAPException e ) {=20 System.err.println( e.toString() );=20 }=20 }=20 }=20 =20 Expires December 6, 2004 [Page 119]=20 JAVA LDAP API April 2004=20 =20 =20 import org.ietf.ldap.*;=20 import java.util.*;=20 =20 /* This example multiplexes the input from three different servers */=20 =20 public class MultiplexServers {=20 public static void main( String[] args ) {=20 try {=20 LDAPConnection [] ld =3D new LDAPConnection[3];=20 String[] hosts =3D { "foo1", "foo2", "foo3" };=20 int[] ports =3D { 389, 389, 2018 };=20 String[] bases =3D { "dc=3Dexample,dc=3Dcom",=20 "o=3Dexample.com",=20 "dc=3Dexample2,dc=3Dcom" };=20 /* search for all entries with surname of Jensen */=20 String MY_FILTER =3D "(sn=3DJensen)";=20 =20 for( int i =3D 0; i < ld.length; i++ ) {=20 ld[i] =3D new LDAPConnection();=20 /* Connect to server */=20 ld[i].connect( hosts[i], ports[i] );=20 }=20 =20 /* Get a response queue for one search */=20 LDAPMessageQueue l =3D=20 ld[0].search( bases[0],=20 ld.SCOPE_SUB,=20 MY_FILTER,=20 null,=20 false,=20 (LDAPMessageQueue)null );=20 /* Share the queue */=20 for( int i =3D 1; i < ld.length; i++ ) {=20 ld[i].search( bases[i],=20 ld[i].SCOPE_SUB,=20 MY_FILTER,=20 null,=20 false,=20 l );=20 }=20 =20 /* Loop on results until finished */=20 LDAPMessage msg;=20 while( (msg =3D l.getResponse()) !=3D null ) {=20 /* The rest is the same as in the previous example */=20 /* ... */=20 =20 Expires December 6, 2004 [Page 120]=20 JAVA LDAP API April 2004=20 =20 =20 import org.ietf.ldap.*;=20 import java.util.*;=20 =20 /* This example multiplexes the input from three searches in=20 different subtrees of the same server */=20 =20 public class MultiplexTrees {=20 public static void main( String[] args ) {=20 try {=20 LDAPConnection ld =3D new LDAPConnection ();=20 /* Connect to server */=20 String MY_HOST =3D "localhost";=20 int MY_PORT =3D 389;=20 ld.connect( MY_HOST, MY_PORT );=20 String MY_FILTER =3D "(sn=3DJensen)";=20 String[] bases =3D { "dc=3Dexample,dc=3Dcom",=20 "o=3Dexample.com",=20 "dc=3Dexample2,dc=3Dcom" };=20 =20 /* Get a response queue for one search */=20 LDAPMessageQueue l =3D=20 ld.search( bases[0],=20 ld.SCOPE_SUB,=20 MY_FILTER,=20 null,=20 false,=20 (LDAPMessageQueue)null );=20 /* Share the queue */=20 for( int i =3D 1; i < bases.length; i++ ) {=20 ld.search( bases[i],=20 ld.SCOPE_SUB,=20 MY_FILTER,=20 null,=20 false,=20 l );=20 }=20 =20 /* The rest is the same as in the MultiplexServers=20 example */=20 /* ... */=20 =20 Expires December 6, 2004 [Page 121]=20 JAVA LDAP API April 2004=20 =20 =20 import org.ietf.ldap.*;=20 import java.util.*;=20 =20 public class ModifyEmail {=20 public static void main( String[] args ) {=20 LDAPConnection ld =3D new LDAPConnection(=20 new SSLSocketFactory.getdefault() );=20 try {=20 /* Connect to server */=20 String MY_HOST =3D "localhost";=20 int MY_PORT =3D 389;=20 ld.connect( MY_HOST, MY_PORT );=20 =20 /* Use TLS to authenticate and secure the connection */=20 ld.startTLS();=20 /* Use SASL external on completed TLS client auth */=20 ld.bind( null, null, new String[] { "external" },=20 null, null );=20 =20 /* Prepare to change my email address */=20 LDAPAttribute attrEmail =3D=20 new LDAPAttribute( "mail", "babs@example.com" );=20 LDAPModification mod =3D=20 new LDAPModification( LDAPModification.REPLACE,=20 attrEmail );=20 =20 /* Now modify the entry in the directory */=20 LDAPMessageQueue r =3D=20 ld.modify( MY_NAME, mod, null );=20 =20 /* Do something else, just to show that we're not=20 blocked yet */=20 System.out.println( "Started authenticating" );=20 =20 /* Wait until it completes */=20 LDAPResponse response =3D (LDAPResponse)r.getResponse();=20 int resultCode =3D response.getResultCode();=20 if (resultCode !=3D LDAPException.SUCCESS) {=20 throw new LDAPException ( "error result",=20 resultCode,=20 response.getMatchedDN() );=20 }=20 =20 System.out.println( "Entry modified" );=20 =20 /* Done, so disconnect */=20 ld.disconnect();=20 } catch( LDAPException e ) {=20 System.out.println( "Error: " + e.toString() );=20 }=20 =20 }=20 =20 Expires December 6, 2004 [Page 122]=20 JAVA LDAP API April 2004=20 =20 =20 }=20 =20 Expires December 6, 2004 [Page 123]=20 JAVA LDAP API April 2004=20 =20 =20 =20 9. Appendix B - Revision history=20 =20 =20 9.1 Changes from ldap-java-api-18.txt=20 =20 Updated =93Status of this Memo=94 and Copyright sections per RFC 3668.= =20 =20 Made usage of MUST, MAY, SHOULD conforms to RFC 2119.=20 =20 Made editorial changes.=20 =20 Clarified definition of OID.=20 =20 Made a distinction between the API implementation and the application=20 using the implementation.=20 =20 LDAPAttribute=20 =20 Clarified that name and options are case insensitive and options=20 have no order.=20 =20 Renamed method getBaseName to getTypeName.=20 =20 Removed method getLangSubtype.=20 =20 Renamed method getSubtypes to getOptions.=20 =20 Renamed method hasSubtype to hasOption.=20 =20 Renamed method hasSubtypes to hasOptions.=20 =20 Changed terminology throughout the document from subtype to=20 option and removed references to language subtypes, leaving only=20 a general discussion about options.=20 =20 LDAPAttributeSchema=20 =20 Clarified names and values of constants.=20 =20 LDAPAttributeSet=20 =20 Clarified that method getAttribute returns null if no attribute=20 found.=20 =20 Removed method getAttribute(String, String) because it was=20 associated with language subtypes.=20 =20 Added method getSubset(String, String) which provides a more=20 general implementation of the above.=20 =20 LDAPConnection=20 =20 Expires December 6, 2004 [Page 124]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Clarified that the method compare throws an=20 IllegalArgumentException if more than one assertion value is=20 supplied in the parameters.=20 =20 Clarified which bind() methods are are synchronous and which are=20 asynchronous.=20 =20 LDAPConstraints=20 =20 Clarified that the method getControls returns null if no=20 controls are present.=20 =20 LDAPException=20 =20 Clarified use of LDAPLocalException to distinguish local errors.=20 =20 Placed methods in alphabetical order.=20 =20 Placed local errors in alphabetical order.=20 =20 Added method getResponse which is used to obtain message of=20 unknown type of of type LDAP_INTERMEDIATE_RESPONSE.=20 =20 LDAPExtendedResponse=20 =20 Implements Serializable=20 =20 LDAPLocalException=20 =20 Clarified use of LDAPLocalException to distinguish local errors.=20 =20 LDAPMessage=20 Added a new response type: LDAP_INTERMEDIATE_RESPONSE=20 =20 LDAPMessageQueue=20 =20 Now a class instead of an interface. LDAPResponseQueue and=20 LDAPSearchQueue are removed. If an application using=20 asynchronous methods merged a search queue into a response=20 queue, the search queue functionality of the isComplete method=20 is needed but not present in the response queue and the identity=20 of the queues is muddied. If you add the method, both classes=20 will have the same functionality. There is really no need for=20 the two classes, as the single class LDAPMessageQueue can=20 perform all the needed functionality with no ambiguity.=20 =20 LDAPResponseQueue=20 =20 Removed class, only LDAPMessageQueue is needed.=20 =20 LDAPSchemaElement=20 =20 Expires December 6, 2004 [Page 125]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Implements Serializable=20 =20 LDAPSearchQueue=20 =20 Removed class, only LDAPMessageQueue is needed.=20 =20 LDAPSchemaElement=20 =20 Implements Serializable.=20 =20 LDAPSocketFactory=20 =20 Remove class, now using standard Java JSSE, such as=20 SSLSocketFactory.=20 =20 LDAPTLSSocketFactory=20 =20 Remove class, now using standard Java JSSE.=20 =20 Implementation Notes=20 =20 Added a note describing what action is taken for referrals that=20 are not a URL of type ldap://.=20 =20 Moved the note regarding limitations of Java with regard to=20 support for UCS4 characters in a String from the overview to the=20 Implementation Notes and included notes on how to handle those=20 characters.=20 =20 Added information on how receipt of an LDAP Intermediate=20 Response Message is handled.=20 =20 Added information on how receipt of an LDAP message with an=20 unknown response type is handled.=20 =20 Bibliography=20 =20 Moved some references from Informative to Normative and added=20 RFC 3771, LDAP Intermediate Response Message.=20 =20 =20 9.2 Changes from ldap-java-api-17.txt=20 =20 =20 LDAPAttribute=20 =20 Throws IllegalArgumentException for null as value parameter in=20 constructors.=20 Implements Comparable, with the method compareTo().=20 =20 =20 =20 Expires December 6, 2004 [Page 126]=20 JAVA LDAP API April 2004=20 =20 =20 LDAPConnection=20 =20 getProperty() returns null for property not found rather than=20 throwing LDAPException.=20 Added fetchSchema() and getSchemaDN().=20 Removed getInputStream(), getOutputStream(), setInputStream(),=20 setOutputStream().=20 =20 =20 LDAPConstraints=20 =20 Removed text saying that non-LDAP URLs are ignored.=20 setProperty() throws IllegalArgumentException for an=20 unsupported property.=20 =20 =20 LDAPEntry=20 =20 Implements Comparable, with the method compareTo().=20 Clarified that getAttributeSet() and getAttribute() return=20 copies rather than references.=20 =20 =20 LDAPExtendedOperation=20 =20 Implements Cloneable.=20 =20 =20 LDAPExtendedResponse=20 =20 Added register().=20 =20 =20 LDAPLocalException=20 =20 New class for local errors.=20 =20 =20 LDAPSchema=20 =20 It now extends LDAPEntry.=20 Constructor takes an LDAPEntry as parameter.=20 Removed fetchSchema(), add(), modify(), remove(), and=20 saveSchema().Methods in LDAPConnection provide this=20 functionality.=20 =20 =20 LDAPSchemaElement=20 =20 Extends LDAPAttribute.=20 Added clarification that the class is read only.=20 =20 =20 Expires December 6, 2004 [Page 127]=20 JAVA LDAP API April 2004=20 =20 =20 =20 LDAPTLSSocketFactory=20 =20 New interface to indicate ability to create a TLS socket.=20 =20 =20 Other=20 =20 Java 2 is now a requirement (not JDK 1.1.8 or Java 2).=20 Editorial changes=20 =20 =20 9.3 Changes from ldap-java-api-16.txt=20 =20 =20 LDAPException=20 =20 Added serverMessage as parameter in constructors.=20 =20 =20 Other=20 =20 Corrected typographical errors and errors in examples of=20 appendix A.=20 =20 =20 9.4 Changes from ldap-java-api-15.txt=20 =20 =20 LDAPAttribute=20 =20 Implements Cloneable.=20 =20 =20 LDAPAttributeSchema=20 =20 Constructor takes "String[] names" instead of "String name" and=20 "String[] aliases".=20 =20 =20 LDAPAttributeSet=20 =20 Implements Cloneable and java.util.Set. Removed the methods=20 made redundant by implementing Set: add(LDAPAttribute attr),=20 elementAt(), getAttributes(), remove(String name),=20 removeElementAt(), and size().=20 =20 =20 LDAPConnection=20 =20 Removed all bind() signatures which take String instead of=20 byte[] for password.=20 =20 Expires December 6, 2004 [Page 128]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Replaced Hashtable as parameter with Map in bind() and=20 getSaslBindProperties.=20 =20 The LDAP_PROPERTY_SDK is of type String rather than Float.=20 LDAP_PROPERTY_PROTOCOL is of type Integer.=20 =20 setInputStream and setOutputStream throw LDAPException.=20 =20 Removed setProperty.=20 =20 Added stopTLS.=20 =20 =20 LDAPCompareAttrNames=20 =20 Implements java.util.Comparator instead of LDAPEntryComparator.=20 =20 =20 LDAPConstraints=20 =20 Implements Cloneable.=20 =20 getServerControls renamed to getControls.=20 =20 setServerControls renamed to setControls.=20 =20 Added getProperty and setProperty.=20 =20 getClientControls and setClientControls removed.=20 =20 =20 LDAPControl=20 =20 Removed all references to "client controls".=20 =20 =20 LDAPEntryComparator=20 =20 Removed; LDAPCompareAttrNames implements java.util.Comparator=20 instead.=20 =20 =20 LDAPException=20 =20 Renamed errorCodeToString() to resultCodeToString().=20 =20 Renamed getLDAPResultCode () to getResultCode ().=20 =20 =20 LDAPListener=20 =20 =20 Expires December 6, 2004 [Page 129]=20 JAVA LDAP API April 2004=20 =20 =20 Renamed to LDAPMessageQueue.=20 =20 =20 LDAPMatchingRuleSchema=20 =20 Combined the two constructors with explicit field parameters.=20 =20 =20 LDAPModificationSet=20 =20 Removed (replaced with LDAPModification[] as parameter where=20 referenced).=20 =20 =20 LDAPResponseListener=20 =20 Renamed to LDAPResponseQueue.=20 =20 =20 LDAPRebind=20 =20 Renamed to LDAPAuthHandler.=20 =20 =20 LDAPRebindAuth=20 =20 Renamed to LDAPAuthProvider.=20 =20 =20 LDAPSchema=20 =20 Renamed getAttribute() to getAttributeSchema(),getAttributes()=20 to getAttributeSchemas(), getObjectClass() to=20 getObjectClassSchema(), getSyntax() to getSyntaxSchema(),=20 getSyntaxes() to getSyntaxSchemas(), getDITContentRule () to=20 getDITContentRuleSchema(), getDITContentRules() to=20 getDITContentRuleSchemas(), getDITStructureRule() to=20 getDITStructureRuleSchema(), getDITStructureRules() to=20 getDITStructureRuleSchemas(),getMatchingRule() to=20 getMatchingRuleSchema(), getMatchingRules() to=20 getMatchingRuleSchemas(), getMatchingRuleUse() to=20 getMatchingRuleUseSchema(),getMatchingRuleUses() to=20 getMatchingRuleUseSchemas(),getNameForm() to=20 getNameFormSchema(), getNameForms() to getNameFormSchemas().=20 =20 Added add(), modify(), remove(), and saveSchema().=20 =20 =20 LDAPSchemaElement=20 =20 Renamed getValue() to toString().=20 =20 =20 Expires December 6, 2004 [Page 130]=20 JAVA LDAP API April 2004=20 =20 =20 Changed getName() to getNames(), removed getAliases().=20 =20 Removed add(), modify(), and remove().=20 =20 =20 LDAPSearchConstraints=20 =20 Added constructor that takes LDAPConstraints as parameter.=20 =20 =20 LDAPSearchListener=20 =20 Renamed to LDAPSearchQueue.=20 =20 =20 LDAPSearchResults=20 =20 Does not implement Enumeration.=20 =20 Removed nextElement().=20 =20 Renamed hasMoreElements() to hasMore().=20 =20 Removed sort() (sorting can now be done with classes/interfaces=20 of the Collections framework now that LDAPAttributeSet=20 implements Set).=20 =20 =20 LDAPSocketFactory=20 =20 Renamed makeSocket() to createSocket().=20 =20 =20 LDAPUrl=20 =20 Implements Cloneable.=20 =20 Renamed getUrl() to toString().=20 =20 Added extensions to the constructor that takes all fields=20 explicitly.=20 =20 =20 All schema elements=20 =20 Constructors take a parameter "String[] names" instead of=20 "String name" and "String[] aliases".=20 =20 =20 Implementation Considerations=20 =20 =20 Expires December 6, 2004 [Page 131]=20 JAVA LDAP API April 2004=20 =20 =20 Removed the specification of package name for controls. The=20 package name may be specified in a follow-on document=20 describing various controls.=20 =20 Moved the package name up to section 1.=20 =20 Added Dependencies.=20 =20 =20 Serializability=20 =20 Made the following classes Serializable:=20 LDAPAttribute=20 LDAPAttributeSet=20 LDAPConstraints=20 LDAPControl=20 LDAPEntry=20 LDAPExtendedOperation=20 LDAPMessage=20 LDAPModification=20 LDAPSchema=20 LDAPSchemaElement=20 LDAPSearchListener=20 LDAPSearchResults=20 LDAPUrl=20 =20 =20 9.5 Changes from ldap-java-api-14.txt=20 =20 =20 LDAPAttributeSchema=20 =20 Changed isModifiable() to isUserModifiable()=20 =20 =20 LDAPConnection=20 =20 Added bind() signatures that take byte[] as password parameter,=20 removed bind() signatures which do not take a version parameter=20 =20 Use Hashtable, not Properties, in all SASL bind signatures=20 =20 Removed setSearchConstraints()=20 =20 rename() takes newParentdn before deleteOldRdn (one of the=20 eight signatures had the order reversed)=20 =20 =20 LDAPException=20 =20 Defined how the toString method overrides the default toString=20 behavior=20 =20 Expires December 6, 2004 [Page 132]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 LDAPMatchingRuleSchema=20 =20 Changed return of getSyntaxString from String[] to String=20 =20 =20 LDAPUrl=20 =20 Removed constructor signature which takes "secure" as a=20 parameter=20 =20 Removed isSecure()=20 =20 getFilter() returns null instead of "(objectclass=3D*)" if no=20 filter was specified=20 =20 =20 Examples=20 =20 Use SASL to bind in synchronous ModifyEmail example and TLS in=20 asynchronous ModifyEmail example (instead of simple bind)=20 =20 =20 General=20 =20 Put methods of LDAPAttributeSchema in alphabetical order=20 =20 Clarifications and editorial changes=20 =20 =20 =20 =20 9.6 Changes from ldap-java-api-13.txt=20 =20 =20 Notice of disconnection, Invalid responses, Level of compatibility=20 =20 New section=20 =20 =20 Result codes=20 =20 Added INVALID_RESPONSE, AMBIGUOUS_RESPONSE=20 Removed PARAM_ERROR=20 =20 =20 LDAPConnection=20 =20 Removed getAuthenticationPassword()=20 Added bind() signatures that take a byte array for password=20 bind() signatures for SASL take an authzId parameter=20 =20 Expires December 6, 2004 [Page 133]=20 JAVA LDAP API April 2004=20 =20 =20 disconnect() may take an LDAPConstraints parameter=20 read() throws LDAPException with AMBIGUOUS_RESPONSE if there is=20 more than one result=20 =20 =20 LDAPConstraints=20 =20 Removed getReferralHandler=20 =20 =20 LDAPRebindAuth=20 =20 Added a signature of the constructor which takes byte[] as=20 parameter=20 getPassword() returns byte[] instead of String=20 =20 =20 LDAPReferralException=20 =20 Clarified that getReferrals() must return LDAP URL strings with=20 the scope rewritten if necessary (for SearchResultReferences on=20 search continuation).=20 =20 =20 LDAPDN=20 =20 Added normalize() and isValid().=20 =20 =20 LDAPUnsolicitedNotificationListener=20 =20 The argument to messageReceived() is LDAPExtendedResponse and=20 not LDAPMessage.=20 =20 =20 Security Considerations=20 =20 Added implementation guidelines=20 =20 =20 General=20 =20 All classes and methods in alphabetical order=20 Many clarifications and editorial changes=20 =20 =20 9.7 Changes from ldap-java-api-12.txt=20 =20 =20 Abstract=20 =20 =20 Expires December 6, 2004 [Page 134]=20 JAVA LDAP API April 2004=20 =20 =20 Removed references to RFC 1823 and to an earlier draft on an=20 asynchronous interface.=20 =20 =20 LDAPConnection=20 =20 Under clone(), added a listing of which methods affect an=20 individual clone and which ones affect all related clones.=20 =20 =20 LDAPException=20 =20 Can take Throwable as root exception argument in an additional=20 constructor signature. Added getCause() to return the root=20 exception. Removed reference to LDAP_PARTIAL_RESULTS among=20 result codes.=20 =20 =20 LDAPBind=20 =20 bind() throws LDAPReferralException instead of LDAPException.=20 =20 =20 LDAPReferralException=20 =20 Can take Throwable as root exception argument instead of=20 LDAPException. getFailureException() was removed and replaced=20 by getCause() in LDAPException. Added getFailedReferral() and=20 setFailedReferral().=20 =20 =20 LDAPControl=20 =20 Removed newInstance(). An implementation of the API can=20 instantiate a control using the LDAPControl constructor.=20 Removed a sentence saying that LDAPv2 doesn't support controls.=20 =20 =20 Referral handling=20 =20 Added section outlining the handling of exceptions on=20 referrals.=20 =20 =20 References=20 =20 Added references to RFCs 2222 and 2830.=20 =20 =20 Host names=20 =20 May be IPv6 references as well as hostnames or IPv4 addresses.=20 =20 Expires December 6, 2004 [Page 135]=20 JAVA LDAP API April 2004=20 =20 =20 =20 =20 LDAPMessage=20 =20 Restored the values of the message types to correspond to the=20 message type values in ldap-java-api-11.txt.=20 =20 =20 LDAPEntry=20 =20 getAttribute returns a single attribute.=20 =20 =20 Unsolicited notifications in LDAPConnection=20 =20 Removed getUnsolicitedNotifications and=20 setUnsolicitedNotifications. Added=20 addUnsolicitedNotificationListener and=20 removeUnsolicitedNotificationListener. Added interface=20 LDAPUnsolicitedNotificationListener.=20 =20 =20 9.8 Changes from ldap-java-api-11.txt=20 =20 =20 LDAPConnection=20 =20 Eliminated the interfaces (LDAPv2 and LDAPv3) that=20 LDAPConnection implemented.=20 =20 Eliminated setOption and getOption (there are corresponding=20 properties in LDAPConstraints and LDAPSearchConstraints).=20 =20 Removed the signatures of connect which took DN, password, and=20 protocol version as arguments. The previous signatures were=20 utility methods that combined connect and bind.=20 =20 Added a signature of extendedOperation which takes=20 LDAPConstraints as argument.=20 =20 Added isTLS.=20 =20 Added getProtocolVersion.=20 =20 Added signatures of abandon which take LDAPConstraints as=20 argument.=20 =20 extendedOperation returns LDAPExtendedResponse, not=20 LDAPExtendedOperation.=20 =20 Added signatures of SASL bind that take LDAPConstraints as=20 argument.=20 =20 Expires December 6, 2004 [Page 136]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Added getSaslBindProperties.=20 =20 Added getSaslBindCallbackHandler.=20 =20 Added getUnsolicitedNotifications and=20 setUnsolicitedNotifications.=20 =20 The default protocol version to bind with is LDAPv3, not=20 LDAPv2.=20 =20 Constants: LDAP_DEREF_NEVER, etc changed to DEREF_NEVER, etc.=20 Values of DEREF_SEARCHING and DEREF_FINDING corrected to those=20 of RFC 2251. The values are now defined in=20 LDAPSearchConstraints instead of in LDAPConnection.=20 =20 =20 LDAPControl=20 =20 Added setValue.=20 =20 =20 LDAPExtendedOperation=20 =20 Added setValue.=20 =20 =20 LDAPSearchResultReference=20 =20 Changed getURLs to getReferrals, which returns String[].=20 =20 =20 LDAPUrl=20 =20 Added method isSecure.=20 =20 Added constructors that take a boolean for isSecure.=20 =20 =20 LDAPReferralException=20 =20 Added getReferralFailureException.=20 Changed getURLs to getReferrals, which returns String[].=20 =20 =20 LDAPConstraints=20 =20 Takes a new interface LDAPReferralHandler as parameter, instead=20 of LDAPBind and LDAPRebind.=20 Changed getReferrals to getReferralFollowing.=20 Changed setReferrals to setReferralFollowing.=20 =20 =20 Expires December 6, 2004 [Page 137]=20 JAVA LDAP API April 2004=20 =20 =20 =20 LDAPReferralHandler=20 =20 New common ancestor to LDAPBind and LDAPRebind.=20 =20 =20 LDAPListener=20 =20 New common ancestor to LDAPSearchListener and=20 LDAPResponseListener.=20 =20 =20 LDAPSearchListener=20 =20 Implements LDAPListener.=20 =20 Added signature of isResponseReceived and of getResponse that=20 takes a message ID as parameter.=20 =20 Added isComplete.=20 =20 =20 LDAPResponseListener=20 =20 Implements LDAPListener.=20 =20 Added signatures isResponseReceived and getResponse that take a=20 message ID as parameter.=20 =20 =20 LDAPBind=20 =20 Changed the signature of bind to return LDAPConnection instead=20 of void, and take an LDAP URL string list as argument.=20 =20 =20 LDAPException=20 =20 Defined the values of symbolic result codes generated by the=20 interface. Added a constructor that takes matchedDN as=20 parameter.=20 =20 =20 LDAPMessage=20 =20 Redefined the values of the message types to correspond to the=20 message type values in [LDAPv3].=20 =20 =20 9.9 Changes from ldap-java-api-10.txt=20 =20 Overview of the LDAP model=20 =20 Expires December 6, 2004 [Page 138]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Allowed for character set conversion from/to T.61 (in addition=20 to UTF-8).=20 =20 LDAPConnection=20 =20 Added startTLS. Added STRING_FORMAT option to setOption. Added=20 numerical values to options in setOption and search. Changed=20 REFERRALS_AUTHENTICATION to REFERRALS_REBIND_PROC. Clarified=20 that getAuthenticationPassword returns null if no simple bind=20 has been performed. Added asynchronous methods (from [TLS]). =20 =20 LDAPConstraints=20 =20 Default for setHopLimit is 10, not 5.=20 =20 =20 LDAPUrl=20 =20 Added getScope and getExtensions.=20 =20 =20 Schema classes=20 =20 Added parameters to constructors (aliases, obsolete,=20 collective).=20 =20 =20 Various classes=20 =20 Removed all "synchronized" qualifier on methods. Added a=20 statement that implementations should ensure thread-safety.=20 =20 =20 9.10 Changes from ldap-java-api-09.txt=20 =20 =20 Overview of LDAP API use=20 =20 Clarifications were added on the behavior of the SDK for null=20 values of LDAPConstraints and for a DN.=20 =20 =20 LDAPAttributeSet=20 =20 Return type of getAttribute is LDAPAttribute, not=20 LDAPAttribute[].=20 =20 =20 LDAPV2=20 =20 =20 Expires December 6, 2004 [Page 139]=20 JAVA LDAP API April 2004=20 =20 =20 Added convenience method of add that does not take=20 LDAPConstraints, added read method that does take=20 LDAPSearchConstraints.=20 =20 =20 Error Codes=20 =20 Changed to Result Codes. Added TLS_NOT_SUPPORTED.=20 =20 =20 LDAPSearchResults=20 =20 Clarified in declaration that it implements Enumeration.=20 =20 =20 LDAPV3=20 =20 Added constants NO_ATTRS and ALL_USER_ATTRS.=20 =20 =20 Schema classes=20 =20 Added LDAPDITContentRuleSchema, LDAPDITStructureRuleSchema,=20 LDAPMatchingRuleUseSchema, LDAPNameFormSchema, LDAPSyntaxSchema.=20 =20 =20 9.11 Changes from ldap-java-api-08.txt=20 =20 =20 Standards track=20 =20 Added intended category to first page header.=20 =20 SASL references=20 =20 Removed all references to a Java SASL internet draft.=20 =20 LDAPv2=20 =20 Removed static methods search(LDAPUrl url). The methods are=20 still present in LDAPConnection.=20 =20 =20 9.12 Changes from ldap-java-api-07.txt=20 =20 =20 LDAPAttributeSchema=20 =20 Removed getAliases() because it is already defined in the=20 superior class LDAPSchemaElement. Removed getSyntax() which=20 returned an integer.=20 =20 =20 Expires December 6, 2004 [Page 140]=20 JAVA LDAP API April 2004=20 =20 =20 LDAPConnection=20 =20 Added getAuthenticationMethod().=20 =20 LDAPSchemaElement=20 =20 Changed getOID() to getID().=20 =20 =20 9.13 Changes from ldap-java-api-06.txt=20 =20 =20 LDAPAttributeSchema=20 =20 Added a constructor that takes the attribute syntax as a String,=20 an optional superior attribute type, and an optional list of=20 aliases. Removed previous constructor.=20 Added getSuperior()and getSyntaxString().=20 =20 =20 LDAPConnection=20 =20 Added getInputStream()getOutputStream(), setInputStream()=20 (Error! Reference source not found.), and setOutputStream().=20 They are used when establishing a security layer with SASL, and=20 may also be used to interpose a proxy.=20 =20 =20 LDAPDN=20 =20 Added equals().=20 =20 =20 LDAPException=20 =20 Added additional error codes defined in [URL].=20 =20 =20 LDAPMatchingRuleSchema=20 =20 Added a constructor that takes the attribute syntax as a String=20 and an optional list of aliases. Removed previous constructor.=20 =20 =20 LDAPObjectClassSchema=20 =20 Added a constructor that takes an array of superior object class=20 names, a type (ABSTRACT, AUXILIARY, or STRUCTURAL), and an=20 optional list of aliases. Removed previous constructor.=20 Added getSuperiors()and getType(). Removed getSuperior().=20 =20 =20 =20 Expires December 6, 2004 [Page 141]=20 JAVA LDAP API April 2004=20 =20 =20 LDAPSchemaElement=20 =20 Added overloaded methods of add, remove, and modify which take a=20 DN as parameter, for specifying where in the DIT to determine=20 the subschemaSubentry for the modification.=20 Added getAliases(), getQualifier(), getQualiferNames(),=20 isObsolete(), and setQualifier().=20 =20 =20 9.14 Changes from ldap-java-api-05.txt=20 =20 =20 LDAPConnection=20 =20 Distinguished between getConstraints() and=20 getSearchConstraints(), and between setConstraints() and=20 setSearchConstraints().=20 =20 =20 LDAPConstraints=20 =20 LDAPBind and LDAPRebind should not be specified in the same=20 constructor. Added setClientControls().=20 =20 =20 LDAPSearchConstraints=20 =20 LDAPBind and LDAPRebind should not be specified in the same=20 constructor.=20 =20 =20 LDAPControl=20 =20 newInstance() is now static.=20 =20 =20 LDAPv3=20 =20 Changed the signature of the bind() methods to match the Java=20 SASL Internet Draft.=20 =20 =20 9.15 Changes from ldap-java-api-04.txt=20 =20 =20 LDAPAttribute=20 =20 Added getByteValueArray() and getStringValueArray().=20 =20 =20 LDAPCompareAttrNames=20 =20 =20 Expires December 6, 2004 [Page 142]=20 JAVA LDAP API April 2004=20 =20 =20 Added getLocale() and setLocale().=20 =20 =20 LDAPSchemaElement=20 =20 Added modify().=20 =20 =20 LDAPSchemaElement=20 =20 Added fetchSchema(LDAPConnection, String).=20 =20 =20 9.16 Changes from ldap-java-api-03.txt=20 =20 =20 LDAPBind=20 =20 New interface, to support sophisticated reauthentication=20 mechanisms.=20 =20 =20 LDAPControl=20 =20 Added methods register() and newInstance(), to support dynamic=20 registration and instantiation of server response controls.=20 =20 =20 LDAPConstraints=20 =20 Separated interface time limit from server search time limit.=20 Moved all search-only constraints to LDAPSearchConstraints.=20 =20 =20 LDAPRebind=20 =20 Reverted back to original name, instead of LDAPReauthentication=20 as it was in the previous draft.=20 =20 =20 LDAPRebindProc=20 =20 Reverted back from LDAPCredentials.=20 =20 =20 LDAPSearchConstraints=20 =20 Reinstated this class, to represent all constraints applicable=20 to a search. LDAPConstraints (which it extends) only represents=20 common constraints for all operations.=20 =20 LDAPSearchResults=20 =20 Expires December 6, 2004 [Page 143]=20 JAVA LDAP API April 2004=20 =20 =20 =20 Added getResponseControls().=20 =20 =20 LDAPv2=20 =20 Added abandon(). Separated interface time limit from server=20 search time limit. Changed authenticate() to bind().=20 =20 =20 LDAPv3=20 =20 Changed authenticate() to bind().=20 =20 =20 9.17 Changes from ldap-java-api-02.txt=20 =20 =20 LDAPSearchConstraints=20 =20 Renamed to LDAPConstraints, since it can be applied to=20 operations other than search.=20 =20 =20 LDAPRebind=20 =20 Renamed to LDAPReauthentication. Added a definition of its=20 single method.=20 =20 LDAPRebindProc=20 =20 Renamed to LDAPCredentials.=20 =20 =20 9.18 Changes from ldap-java-api-01.txt=20 =20 =20 LDAPAttribute=20 =20 Added a copy constructor.=20 Added support for subtypes, and for language subtypes in=20 particular.=20 =20 =20 LDAPAttributeSet=20 =20 LDAPAttributeSet implements Cloneable.=20 Added getSubset() for subtype support.=20 =20 =20 LDAPDN=20 =20 =20 Expires December 6, 2004 [Page 144]=20 JAVA LDAP API April 2004=20 =20 =20 Added support for escaping and unescaping an RDN.=20 =20 =20 LDAPException=20 =20 Added the SASL_BIND_IN_PROGRESS error code.=20 =20 =20 LDAPSearchResults=20 =20 Added getCount(), to report the number of results returned.=20 =20 =20 LDAPConnection=20 =20 Added a signature that passes LDAPConstraints to read(LDAPURL).=20 =20 =20 LDAPv2=20 =20 Added signatures that pass LDAPConstraints to the following=20 methods:=20 add()=20 compare()=20 modify()=20 read()=20 rename()=20 =20 LDAPv3=20 =20 Removed "Preferred Language", because it has been dropped from=20 the extension work.=20 Added a signature that passes LDAPConstraints to rename().=20 =20 =20 Expires December 6, 2004 [Page 145]=20 --=__PartB2933BDD.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__PartB2933BDD.0__=-- From ldapext-bounces@ietf.org Mon Jun 7 14:26:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03910 for ; Mon, 7 Jun 2004 14:26:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOl4-0007oY-3W; Mon, 07 Jun 2004 14:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOXy-0004cR-Ir for ldapext@megatron.ietf.org; Mon, 07 Jun 2004 14:08:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02707 for ; Mon, 7 Jun 2004 14:08:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOXx-0001Om-Gx for ldapext@ietf.org; Mon, 07 Jun 2004 14:08:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOX0-0000qf-00 for ldapext@ietf.org; Mon, 07 Jun 2004 14:07:34 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BXOW2-0007YS-00 for ldapext@ietf.org; Mon, 07 Jun 2004 14:06:34 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 07 Jun 2004 12:06:03 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 07 Jun 2004 12:05:47 -0600 From: "Steve Sonntag" To: , "Steve Sonntag" Subject: Re: [ldapext] draft-ietf-ldapext-ldap-java-api-19.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I will be out of town until 21 June, so I cannot answer any questions until then. Thanks -Steve Sonntag >>> "Steve Sonntag" 07-Jun-04 9:03:41 AM >>> Draft 19 of the java ldap API has been submitted (attached). We have tried to address all the comments and suggestions made against the previous draft. Any review is appreciated. -Steve Sonntag _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jun 8 13:02:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08348 for ; Tue, 8 Jun 2004 13:02:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjom-0001rt-C4; Tue, 08 Jun 2004 12:51:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjRz-0001pC-9H for ldapext@megatron.ietf.org; Tue, 08 Jun 2004 12:27:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06357 for ; Tue, 8 Jun 2004 12:27:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXjRx-0004b2-Un for ldapext@ietf.org; Tue, 08 Jun 2004 12:27:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXjQs-0003li-00 for ldapext@ietf.org; Tue, 08 Jun 2004 12:26:39 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BXjPy-0002xM-00 for ldapext@ietf.org; Tue, 08 Jun 2004 12:25:43 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i58GPVqf075195; Tue, 8 Jun 2004 16:25:32 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040608091041.048a6f70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 08 Jun 2004 09:25:47 -0700 To: andrew.sciberras@adacel.com.au, steven.legg@adacel.com.au From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org, xeddev@adacel.com Subject: [ldapext] LDIFv2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Andrew, I'm a bit concerned by the use of whitespace to indicate continuations in LDIFv2 XML values, especially in the last line of the value. I think this choice will make it especially hard on those who create LDIF by hand, often by example (instead of by reading the specification), to get it right. I suggest instead LDIFv2 that looks like: dn: cn=Andrew Sciberras,o=Adacel,c=AU objectClass: organizationalPerson attr;transfer-rxer>: > > > 250 Bay Street > Brighton Victoria 3186 > Australia > >sn: Sciberras I note as well that nothing in this extension is XML specific, the extension is useful for incorporation of values which are represented in any multi-line format. Kurt PS: your I-D seems to be encoded using quotable-printable... _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 9 11:54:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23730 for ; Wed, 9 Jun 2004 11:54:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4x1-0000ts-Du; Wed, 09 Jun 2004 11:25:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4no-0002NJ-MT for ldapext@megatron.ietf.org; Wed, 09 Jun 2004 11:15:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19443 for ; Wed, 9 Jun 2004 11:15:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY4nn-0007NG-Pk for ldapext@ietf.org; Wed, 09 Jun 2004 11:15:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY4mA-0005hN-00 for ldapext@ietf.org; Wed, 09 Jun 2004 11:14:02 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BY4kb-0003L3-00 for ldapext@ietf.org; Wed, 09 Jun 2004 11:12:25 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 09 Jun 2004 09:11:55 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 09 Jun 2004 09:11:38 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] subtree search with glue entries X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit All, Assume a server populated with these entries: dc=com (glue) dc=example,dc=com (context prefix) dc=org (context prefix) When a one-level or subtree search is rooted at the DIT root (empty RDN sequence)*, how should dc=com be treated? 1.1) It should not be returned 1.2) A search result reference should be generated using the superior referral should be returned When a subtree search is rooted at the DIT root (empty RDN sequence)*, how should dc=example,dc=com (and subordinates) be treated? 2.1) They should not be returned 2.2) They should be returned I assume the answers are 1.1 and 2.1, but am not sure. Does anyone else have experience here? Jim *Note that while some LDAP servers don't support this, it is a feature of X.511 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 9 13:53:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03882 for ; Wed, 9 Jun 2004 13:53:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY6sk-0003Rd-Dm; Wed, 09 Jun 2004 13:28:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY66q-0006nS-0z for ldapext@megatron.ietf.org; Wed, 09 Jun 2004 12:39:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27042 for ; Wed, 9 Jun 2004 12:39:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY66p-0003Sv-0K for ldapext@ietf.org; Wed, 09 Jun 2004 12:39:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY658-0002DU-00 for ldapext@ietf.org; Wed, 09 Jun 2004 12:37:43 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BY629-0000QU-00 for ldapext@ietf.org; Wed, 09 Jun 2004 12:34:37 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i59GYaqf083770; Wed, 9 Jun 2004 16:34:36 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040609090234.04343510@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 09 Jun 2004 09:34:24 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] subtree search with glue entries In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 08:11 AM 6/9/2004, Jim Sermersheim wrote: >All, > >Assume a server populated with these entries: > >dc=com (glue) >dc=example,dc=com (context prefix) >dc=org (context prefix) > >When a one-level or subtree search is rooted at the DIT root (empty RDN >sequence)*, how should dc=com be treated? > >1.1) It should not be returned >1.2) A search result reference should be generated using the superior >referral should be returned I would argue that since server does not hold the baseObject of the search, it should return a referral to the server which holds it. That server, in response to the client's search, return any objects it holds in scope and a continuation back to this server for dc=example,dc=com with an appropriate scope: baseObject (if original scope was one-level) or subtree (if original scope was oneLevel). >When a subtree search is rooted at the DIT root (empty RDN sequence)*, >how should dc=example,dc=com (and subordinates) be treated? The server should refer the client (using a search referral) to a server which has superior knowledge. >2.1) They should not be returned >2.2) They should be returned > >I assume the answers are 1.1 and 2.1, but am not sure. Does anyone else >have experience here? Yes. In OpenLDAP, one can configure a server to have root knowledge. That is, to have knowledge of where all top-level naming contexts are held. The OpenLDAP Root Service [RFC3088] operates in this manner. >*Note that while some LDAP servers don't support this, it is a feature >of X.511 In LDAP, a number of implementations (including OpenLDAP, if so (mis)configured) will treat a non-baseObject scoped search at the root ("") as a like-scoped search at a context prefix held by the server. The idea, I guess, is to "friendly" or, more specifically, to avoid client configuration of an appropriate search base (or implementation of namingContext/enhancedSearchGuide discovery). Because of this, it makes build any kind of "global" directory quite difficult. (There are, of course, other reasons why building "global" directories is difficult.) Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 9 13:56:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04380 for ; Wed, 9 Jun 2004 13:56:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY70y-0006db-LT; Wed, 09 Jun 2004 13:37:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY6R3-00079T-9O for ldapext@megatron.ietf.org; Wed, 09 Jun 2004 13:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28855 for ; Wed, 9 Jun 2004 13:00:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY6Qu-0003DI-5n for ldapext@ietf.org; Wed, 09 Jun 2004 13:00:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY6PM-0002GE-00 for ldapext@ietf.org; Wed, 09 Jun 2004 12:58:36 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BY6NQ-0000Wp-00 for ldapext@ietf.org; Wed, 09 Jun 2004 12:56:36 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i59GuZqf083866; Wed, 9 Jun 2004 16:56:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040609095539.04368c20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 09 Jun 2004 09:56:50 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] subtree search with glue entries In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 09:52 AM 6/9/2004, Jim Sermersheim wrote: >So if I can paraphrase: The simple answer is that since this server is >not a top-level DSA, a search based at the root should return a referral >to a higher DSA. Yes. >Or am I oversimplifying it? No. >>>> "Kurt D. Zeilenga" 6/9/04 10:34:24 AM >>> >At 08:11 AM 6/9/2004, Jim Sermersheim wrote: >>All, >> >>Assume a server populated with these entries: >> >>dc=com (glue) >>dc=example,dc=com (context prefix) >>dc=org (context prefix) >> >>When a one-level or subtree search is rooted at the DIT root (empty >RDN >>sequence)*, how should dc=com be treated? >> >>1.1) It should not be returned >>1.2) A search result reference should be generated using the superior >>referral should be returned > >I would argue that since server does not hold the baseObject of the >search, it should return a referral to the server which holds it. >That server, in response to the client's search, return any objects >it holds in scope and a continuation back to this server for >dc=example,dc=com with an appropriate scope: baseObject (if original >scope was one-level) or subtree (if original scope was oneLevel). > >>When a subtree search is rooted at the DIT root (empty RDN >sequence)*, >>how should dc=example,dc=com (and subordinates) be treated? > >The server should refer the client (using a search referral) to >a server which has superior knowledge. > >>2.1) They should not be returned >>2.2) They should be returned >> >>I assume the answers are 1.1 and 2.1, but am not sure. Does anyone >else >>have experience here? > >Yes. In OpenLDAP, one can configure a server to have root knowledge. >That is, to have knowledge of where all top-level naming contexts >are held. The OpenLDAP Root Service [RFC3088] operates in this >manner. > >>*Note that while some LDAP servers don't support this, it is a >feature >>of X.511 > >In LDAP, a number of implementations (including OpenLDAP, if so >(mis)configured) >will treat a non-baseObject scoped search at the root ("") as a >like-scoped >search at a context prefix held by the server. The idea, I guess, is >to >"friendly" or, more specifically, to avoid client configuration of an >appropriate search base (or implementation of >namingContext/enhancedSearchGuide >discovery). > >Because of this, it makes build any kind of "global" directory quite >difficult. (There are, of course, other reasons why building "global" >directories is difficult.) > >Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 9 13:58:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04486 for ; Wed, 9 Jun 2004 13:58:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY73c-00085X-Pu; Wed, 09 Jun 2004 13:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY6bx-0002z4-IK for ldapext@megatron.ietf.org; Wed, 09 Jun 2004 13:11:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29358 for ; Wed, 9 Jun 2004 13:11:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY6bw-0003ic-Bd for ldapext@ietf.org; Wed, 09 Jun 2004 13:11:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY6Yk-0001is-00 for ldapext@ietf.org; Wed, 09 Jun 2004 13:08:18 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BY6X1-0000fF-00 for ldapext@ietf.org; Wed, 09 Jun 2004 13:06:31 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 09 Jun 2004 11:06:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 09 Jun 2004 11:05:39 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] subtree search with glue entries Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I should have said a search based at the root which is not a read of the root DSE. >>> "Kurt D. Zeilenga" 6/9/04 10:56:50 AM >>> At 09:52 AM 6/9/2004, Jim Sermersheim wrote: >So if I can paraphrase: The simple answer is that since this server is >not a top-level DSA, a search based at the root should return a referral >to a higher DSA. Yes. >Or am I oversimplifying it? No. >>>> "Kurt D. Zeilenga" 6/9/04 10:34:24 AM >>> >At 08:11 AM 6/9/2004, Jim Sermersheim wrote: >>All, >> >>Assume a server populated with these entries: >> >>dc=com (glue) >>dc=example,dc=com (context prefix) >>dc=org (context prefix) >> >>When a one-level or subtree search is rooted at the DIT root (empty >RDN >>sequence)*, how should dc=com be treated? >> >>1.1) It should not be returned >>1.2) A search result reference should be generated using the superior >>referral should be returned > >I would argue that since server does not hold the baseObject of the >search, it should return a referral to the server which holds it. >That server, in response to the client's search, return any objects >it holds in scope and a continuation back to this server for >dc=example,dc=com with an appropriate scope: baseObject (if original >scope was one-level) or subtree (if original scope was oneLevel). > >>When a subtree search is rooted at the DIT root (empty RDN >sequence)*, >>how should dc=example,dc=com (and subordinates) be treated? > >The server should refer the client (using a search referral) to >a server which has superior knowledge. > >>2.1) They should not be returned >>2.2) They should be returned >> >>I assume the answers are 1.1 and 2.1, but am not sure. Does anyone >else >>have experience here? > >Yes. In OpenLDAP, one can configure a server to have root knowledge. >That is, to have knowledge of where all top-level naming contexts >are held. The OpenLDAP Root Service [RFC3088] operates in this >manner. > >>*Note that while some LDAP servers don't support this, it is a >feature >>of X.511 > >In LDAP, a number of implementations (including OpenLDAP, if so >(mis)configured) >will treat a non-baseObject scoped search at the root ("") as a >like-scoped >search at a context prefix held by the server. The idea, I guess, is >to >"friendly" or, more specifically, to avoid client configuration of an >appropriate search base (or implementation of >namingContext/enhancedSearchGuide >discovery). > >Because of this, it makes build any kind of "global" directory quite >difficult. (There are, of course, other reasons why building "global" >directories is difficult.) > >Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 9 14:00:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04858 for ; Wed, 9 Jun 2004 14:00:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY73u-0008ID-MY; Wed, 09 Jun 2004 13:40:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY6dl-0003zT-Nm for ldapext@megatron.ietf.org; Wed, 09 Jun 2004 13:13:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29589 for ; Wed, 9 Jun 2004 13:13:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY6dk-0004xt-Om for ldapext@ietf.org; Wed, 09 Jun 2004 13:13:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY6bK-0003c1-00 for ldapext@ietf.org; Wed, 09 Jun 2004 13:10:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BY6Y8-00010w-00 for ldapext@ietf.org; Wed, 09 Jun 2004 13:07:40 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BY6Kg-0006uY-RN for ldapext@ietf.org; Wed, 09 Jun 2004 12:53:46 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 09 Jun 2004 10:53:13 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 09 Jun 2004 10:52:52 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] subtree search with glue entries Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit So if I can paraphrase: The simple answer is that since this server is not a top-level DSA, a search based at the root should return a referral to a higher DSA. Or am I oversimplifying it? >>> "Kurt D. Zeilenga" 6/9/04 10:34:24 AM >>> At 08:11 AM 6/9/2004, Jim Sermersheim wrote: >All, > >Assume a server populated with these entries: > >dc=com (glue) >dc=example,dc=com (context prefix) >dc=org (context prefix) > >When a one-level or subtree search is rooted at the DIT root (empty RDN >sequence)*, how should dc=com be treated? > >1.1) It should not be returned >1.2) A search result reference should be generated using the superior >referral should be returned I would argue that since server does not hold the baseObject of the search, it should return a referral to the server which holds it. That server, in response to the client's search, return any objects it holds in scope and a continuation back to this server for dc=example,dc=com with an appropriate scope: baseObject (if original scope was one-level) or subtree (if original scope was oneLevel). >When a subtree search is rooted at the DIT root (empty RDN sequence)*, >how should dc=example,dc=com (and subordinates) be treated? The server should refer the client (using a search referral) to a server which has superior knowledge. >2.1) They should not be returned >2.2) They should be returned > >I assume the answers are 1.1 and 2.1, but am not sure. Does anyone else >have experience here? Yes. In OpenLDAP, one can configure a server to have root knowledge. That is, to have knowledge of where all top-level naming contexts are held. The OpenLDAP Root Service [RFC3088] operates in this manner. >*Note that while some LDAP servers don't support this, it is a feature >of X.511 In LDAP, a number of implementations (including OpenLDAP, if so (mis)configured) will treat a non-baseObject scoped search at the root ("") as a like-scoped search at a context prefix held by the server. The idea, I guess, is to "friendly" or, more specifically, to avoid client configuration of an appropriate search base (or implementation of namingContext/enhancedSearchGuide discovery). Because of this, it makes build any kind of "global" directory quite difficult. (There are, of course, other reasons why building "global" directories is difficult.) Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 9 20:54:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07053 for ; Wed, 9 Jun 2004 20:54:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYDmp-0007ZN-VJ; Wed, 09 Jun 2004 20:51:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYDfv-0005U3-Mc for ldapext@megatron.ietf.org; Wed, 09 Jun 2004 20:44:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06578 for ; Wed, 9 Jun 2004 20:44:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYDft-0000X2-Bc for ldapext@ietf.org; Wed, 09 Jun 2004 20:44:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYDeo-0007PQ-00 for ldapext@ietf.org; Wed, 09 Jun 2004 20:43:02 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BYDdk-0005fr-00 for ldapext@ietf.org; Wed, 09 Jun 2004 20:41:56 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Thu, 10 Jun 2004 10:40:14 +1000 Received: (qmail 12007 invoked from network); 10 Jun 2004 00:41:24 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 10 Jun 2004 00:41:24 -0000 From: "Andrew Sciberras" To: "'Kurt D. Zeilenga'" Date: Thu, 10 Jun 2004 10:41:26 +1000 Message-ID: <089f01c44e83$aa773d40$a618200a@mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <6.0.1.1.0.20040608091041.048a6f70@127.0.0.1> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: steven.legg@adacel.com.au, ldapext@ietf.org, xeddev@adacel.com Subject: [ldapext] RE: [XEDDEV] LDIFv2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrew.sciberras@adacel.com List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >Andrew, Hi Kurt! Thanks for your comments. > >I'm a bit concerned by the use of whitespace to indicate >continuations in LDIFv2 XML values, especially in the last >line of the value. I think this choice will make it >especially hard on those who create LDIF by hand, often by >example (instead of by reading the specification), to >get it right. > I think you may be right and will incorporate this into my next draft. Below is your suggestion: dn: cn=Andrew Sciberras,o=Adacel,c=AU objectClass: organizationalPerson attr;transfer-rxer>: > > > 250 Bay Street > Brighton Victoria 3186 > Australia > >sn: Sciberras Incorporating your changes, this should actually look like this: dn: cn=Andrew Sciberras,o=Adacel,c=AU objectClass: organizationalPerson attr;transfer-rxer>: > > > 250 Bay Street > Brighton Victoria 3186 > Australia > > sn: Sciberras The difference (ignoring the fact that I've removed the 3D text after 'version=' ) is that "sn: Sciberras" is on a new line. And that the value ends with a line that contains '>' followed by a new line character/sequence. >I note as well that nothing in this extension is XML specific, >the extension is useful for incorporation of values which are >represented in any multi-line format. This is correct, assuming that values can all be represented in UTF8 excluding the NULL character. The intention of this draft is to specifically allow XML encoded information to be displayed in its encoding, rather than BASE64, because XML encodings are text based. Allowing this draft to be open-ended in what it applies to (i.e. including non text based encodings which meet the aforementioned requirements) will be counter to my original intention. From my point of view, a text encoding (i.e. XML) is more presentable than BASE64, which in turn is more presentable than non-ASCII character encoding. > >Kurt > Cheers, Andrew. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 10 12:21:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16669 for ; Thu, 10 Jun 2004 12:21:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYRuf-0008FM-ND; Thu, 10 Jun 2004 11:56:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYQaE-0001NG-9c for ldapext@megatron.ietf.org; Thu, 10 Jun 2004 10:31:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10914 for ; Thu, 10 Jun 2004 10:31:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYQaD-0002Jf-C1 for ldapext@ietf.org; Thu, 10 Jun 2004 10:31:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYQZ2-0001Qg-00 for ldapext@ietf.org; Thu, 10 Jun 2004 10:29:57 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BYQXU-0000xI-00 for ldapext@ietf.org; Thu, 10 Jun 2004 10:28:20 -0400 Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.30) id 1BYQXL-0000mS-Kn for ldapext@ietf.org; Thu, 10 Jun 2004 16:28:11 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1BYQXG-00044g-Lm; Thu, 10 Jun 2004 16:28:06 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BYQXF-0000y0-00; Thu, 10 Jun 2004 16:28:05 +0200 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Thu, 10 Jun 2004 16:28:05 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ldapext] New I-D: 'untypedObject' object class X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org People often make container entries like 'ou=people,dc=foo,dc=no' which use object class 'organizationalUnit' even though such entries do not represent real org.units at all. organizationalUnit just seems to get used because no better standard object class is available. So I've submitted a small Internet-Draft for an 'untypedObject' class to use instead: http://www.ietf.org/internet-drafts/draft-furuseth-ldap-untypedobject-00.txt Abstract: "This document defines an 'untypedObject' structural object class for the Lightweight Directory Access Protocol (LDAP) and X.500. This is useful for entries with no 'natural' choice of structural object class, e.g. if an entry must exist even though its contents are uninteresting." Please comment. For one thing, I'd like to know if I should rename it to e.g. 'subtreeBase', supposed to be used to the above purpose only, or generalize (object class 'something'?) for other purposes as well. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 11 08:22:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17492 for ; Fri, 11 Jun 2004 08:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkSm-0000eW-EN; Fri, 11 Jun 2004 07:44:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYSUT-00026v-DL for ldapext@megatron.ietf.org; Thu, 10 Jun 2004 12:33:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17496 for ; Thu, 10 Jun 2004 12:33:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYSUS-00059K-BL for ldapext@ietf.org; Thu, 10 Jun 2004 12:33:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYSTK-0004ID-00 for ldapext@ietf.org; Thu, 10 Jun 2004 12:32:11 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 1BYSS4-0003Ka-00 for ldapext@ietf.org; Thu, 10 Jun 2004 12:30:52 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5AGULQ1711660; Thu, 10 Jun 2004 12:30:22 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5AGVKc4139660; Thu, 10 Jun 2004 12:31:21 -0400 In-Reply-To: Subject: Re: [ldapext] New I-D: 'untypedObject' object class To: Hallvard B Furuseth X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Thu, 10 Jun 2004 11:30:18 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5.2|June 01, 2004) at 06/10/2004 11:30:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Some LDAP servers ship with a "container" object class. It might have come from Active Directory; at least they use it. Perhaps we could standardize container, rather than introducing a different objectclass. I know "container" is shipped with more than just Active Directory, but I don't know how wide-spread it is. John McMeeking Hallvard B Furuseth ldapext@ietf.org Sent by: cc ldapext-bounces@i etf.org Subject [ldapext] New I-D: 'untypedObject' object class 06/10/2004 09:28 AM People often make container entries like 'ou=people,dc=foo,dc=no' which use object class 'organizationalUnit' even though such entries do not represent real org.units at all. organizationalUnit just seems to get used because no better standard object class is available. So I've submitted a small Internet-Draft for an 'untypedObject' class to use instead: http://www.ietf.org/internet-drafts/draft-furuseth-ldap-untypedobject-00.txt Abstract: "This document defines an 'untypedObject' structural object class for the Lightweight Directory Access Protocol (LDAP) and X.500. This is useful for entries with no 'natural' choice of structural object class, e.g. if an entry must exist even though its contents are uninteresting." Please comment. For one thing, I'd like to know if I should rename it to e.g. 'subtreeBase', supposed to be used to the above purpose only, or generalize (object class 'something'?) for other purposes as well. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 11 08:29:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18224 for ; Fri, 11 Jun 2004 08:29:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkTA-0000oZ-Ia; Fri, 11 Jun 2004 07:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYTyN-0000gm-91 for ldapext@megatron.ietf.org; Thu, 10 Jun 2004 14:08:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21872 for ; Thu, 10 Jun 2004 14:08:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYTyM-0001Jk-2K for ldapext@ietf.org; Thu, 10 Jun 2004 14:08:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYTxL-0000r7-00 for ldapext@ietf.org; Thu, 10 Jun 2004 14:07:15 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BYTwW-0000Al-00 for ldapext@ietf.org; Thu, 10 Jun 2004 14:06:24 -0400 Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.30) id 1BYTwR-0002WL-N1; Thu, 10 Jun 2004 20:06:19 +0200 Received: from bombur.uio.no ([129.240.186.42]) by smtp.uio.no with esmtp (Exim 4.34) id 1BYTwN-0004n1-7n; Thu, 10 Jun 2004 20:06:15 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BYTwJ-0001Uy-00; Thu, 10 Jun 2004 20:06:11 +0200 From: Hallvard B Furuseth Message-Id: To: John McMeeking Subject: Re: [ldapext] New I-D: 'untypedObject' object class In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 10 Jun 2004 20:06:11 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org John McMeeking writes: > Some LDAP servers ship with a "container" object class. It might > have come from Active Directory; at least they use it. Perhaps we > could standardize container, rather than introducing a different > objectclass. I know "container" is shipped with more than just > Active Directory, but I don't know how wide-spread it is. Google found two different 'container's (+ 600 more results): IBM LDAP Directory Schema: ( 1.3.18.0.2.6.28 NAME 'container' DESC 'An object that can contain other objects.' SUP top STRUCTURAL MUST (cn) ) Active Directory: ( 1.2.840.113556.1.3.23 NAME 'container' SUP top STRUCTURAL MUST (cn) MAY (schemaVersion $ defaultClassStore) ) schemaVersion and defaultClassStore are Active Directory attributes; I'd prefer to avoid them. I could ask IBM to standardize their 'container'. I don't think anyone else should standardize their object class, in case they want to be able to change it someday. (Never mind that one isn't supposed to do that; people do it anyway.) I do miss some of the attributes I added, though. In particular 'description'. And 'enhancedSearchGuide' & 'searchGuide', at least in theory:-) I've never used them, but it looks like they should be present in objects intented to have children. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 11 08:30:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18311 for ; Fri, 11 Jun 2004 08:30:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkTB-0000ot-Q3; Fri, 11 Jun 2004 07:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYUcD-0006Ro-LN for ldapext@megatron.ietf.org; Thu, 10 Jun 2004 14:49:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23689 for ; Thu, 10 Jun 2004 14:49:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYUc9-0004dr-Nk for ldapext@ietf.org; Thu, 10 Jun 2004 14:49:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYUbC-00049X-00 for ldapext@ietf.org; Thu, 10 Jun 2004 14:48:26 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx with esmtp (Exim 4.12) id 1BYUa0-0003Cn-00 for ldapext@ietf.org; Thu, 10 Jun 2004 14:47:12 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5AIkfhF586358; Thu, 10 Jun 2004 14:46:41 -0400 Received: from d27ml001.rchland.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5AIlec4135472; Thu, 10 Jun 2004 14:47:40 -0400 In-Reply-To: Subject: Re: [ldapext] New I-D: 'untypedObject' object class To: Hallvard B Furuseth X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Thu, 10 Jun 2004 13:46:37 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5.2|June 01, 2004) at 06/10/2004 01:46:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I'm curious whether anybody else sees any particular benefit or drawback to borrowing container. If container really is provided by only those two vendors -- and I made no attempt to discover this -- it probably doesn't make any difference to most folks if a totally new object class is introduced and would avoid any potential conflict with the private definitions of this object class. On the other hand, if a meaningful number of people have borrowed "container" on their own and extended their server's schema, it might be advantageous. IBM and Microsoft would have to decide what to do if the definition is expanded to include description, searchGuide, and enhancedSearchGuide. John McMeeking Hallvard B Furuseth wrote on 06/10/2004 01:06:11 PM: > John McMeeking writes: > > > Some LDAP servers ship with a "container" object class. It might > > have come from Active Directory; at least they use it. Perhaps we > > could standardize container, rather than introducing a different > > objectclass. I know "container" is shipped with more than just > > Active Directory, but I don't know how wide-spread it is. > > Google found two different 'container's (+ 600 more results): > > IBM LDAP Directory Schema: > ( 1.3.18.0.2.6.28 NAME 'container' > DESC 'An object that can contain other objects.' > SUP top STRUCTURAL > MUST (cn) ) > > Active Directory: > ( 1.2.840.113556.1.3.23 NAME 'container' > SUP top STRUCTURAL > MUST (cn) > MAY (schemaVersion $ defaultClassStore) ) > > schemaVersion and defaultClassStore are Active Directory > attributes; I'd prefer to avoid them. > > I could ask IBM to standardize their 'container'. I don't think > anyone else should standardize their object class, in case they > want to be able to change it someday. (Never mind that one isn't > supposed to do that; people do it anyway.) > > I do miss some of the attributes I added, though. In particular > 'description'. And 'enhancedSearchGuide' & 'searchGuide', at > least in theory:-) I've never used them, but it looks like they > should be present in objects intented to have children. > > -- > Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 11 19:55:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15201 for ; Fri, 11 Jun 2004 19:55:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYvoR-0005bL-Ih; Fri, 11 Jun 2004 19:51:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYvnC-000521-Nf for ldapext@megatron.ietf.org; Fri, 11 Jun 2004 19:50:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14960 for ; Fri, 11 Jun 2004 19:50:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYvnA-00004y-WC for ldapext@ietf.org; Fri, 11 Jun 2004 19:50:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYvmG-0007RX-00 for ldapext@ietf.org; Fri, 11 Jun 2004 19:49:41 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BYvlJ-0006an-00 for ldapext@ietf.org; Fri, 11 Jun 2004 19:48:41 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 11 Jun 2004 17:48:11 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 11 Jun 2004 17:47:50 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] exclusions versus alreadySearched X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit All (especially anyone with X.500 experience) I'm trying to understand why the X.518 ChainingResults type has an alreadySearched field. If a DSA recieves a chained operation (which envelopes a search), and: - can service the entire search request, I see no need to report anything in the alreadySearched field. - returns a referral during name resolution, there is also no need - returns a referral while searching (equal to a search result referece), then the exclusions field of the referral holds the "alreadySearched" data. Thus I see no need for ChainingResults.alreadySearched. Am I missing something? Once I understand this and a few other isuues, I'll submit the chained operation I-D. I think I'll need to submit a control specification as well so we can start passing around information in the X.518 ContinuationReference (like exclusions) Thanks, Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 14 20:55:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17358 for ; Mon, 14 Jun 2004 20:55:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba1WA-0001Pj-9F; Mon, 14 Jun 2004 20:09:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba0ay-00027k-GZ for ldapext@megatron.ietf.org; Mon, 14 Jun 2004 19:10:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11353 for ; Mon, 14 Jun 2004 19:10:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba0aw-00054c-DO for ldapext@ietf.org; Mon, 14 Jun 2004 19:10:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba0a3-0004nN-00 for ldapext@ietf.org; Mon, 14 Jun 2004 19:09:32 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1Ba0Zl-0004VJ-00 for ldapext@ietf.org; Mon, 14 Jun 2004 19:09:13 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Tue, 15 Jun 2004 09:07:55 +1000 Received: (qmail 6586 invoked from network); 14 Jun 2004 23:08:40 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 14 Jun 2004 23:08:40 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5EN8bF01700; Tue, 15 Jun 2004 09:08:37 +1000 Message-ID: <40CE2FF4.8090803@adacel.com> Date: Tue, 15 Jun 2004 09:08:36 +1000 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] exclusions versus alreadySearched References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, I seem to recall the main value of the ChainingResults.alreadySearched field occurs when processing a nonSpecificSubordinateReference (nssr). Each DSA referenced by the nssr will hold one or more subordinate naming context under the nssr. The alreadySearched field in the ChainingResults allows the subordinate DSA to inform the superior DSA which subordinate naming contexts it holds and has provided results for in the chained search result. When using serial multi-chaining, this information can be passed on to subsequent subordinate DSAs through the ChainingArguments.exclusions field to reduce the work they need to carry out. - Mark. Jim Sermersheim wrote: > All (especially anyone with X.500 experience) > > I'm trying to understand why the X.518 ChainingResults type has an > alreadySearched field. > > If a DSA recieves a chained operation (which envelopes a search), and: > > - can service the entire search request, I see no need to report > anything in the alreadySearched field. > - returns a referral during name resolution, there is also no need > - returns a referral while searching (equal to a search result > referece), then the exclusions field of the referral holds the > "alreadySearched" data. > > Thus I see no need for ChainingResults.alreadySearched. Am I missing > something? > > Once I understand this and a few other isuues, I'll submit the chained > operation I-D. I think I'll need to submit a control specification as > well so we can start passing around information in the X.518 > ContinuationReference (like exclusions) > > Thanks, > Jim > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jun 15 00:24:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05822 for ; Tue, 15 Jun 2004 00:24:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba4tG-000417-PL; Mon, 14 Jun 2004 23:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba4bN-0007LJ-OU for ldapext@megatron.ietf.org; Mon, 14 Jun 2004 23:27:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02023 for ; Mon, 14 Jun 2004 23:27:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba4bL-00009G-OU for ldapext@ietf.org; Mon, 14 Jun 2004 23:27:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba4Vw-0006Vh-00 for ldapext@ietf.org; Mon, 14 Jun 2004 23:21:33 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1Ba4JB-0003uq-00 for ldapext@ietf.org; Mon, 14 Jun 2004 23:08:21 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 14 Jun 2004 21:08:09 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 14 Jun 2004 21:07:31 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] exclusions versus alreadySearched Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Ah, I see. That probably didn't occur to me as we've given up on NSSRs. >>> Mark Ennis 6/14/04 5:08:36 PM >>> Jim, I seem to recall the main value of the ChainingResults.alreadySearched field occurs when processing a nonSpecificSubordinateReference (nssr). Each DSA referenced by the nssr will hold one or more subordinate naming context under the nssr. The alreadySearched field in the ChainingResults allows the subordinate DSA to inform the superior DSA which subordinate naming contexts it holds and has provided results for in the chained search result. When using serial multi-chaining, this information can be passed on to subsequent subordinate DSAs through the ChainingArguments.exclusions field to reduce the work they need to carry out. - Mark. Jim Sermersheim wrote: > All (especially anyone with X.500 experience) > > I'm trying to understand why the X.518 ChainingResults type has an > alreadySearched field. > > If a DSA recieves a chained operation (which envelopes a search), and: > > - can service the entire search request, I see no need to report > anything in the alreadySearched field. > - returns a referral during name resolution, there is also no need > - returns a referral while searching (equal to a search result > referece), then the exclusions field of the referral holds the > "alreadySearched" data. > > Thus I see no need for ChainingResults.alreadySearched. Am I missing > something? > > Once I understand this and a few other isuues, I'll submit the chained > operation I-D. I think I'll need to submit a control specification as > well so we can start passing around information in the X.518 > ContinuationReference (like exclusions) > > Thanks, > Jim > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 21 15:46:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21528 for ; Mon, 21 Jun 2004 15:46:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUNu-0008Nn-52; Mon, 21 Jun 2004 15:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcT0O-0000Nj-2h for ldapext@megatron.ietf.org; Mon, 21 Jun 2004 13:54:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11981 for ; Mon, 21 Jun 2004 13:54:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcT0N-00018n-0A for ldapext@ietf.org; Mon, 21 Jun 2004 13:54:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcSzR-0000tf-00 for ldapext@ietf.org; Mon, 21 Jun 2004 13:53:54 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcSzB-0000NF-00 for ldapext@ietf.org; Mon, 21 Jun 2004 13:53:37 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 21 Jun 2004 11:55:12 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 21 Jun 2004 11:51:31 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartECCD7633.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ldapext] Chained Operation (control, extended op, or op?) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartECCD7633.0__= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit All, I'm attaching a not-ready-for-prime-time I-D which describes an LDAP chained operation. Following X.518, I described it as an operation (well, an extended operation) which contains the original message and some chaining arguments. Some of my peers here have repeatedly argued that there is no reason to define it as an extended operation, and that a control makes more sense. What do others think? I can go either way. If it's a control, I'd want to reconsider the targetObject and entryOnly fields. If the control holds these, and is sent as non-critical, and the receiving server doesn't support the control, the outcome will be erroneous. As an extended operation, we have two sets of resultCode, matchedDN, errorMessage, and referral. This can be resolved by chosing yet another solution: Create a whole new operation (don't use an extended operation). The new operation would not include the elements of LDAPResult (well, the resultCode might be nice, but referral and matchedDN is confusing). I'll publish once I get some feedback on this, and fix up some editorial issues. Jim --=__PartECCD7633.0__= Content-Type: text/plain; name="draft-sermersheim-ldap-chained-op-00.txt" Content-Disposition: attachment; filename="draft-sermersheim-ldap-chained-op-00.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA11981 Content-Transfer-Encoding: quoted-printable Personal Submission J. Sermersheim=20 Internet Draft =20 Document: draft-sermersheim-ldap-chained-op-00.txt Novell, Inc=20 Intended Category: Standard Track June 2004=20 =20 =20 LDAP Chained Operation=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Distribution of this memo is unlimited. Technical discussion of this=20 document will take place on the IETF LDAP Extensions Working Group=20 mailing list . Editorial comments may be sent to=20 the author .=20 =20 Abstract=20 =20 This document describes an Lightweight Directory Access Protocol=20 (LDAP)[RFC3377] operation in the form of an extended request and=20 response which allows a directory operation to be chained between=20 Directory Server Agents (DSAs). This is similar to the chained form=20 of operations described in Section 12.1 of [X.518].=20 =20 1. Introduction=20 =20 Many directory servers have the ability through the use of various=20 mechanisms to participate in a distributed directory model. A=20 distributed directory is one where the DIT is distributed over=20 multiple DSAs. One operation completion mechanism used by DSAs in a=20 distributed directory is chaining. Chaining is defined in [X.518],=20 and is the act of one DSA communicating a directory operation that=20 originated from a DUA to another DSA in a distributed directory.=20 Contrast this with the act of passing referrals (4.1.11 of=20 [RFC2251]) and SearchResultReferences (4.5.2 of [RFC2251]) back to=20 the client. Chaining may happen during the name resolution part of=20 =20 Sermersheim Internet-Draft - Exp. Dec 2004 Page 1 =0C LDAP Chained Operation=20 =20 an operation, or during other operations like search that apply to a=20 number of entries in a subtree.=20 =20 This document does not attempt to define the distributed directory=20 model, rather it defines the manner in which LDAP DSAs chain=20 requests. As such, the term chaining may apply to uni-chaining as=20 well as multi-chaining (see [X.518]) depending on the capabilities=20 and configuration of the DSAs. =20 =20 =20 2. Conventions=20 =20 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"=20 used in this document carry the meanings described in [RFC2119].=20 =20 All Basic Encoding Rules (BER)[BER] encodings follow the conventions=20 found in Section 5.1 of [RFC2251].=20 =20 =20 3 Chained Request=20 =20 The Chained Request is sent as an LDAP extended operation. The=20 requestName is . The requestValue is the BER [BER] encoding=20 of the following ChainedRequestValue ASN.1 definition.=20 =20 ChainedRequestValue ::=3D SEQUENCE {=20 chainingArguments ChainingArguments,=20 operationRequest OperationRequest }=20 =20 ChainingArguments ::=3D SEQUENCE {=20 targetObject [0] LDAPDN OPTIONAL,=20 traceInformation [1] ChainingTraceInformation,=20 entryOnly [2] BOOLEAN DEFAULT FALSE,=20 exclusions [3] Exclusions OPTIONAL }=20 =20 ChainingTraceInformation ::=3D SET OF LDAPURL=20 =20 Exclusions ::=3D SET OF RelativeLDAPDN=20 =20 OperationRequest ::=3D SEQUENCE {=20 Request ::=3D CHOICE {=20 bindRequest BindRequest,=20 searchRequest SearchRequest,=20 modifyRequest ModifyRequest,=20 addRequest AddRequest,=20 delRequest DelRequest,=20 modDNRequest ModifyDNRequest,=20 compareRequest CompareRequest,=20 extendedReq ExtendedRequest,=20 ... },=20 controls [0] Controls COPTIONAL }=20 =20 =20 Sermersheim Internet-Draft - Exp. Dec 2004 Page 2 =0C LDAP Chained Operation=20 =20 LDAPDN, RelativeLDAPDN, LDAPURL, BindRequest, SearchRequest,=20 ModifyRequest, AddRequest, DelRequest, ModifyDNRequest,=20 CompareRequest, ExtendedRequest and Controls are defined in=20 [RFC2251].=20 =20 3.1 ChainedRequestValue.chainingArguments=20 =20 In general, these fields assist in refining the original operation=20 as it is to be executed on the receiving DSA.=20 =20 3.1.1 ChainedRequestValue.chainingArguments.targetObject=20 =20 This field contains the new target (or base) DN for the operation. =20 =20 The sending DSA populates this under different scenarios including=20 the case where an alias has been dereferenced while resolving the=20 DN, and also the case where a referral carries a target name=20 different from the reference object that caused the referral. =20 =20 This field can be omitted only if it would be the the same value as=20 the object or base object parameter in the chained operation, in=20 which case its implied value is that value.=20 =20 The receiving DSA examines this field and (if present) uses it=20 rather than the base DN held in the operationRequest.=20 =20 3.1.2 ChainedRequestValue.chainingArguments.traceInformation=20 =20 This contains a set of URIs. Each value represents the address of a=20 DSA and DN that has already been contacted while trying to service=20 the operation.=20 =20 The sending DSA populates this with its own URI, and also the URIs=20 of any DSAs that have already been chained to.=20 =20 The receiving DSA examines this list of URIs and returns a=20 loopDetect (54) error if it finds that any of the addresses and DNs=20 in the listed URI=92s represent it=92s own.=20 =20 3.1.3 ChainedRequestValue.chainingArguments.entryOnly=20 =20 This is set to true when the operationRequest is a search, the scope=20 is singleLevel, and the ChainedRequest is being sent due to a search=20 result reference.=20 =20 When this is true, the receiving DSA treats the search operation (in=20 operationRequset) as having a scope of baseObject.=20 =20 3.1.4 ChainedRequestValue.chainingArguments.exclusions=20 =20 Each RelativeLDAPDN in this field identifies a subtree rooted at the=20 context prefix of a naming context subordinate to the targetObject=20 which should not be explored by the receiving DSA. See Section 10.9=20 =20 Sermersheim Internet-Draft - Exp. Dec 2004 Page 3 =0C LDAP Chained Operation=20 =20 (Exclusions) of [X.518] for more details. .=20 =20 Exclusions are used to minimize the number of duplicate entries=20 returned to the DSA initiating a chained operation.=20 =20 The RDNSequence is relative to the target object, and is not the=20 distinguished name of the context prefix.=20 =20 3.2 ChainedRequestValue.operationRequest=20 =20 This holds the original LDAP operation request. This is restricted=20 to a subset of all LDAP operation. Namely, the following LDAP=20 operation types are not allowed:=20 =20 - Abandon/Cancel operations. When an abandon or cancel operation=20 needs to be chained, it is sent to the remote DSA as-is. This is=20 because there is no need to track it for loop detection or pass on=20 any other information normally found in ChainingArguments.=20 =20 - Unbind. Again, there is no need to send chaining-related=20 information to a DSA to perform an unbind. If an unbind request is=20 unbinding a previously chained bind, the server servicing the=20 unbind request ensures that the unbind is properly chained.=20 =20 - Chained Operation. When a DSA receives a chained operation, and=20 must again chain that operation to a remote DSA, it sends a=20 ChainedRequest where the operationRequest is that of the incoming=20 operationRequest.=20 =20 =20 4 Chained Response=20 =20 The Chained Response is sent as an LDAP extended operation. The=20 requestName is omitted. The requestValue is the BER [BER] encoding=20 of the following ChainedResponse ASN.1 definition.=20 =20 ChainedResponse ::=3D SEQUENCE {=20 chainedResults ChainingResults,=20 operationResponse OperationResponse }=20 =20 ChainingResults ::=3D SEQUENCE {=20 exclusions [0] Exclusions OPTIONAL }=20 =20 OperationResponse ::=3D SEQUENCE {=20 Response ::=3D CHOICE {=20 bindResponse BindResponse,=20 searchResEntry SearchResultEntry,=20 searchResDone SearchResultDone,=20 searchResRef SearchResultReference,=20 modifyResponse ModifyResponse,=20 addResponse AddResponse,=20 delResponse DelResponse,=20 modDNResponse ModifyDNResponse,=20 =20 Sermersheim Internet-Draft - Exp. Dec 2004 Page 4 =0C LDAP Chained Operation=20 =20 compareResponse CompareResponse,=20 extendedResp ExtendedResponse,=20 ... },=20 controls [0] Controls COPTIONAL }=20 =20 BindResponse, SearchResultEntry, SearchResultDone,=20 SearchResultReference, ModifyResponse, AddResponse, DelResponse,=20 ModifyDNResponse, CompareResponse, ExtendedResponse, and Controls=20 are defined in [RFC2251].=20 =20 =20 4.1 ChainedResponse.chainedResults=20 =20 In general, this is used to convey additional information that may=20 needed in the even that the operation needs to be progressed=20 further.=20 =20 Editor=92s Note: I have created this as it=92s own type so that new=20 fields may be added later if needed. It may turn out that exclusions=20 is not needed at all, and thus this entire field can go away.=20 =20 4.1.1 ChainedResponse.chainedResults.exclusions=20 =20 If present, these name RDNs immediately subordinate to the=20 ChainedRequest.chainingArguments.targetObject which have been=20 processed as part of a chained search operation and therefore may be=20 excluded in subsequent subrequests.=20 =20 4.2 ChainedResponse.operationResponse=20 =20 This holds the response message tied to the=20 ChainedRequest.operationRequest.=20 =20 =20 =20 =20 6. Normative References=20 =20 [X.518]=20 ITU-T Rec. X.511, "The Directory: Abstract Service Definition",=20 1993.=20 =20 [RFC2119]=20 Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement=20 Levels", Internet Draft, March 1997. =20 Available as RFC2119.=20 =20 [RFC2251]=20 =20 Sermersheim Internet-Draft - Exp. Dec 2004 Page 5 =0C LDAP Chained Operation=20 =20 Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access=20 Protocol (v3)", Internet Standard, December, 1997. =20 Available as RFC2251.=20 =20 =20 7. Author's Address=20 =20 Jim Sermersheim=20 Novell, Inc.=20 1800 South Novell Place=20 Provo, Utah 84606, USA=20 jimse@novell.com=20 +1 801 861-3088=20 =20 Sermersheim Internet-Draft - Exp. Dec 2004 Page 6 =0C --=__PartECCD7633.0__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__PartECCD7633.0__=-- From ldapext-bounces@ietf.org Mon Jun 21 16:24:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25353 for ; Mon, 21 Jun 2004 16:24:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcV8g-0004df-2r; Mon, 21 Jun 2004 16:11:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUzd-0002CO-Te for ldapext@megatron.ietf.org; Mon, 21 Jun 2004 16:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23229 for ; Mon, 21 Jun 2004 16:02:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcUzc-0007C7-K9 for ldapext@ietf.org; Mon, 21 Jun 2004 16:02:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcUyT-0006sv-00 for ldapext@ietf.org; Mon, 21 Jun 2004 16:01:01 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BcUxj-0006cQ-00 for ldapext@ietf.org; Mon, 21 Jun 2004 16:00:16 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5LK09MC081796; Mon, 21 Jun 2004 20:00:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040621124840.04841808@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 21 Jun 2004 13:00:19 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I believe it best to design the chaining operation as an extended operation which "wraps" the chained operation (as well as provides additional "chaining" information), for three reasons: 1) separates chaining v. chained result information (e.g., resultCode, referrals, etc.), 2) separates chaining v. chained extension information (e.g., controls), 3) may facilitate mapping to X.518 operations At 10:51 AM 6/21/2004, Jim Sermersheim wrote: >All, > >I'm attaching a not-ready-for-prime-time I-D which describes an LDAP >chained operation. Following X.518, I described it as an operation >(well, an extended operation) which contains the original message and >some chaining arguments. Some of my peers here have repeatedly argued >that there is no reason to define it as an extended operation, and that >a control makes more sense. > >What do others think? I can go either way. > >If it's a control, I'd want to reconsider the targetObject and >entryOnly fields. If the control holds these, and is sent as >non-critical, and the receiving server doesn't support the control, the >outcome will be erroneous. > >As an extended operation, we have two sets of resultCode, matchedDN, >errorMessage, and referral. This can be resolved by chosing yet another >solution: Create a whole new operation (don't use an extended >operation). The new operation would not include the elements of >LDAPResult (well, the resultCode might be nice, but referral and >matchedDN is confusing). > >I'll publish once I get some feedback on this, and fix up some >editorial issues. > >Jim > >Content-Type: text/plain; name="draft-sermersheim-ldap-chained-op-00.txt" >Content-Disposition: attachment; > filename="draft-sermersheim-ldap-chained-op-00.txt" >X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA11981 > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 21 16:39:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26487 for ; Mon, 21 Jun 2004 16:39:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcVOk-00087g-Qc; Mon, 21 Jun 2004 16:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcVD3-0005JS-1w for ldapext@megatron.ietf.org; Mon, 21 Jun 2004 16:16:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24775 for ; Mon, 21 Jun 2004 16:16:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcVD1-0003gY-Ot for ldapext@ietf.org; Mon, 21 Jun 2004 16:16:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcVCO-0003P2-00 for ldapext@ietf.org; Mon, 21 Jun 2004 16:15:25 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BcVBU-00034L-00 for ldapext@ietf.org; Mon, 21 Jun 2004 16:14:28 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5LKESMC081972; Mon, 21 Jun 2004 20:14:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040621130623.04946ca8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 21 Jun 2004 13:14:38 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org A few more reasons to use an extended operation here: MessageId handling - if we assume messages from multiple clients are multiplex over one session to the chained server, use of a control would require messageId munging. Special bind behavior - a chained bind shouldn't change the LDAP association of the chaining session. If a chaining control were used, that control would have to alter bind semantics. Operation-level signatures - use of a chaining extended operation could be compatible operation-level signature extensions (e.g., RFC 2649), whereas use of a chaining control would likely not be compatible (or would likely require special handling to be compatible). Kurt At 10:51 AM 6/21/2004, Jim Sermersheim wrote: >All, > >I'm attaching a not-ready-for-prime-time I-D which describes an LDAP >chained operation. Following X.518, I described it as an operation >(well, an extended operation) which contains the original message and >some chaining arguments. Some of my peers here have repeatedly argued >that there is no reason to define it as an extended operation, and that >a control makes more sense. > >What do others think? I can go either way. > >If it's a control, I'd want to reconsider the targetObject and >entryOnly fields. If the control holds these, and is sent as >non-critical, and the receiving server doesn't support the control, the >outcome will be erroneous. > >As an extended operation, we have two sets of resultCode, matchedDN, >errorMessage, and referral. This can be resolved by chosing yet another >solution: Create a whole new operation (don't use an extended >operation). The new operation would not include the elements of >LDAPResult (well, the resultCode might be nice, but referral and >matchedDN is confusing). > >I'll publish once I get some feedback on this, and fix up some >editorial issues. > >Jim > >Content-Type: text/plain; name="draft-sermersheim-ldap-chained-op-00.txt" >Content-Disposition: attachment; > filename="draft-sermersheim-ldap-chained-op-00.txt" >X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA11981 > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 21 18:59:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12476 for ; Mon, 21 Jun 2004 18:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXeo-0001dG-DC; Mon, 21 Jun 2004 18:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXSO-000673-QA for ldapext@megatron.ietf.org; Mon, 21 Jun 2004 18:40:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10973 for ; Mon, 21 Jun 2004 18:40:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcXSN-0006iU-Bb for ldapext@ietf.org; Mon, 21 Jun 2004 18:40:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcXRR-0006Ql-00 for ldapext@ietf.org; Mon, 21 Jun 2004 18:39:05 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcXQW-0005tW-00 for ldapext@ietf.org; Mon, 21 Jun 2004 18:38:08 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 21 Jun 2004 16:41:06 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 21 Jun 2004 16:37:13 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >>> "Kurt D. Zeilenga" 6/21/04 2:14:38 PM >>> >A few more reasons to use an extended operation here: > >MessageId handling - if we assume messages from multiple > clients are multiplex over one session to the chained > server, use of a control would require messageId munging. I purposely defined the 'wrapped' thing to be specific operations and controls (not LDAPMessage) so that we wouldn't have two different messageIDs. I can change it back, but I note for the scenario above would require the sending DSA to also provide the incomming user's identity using something like the proxy AuthN control, or by adding another 'originator' field to the chained request. >Special bind behavior - a chained bind shouldn't change > the LDAP association of the chaining session. If > a chaining control were used, that control would have > to alter bind semantics. Yes, a further example of the first reason. >Operation-level signatures - use of a chaining > extended operation could be compatible operation-level > signature extensions (e.g., RFC 2649), whereas use of a > chaining control would likely not be compatible (or > would likely require special handling to be compatible). Yes. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 21 19:05:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13022 for ; Mon, 21 Jun 2004 19:05:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXfP-0001ws-Kz; Mon, 21 Jun 2004 18:53:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXVQ-0006te-Ma for ldapext@megatron.ietf.org; Mon, 21 Jun 2004 18:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11246 for ; Mon, 21 Jun 2004 18:43:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcXVP-0007g5-95 for ldapext@ietf.org; Mon, 21 Jun 2004 18:43:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcXUZ-0007MN-00 for ldapext@ietf.org; Mon, 21 Jun 2004 18:42:20 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcXTa-0006kq-00 for ldapext@ietf.org; Mon, 21 Jun 2004 18:41:18 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 21 Jun 2004 16:44:22 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 21 Jun 2004 16:40:08 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit For #1, I saw having two referrals as being confusing. When would the chained operation's referral field ever be populated? It seems that the embedded operation's referral would always be used. For #2, the I-D does this, but not in the way you are thinking. Jim >>> "Kurt D. Zeilenga" 6/21/04 2:00:19 PM >>> I believe it best to design the chaining operation as an extended operation which "wraps" the chained operation (as well as provides additional "chaining" information), for three reasons: 1) separates chaining v. chained result information (e.g., resultCode, referrals, etc.), 2) separates chaining v. chained extension information (e.g., controls), 3) may facilitate mapping to X.518 operations At 10:51 AM 6/21/2004, Jim Sermersheim wrote: >All, > >I'm attaching a not-ready-for-prime-time I-D which describes an LDAP >chained operation. Following X.518, I described it as an operation >(well, an extended operation) which contains the original message and >some chaining arguments. Some of my peers here have repeatedly argued >that there is no reason to define it as an extended operation, and that >a control makes more sense. > >What do others think? I can go either way. > >If it's a control, I'd want to reconsider the targetObject and >entryOnly fields. If the control holds these, and is sent as >non-critical, and the receiving server doesn't support the control, the >outcome will be erroneous. > >As an extended operation, we have two sets of resultCode, matchedDN, >errorMessage, and referral. This can be resolved by chosing yet another >solution: Create a whole new operation (don't use an extended >operation). The new operation would not include the elements of >LDAPResult (well, the resultCode might be nice, but referral and >matchedDN is confusing). > >I'll publish once I get some feedback on this, and fix up some >editorial issues. > >Jim > >Content-Type: text/plain; name="draft-sermersheim-ldap-chained-op-00.txt" >Content-Disposition: attachment; > filename="draft-sermersheim-ldap-chained-op-00.txt" >X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA11981 > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 21 19:30:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15748 for ; Mon, 21 Jun 2004 19:30:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcY71-0000Tv-7p; Mon, 21 Jun 2004 19:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcY0C-0006w4-3l for ldapext@megatron.ietf.org; Mon, 21 Jun 2004 19:15:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14139 for ; Mon, 21 Jun 2004 19:14:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcY0A-0001qz-JY for ldapext@ietf.org; Mon, 21 Jun 2004 19:14:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcXzC-0001Z9-00 for ldapext@ietf.org; Mon, 21 Jun 2004 19:13:58 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BcXyC-00011n-00 for ldapext@ietf.org; Mon, 21 Jun 2004 19:12:57 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5LNCpMC083024; Mon, 21 Jun 2004 23:12:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040621154840.02c97a48@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 21 Jun 2004 16:13:00 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 03:37 PM 6/21/2004, Jim Sermersheim wrote: >>>> "Kurt D. Zeilenga" 6/21/04 2:14:38 PM >>> >>A few more reasons to use an extended operation here: >> >>MessageId handling - if we assume messages from multiple >> clients are multiplex over one session to the chained >> server, use of a control would require messageId munging. > >I purposely defined the 'wrapped' thing to be specific operations and >controls (not LDAPMessage) so that we wouldn't have two different >messageIDs. I can change it back, Please do. IIRC, message signatures encompass the whole LDAPMessage (less the signature control). >but I note for the scenario above >would require the sending DSA to also provide the incomming user's >identity using something like the proxy AuthN control, >or by adding another 'originator' field to the chained request. "Another" or "an"? That is, do we need more than one 'originator' field? BTW, I'd like to add support for chaining SASL bind exchanges. This will require some fields beyond those offered by the X.518 ChainingArguments/ChainingResults structures. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 21 19:46:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16612 for ; Mon, 21 Jun 2004 19:46:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcYI5-000350-35; Mon, 21 Jun 2004 19:33:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcYBG-0001Q0-RL for ldapext@megatron.ietf.org; Mon, 21 Jun 2004 19:26:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15332 for ; Mon, 21 Jun 2004 19:26:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcYBF-0005bh-Cf for ldapext@ietf.org; Mon, 21 Jun 2004 19:26:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcYA3-0005Cf-00 for ldapext@ietf.org; Mon, 21 Jun 2004 19:25:12 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BcY8L-0004UX-00 for ldapext@ietf.org; Mon, 21 Jun 2004 19:23:25 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5LNNPMC083064; Mon, 21 Jun 2004 23:23:25 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040621161743.048d72a0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 21 Jun 2004 16:23:34 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 03:40 PM 6/21/2004, Jim Sermersheim wrote: >For #1, I saw having two referrals as being confusing. When would the >chained operation's referral field ever be populated? It seems that the >embedded operation's referral would always be used. When the chained server wishes to refer the chaining server to another server to progress the chained operation (instead of wishing to refer the originator to another server). >For #2, the I-D does this, but not in the way you are thinking. > >Jim > >>>> "Kurt D. Zeilenga" 6/21/04 2:00:19 PM >>> >I believe it best to design the chaining operation as an extended >operation which "wraps" the chained operation (as well as provides >additional "chaining" information), for three reasons: > 1) separates chaining v. chained result information (e.g., >resultCode, > referrals, etc.), > 2) separates chaining v. chained extension information (e.g., >controls), > 3) may facilitate mapping to X.518 operations > >At 10:51 AM 6/21/2004, Jim Sermersheim wrote: >>All, >> >>I'm attaching a not-ready-for-prime-time I-D which describes an LDAP >>chained operation. Following X.518, I described it as an operation >>(well, an extended operation) which contains the original message and >>some chaining arguments. Some of my peers here have repeatedly argued >>that there is no reason to define it as an extended operation, and >that >>a control makes more sense. >> >>What do others think? I can go either way. >> >>If it's a control, I'd want to reconsider the targetObject and >>entryOnly fields. If the control holds these, and is sent as >>non-critical, and the receiving server doesn't support the control, >the >>outcome will be erroneous. >> >>As an extended operation, we have two sets of resultCode, matchedDN, >>errorMessage, and referral. This can be resolved by chosing yet >another >>solution: Create a whole new operation (don't use an extended >>operation). The new operation would not include the elements of >>LDAPResult (well, the resultCode might be nice, but referral and >>matchedDN is confusing). >> >>I'll publish once I get some feedback on this, and fix up some >>editorial issues. >> >>Jim >> >>Content-Type: text/plain; >name="draft-sermersheim-ldap-chained-op-00.txt" >>Content-Disposition: attachment; >> filename="draft-sermersheim-ldap-chained-op-00.txt" >>X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id >NAA11981 >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 21 21:36:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23720 for ; Mon, 21 Jun 2004 21:36:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bca9s-00005w-Fh; Mon, 21 Jun 2004 21:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcZio-0004Ox-4A for ldapext@megatron.ietf.org; Mon, 21 Jun 2004 21:05:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22664 for ; Mon, 21 Jun 2004 21:05:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcZil-0005zC-51 for ldapext@ietf.org; Mon, 21 Jun 2004 21:05:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcZTB-0003Im-00 for ldapext@ietf.org; Mon, 21 Jun 2004 20:49:02 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BcZGU-0001RI-00 for ldapext@ietf.org; Mon, 21 Jun 2004 20:35:54 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Tue, 22 Jun 2004 10:33:38 +1000 Received: (qmail 26612 invoked from network); 22 Jun 2004 00:35:15 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 22 Jun 2004 00:35:15 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5M0ZEF21173; Tue, 22 Jun 2004 10:35:14 +1000 Message-ID: <40D77EC1.3070201@adacel.com> Date: Tue, 22 Jun 2004 10:35:13 +1000 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, It is my opinion that you need to define your procedures for distributed operations and define your chaining argument and chaining result based on those procedures. If you choose to assume that the procedures for distributed operations are those defined in X.518, then you will need to include fields in the chaining arguments and results that are required by those procedures. In particular, the operation progress information is critical to the name resolution procedures defined in X.518 and I do not see how you can use these procedures without this field in the chaining arguments and in the trace information (and in referrals). Where information critical to X.518 procedures for distributed operations is not supported, new procedures need to be defined to accomodate chaining of LDAP operations. - Mark. Jim Sermersheim wrote: > All, > > I'm attaching a not-ready-for-prime-time I-D which describes an LDAP > chained operation. Following X.518, I described it as an operation > (well, an extended operation) which contains the original message and > some chaining arguments. Some of my peers here have repeatedly argued > that there is no reason to define it as an extended operation, and that > a control makes more sense. > > What do others think? I can go either way. > > If it's a control, I'd want to reconsider the targetObject and > entryOnly fields. If the control holds these, and is sent as > non-critical, and the receiving server doesn't support the control, the > outcome will be erroneous. > > As an extended operation, we have two sets of resultCode, matchedDN, > errorMessage, and referral. This can be resolved by chosing yet another > solution: Create a whole new operation (don't use an extended > operation). The new operation would not include the elements of > LDAPResult (well, the resultCode might be nice, but referral and > matchedDN is confusing). > > I'll publish once I get some feedback on this, and fix up some > editorial issues. > > Jim > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jun 21 22:36:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26576 for ; Mon, 21 Jun 2004 22:36:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcb79-0002h8-0M; Mon, 21 Jun 2004 22:34:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcaue-0000gc-3n for ldapext@megatron.ietf.org; Mon, 21 Jun 2004 22:21:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25866 for ; Mon, 21 Jun 2004 22:21:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcauc-00073p-A0 for ldapext@ietf.org; Mon, 21 Jun 2004 22:21:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcZss-00075C-00 for ldapext@ietf.org; Mon, 21 Jun 2004 21:15:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BcZTs-00039z-00 for ldapext@ietf.org; Mon, 21 Jun 2004 20:49:44 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BcZTs-0007Df-LF for ldapext@ietf.org; Mon, 21 Jun 2004 20:49:44 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 21 Jun 2004 18:52:36 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 21 Jun 2004 18:48:37 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >>> "Kurt D. Zeilenga" 6/21/04 5:13:00 PM >>> >At 03:37 PM 6/21/2004, Jim Sermersheim wrote: >>>>> "Kurt D. Zeilenga" 6/21/04 2:14:38 PM >>> >>>A few more reasons to use an extended operation here: >>> >>>MessageId handling - if we assume messages from multiple >>> clients are multiplex over one session to the chained >>> server, use of a control would require messageId munging. >> >>I purposely defined the 'wrapped' thing to be specific operations and >>controls (not LDAPMessage) so that we wouldn't have two different >>messageIDs. I can change it back, > >Please do. IIRC, message signatures encompass the whole >LDAPMessage (less the signature control). > >>but I note for the scenario above >>would require the sending DSA to also provide the incomming user's >>identity using something like the proxy AuthN control, >>or by adding another 'originator' field to the chained request. > >"Another" or "an"? That is, do we need more than one >'originator' field? An. Currently there is no originator field in my proposal. Jim BTW, I'd like to add support for chaining SASL bind exchanges. This will require some fields beyond those offered by the X.518 ChainingArguments/ChainingResults structures. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jun 22 01:56:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22262 for ; Tue, 22 Jun 2004 01:56:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BceBD-0000Ct-2T; Tue, 22 Jun 2004 01:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bccyl-0006HF-Bi for ldapext@megatron.ietf.org; Tue, 22 Jun 2004 00:33:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03739 for ; Tue, 22 Jun 2004 00:33:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bccyj-0004n2-Av for ldapext@ietf.org; Tue, 22 Jun 2004 00:33:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcb08-0007bE-00 for ldapext@ietf.org; Mon, 21 Jun 2004 22:27:09 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcZvt-0007LO-00 for ldapext@ietf.org; Mon, 21 Jun 2004 21:18:42 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Mon, 21 Jun 2004 19:21:51 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 21 Jun 2004 19:17:52 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Thanks Mark, Yes, I do need to add better semantics and some implementation details. If people agree that this operation should be sent as an extended request, I'll do that and submit. I couldn't find a reason why operationProgress was needed. For example, today's LDAP servers return referrals and search result references which LDAP clients can follow. Nothing is conveyed regarding the operation progress when those clients follow these referrals and search referral references. Furthermore, I don't understand what a receiving DSA does with this information. A receiving DSA will not get a nameResolutionPhase of completed, thus it's either notStarted or proceeding. Regardless of whether it's notStarted or proceeding, the targetObject contains the DN to be resolved (unless the value is the same as the base DN of the embedded operation). Will you let me know what I'm missing here? Some of the other fields are left for future controls that I haven't had time to write up (specifically referenceType, timeLimit, excludeShadows, and nameResolveOnMaster). Each of these have utility outside of the chained operation, so I think defining them as controls in their own documents would be better. Jim >>> Mark Ennis 6/21/04 6:35:13 PM >>> Jim, It is my opinion that you need to define your procedures for distributed operations and define your chaining argument and chaining result based on those procedures. If you choose to assume that the procedures for distributed operations are those defined in X.518, then you will need to include fields in the chaining arguments and results that are required by those procedures. In particular, the operation progress information is critical to the name resolution procedures defined in X.518 and I do not see how you can use these procedures without this field in the chaining arguments and in the trace information (and in referrals). Where information critical to X.518 procedures for distributed operations is not supported, new procedures need to be defined to accomodate chaining of LDAP operations. - Mark. Jim Sermersheim wrote: > All, > > I'm attaching a not-ready-for-prime-time I-D which describes an LDAP > chained operation. Following X.518, I described it as an operation > (well, an extended operation) which contains the original message and > some chaining arguments. Some of my peers here have repeatedly argued > that there is no reason to define it as an extended operation, and that > a control makes more sense. > > What do others think? I can go either way. > > If it's a control, I'd want to reconsider the targetObject and > entryOnly fields. If the control holds these, and is sent as > non-critical, and the receiving server doesn't support the control, the > outcome will be erroneous. > > As an extended operation, we have two sets of resultCode, matchedDN, > errorMessage, and referral. This can be resolved by chosing yet another > solution: Create a whole new operation (don't use an extended > operation). The new operation would not include the elements of > LDAPResult (well, the resultCode might be nice, but referral and > matchedDN is confusing). > > I'll publish once I get some feedback on this, and fix up some > editorial issues. > > Jim > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jun 22 09:13:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07410 for ; Tue, 22 Jun 2004 09:13:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BckmU-0001oI-Oc; Tue, 22 Jun 2004 08:53:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bce7V-0007p7-5R for ldapext@megatron.ietf.org; Tue, 22 Jun 2004 01:46:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20644 for ; Tue, 22 Jun 2004 01:46:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bce7S-0002Eb-Cm for ldapext@ietf.org; Tue, 22 Jun 2004 01:46:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcdrU-0007An-00 for ldapext@ietf.org; Tue, 22 Jun 2004 01:30:25 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BcdDO-0007Wz-00 for ldapext@ietf.org; Tue, 22 Jun 2004 00:48:59 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Tue, 22 Jun 2004 14:46:44 +1000 Received: (qmail 20728 invoked from network); 22 Jun 2004 04:48:22 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 22 Jun 2004 04:48:22 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5M4mMF25249; Tue, 22 Jun 2004 14:48:22 +1000 Message-ID: <40D7BA14.9000501@adacel.com> Date: Tue, 22 Jun 2004 14:48:20 +1000 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, The operationProgress becomes important in name resolution when DSAs have subordinate/superior relationships. Traditionally LDAP servers are defined as "First-level DSAs" which means that the operationProgress information is of little value in processing of referrals. It is not true that a receiving DSA will not get a nameResolutionPhase of "completed". This can occur when processing a search operation, where name resolution has completed, but the scope of the search includes a reference to a subordinate DSA. The search will be chained with the targetObject of the chainingArguments set to the name of the superior of the DSE containing the subordinate reference and the operationProgress.nameResolutionPhase set to completed (cf. X.518 19.3.2.2.1 7a). This allows the subordinate DSA to confirm the targetObject is an immSupr DSE and proceed with the search from this point. If the subordinate DSA cannot resolve the targetObject as an immSupr DSE then it should generate ServiceError.unableToProceed to indicate an inconsistency in the hierarchical operational binding (i.e. the knowledge) between these DSAs. X.518 assume that the first step for the processing of any operation is name resolution. The operationProgress is used to determine if the hierarchical operation binding (represented by the knowledge such as subordinate and superior references) is consistent. In the absence of the operationProgress, a subordinate DSA, on receiving a request for a naming context it does not recognise, will chain the request to a superior DSA. Where the hierarchical operational binding has become inconsistent between the superior and subordinate DSA, this could lead to a loop condition or an incorrect NameError.noSuchObject. The operatonProgress in the traceInformation of the chaining arguments is used to support a situation where one DSA contains both superior and subordinate parts of the DIT to a second DSA. Because of aliases, the first DSA could have the same request chained to it at different points in the name resolution and needs to be able to distinguish between the incidents in order to allow the name resolution to complete. N.B. I have used the ITU-T Rec. X.518 (1993 E) as my reference for the X.500 procedures for distributed operations. As far as I am aware there are no significant differences in more recent editions of this recommendation. - Mark. Jim Sermersheim wrote: > Thanks Mark, > > Yes, I do need to add better semantics and some implementation details. > If people agree that this operation should be sent as an extended > request, I'll do that and submit. > > I couldn't find a reason why operationProgress was needed. For example, > today's LDAP servers return referrals and search result references which > LDAP clients can follow. Nothing is conveyed regarding the operation > progress when those clients follow these referrals and search referral > references. > > Furthermore, I don't understand what a receiving DSA does with this > information. A receiving DSA will not get a nameResolutionPhase of > completed, thus it's either notStarted or proceeding. Regardless of > whether it's notStarted or proceeding, the targetObject contains the DN > to be resolved (unless the value is the same as the base DN of the > embedded operation). Will you let me know what I'm missing here? > > Some of the other fields are left for future controls that I haven't > had time to write up (specifically referenceType, timeLimit, > excludeShadows, and nameResolveOnMaster). Each of these have utility > outside of the chained operation, so I think defining them as controls > in their own documents would be better. > > Jim > > >>>>Mark Ennis 6/21/04 6:35:13 PM >>> > > Jim, > > It is my opinion that you need to define your procedures for > distributed > operations and define your chaining argument and chaining result based > > on those procedures. If you choose to assume that the procedures for > distributed operations are those defined in X.518, then you will need > to > include fields in the chaining arguments and results that are required > > by those procedures. In particular, the operation progress information > > is critical to the name resolution procedures defined in X.518 and I do > > not see how you can use these procedures without this field in the > chaining arguments and in the trace information (and in referrals). > > Where information critical to X.518 procedures for distributed > operations is not supported, new procedures need to be defined to > accomodate chaining of LDAP operations. > > - Mark. > > Jim Sermersheim wrote: > > >>All, >> >>I'm attaching a not-ready-for-prime-time I-D which describes an LDAP >>chained operation. Following X.518, I described it as an operation >>(well, an extended operation) which contains the original message > > and > >>some chaining arguments. Some of my peers here have repeatedly > > argued > >>that there is no reason to define it as an extended operation, and > > that > >>a control makes more sense. >> >>What do others think? I can go either way. >> >>If it's a control, I'd want to reconsider the targetObject and >>entryOnly fields. If the control holds these, and is sent as >>non-critical, and the receiving server doesn't support the control, > > the > >>outcome will be erroneous. >> >>As an extended operation, we have two sets of resultCode, matchedDN, >>errorMessage, and referral. This can be resolved by chosing yet > > another > >>solution: Create a whole new operation (don't use an extended >>operation). The new operation would not include the elements of >>LDAPResult (well, the resultCode might be nice, but referral and >>matchedDN is confusing). >> >>I'll publish once I get some feedback on this, and fix up some >>editorial issues. >> >>Jim >> >> >> > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jun 22 09:17:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07471 for ; Tue, 22 Jun 2004 09:17:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcknD-0001z0-CC; Tue, 22 Jun 2004 08:54:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BceRf-0005ZB-Bj for ldapext@megatron.ietf.org; Tue, 22 Jun 2004 02:07:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00644 for ; Tue, 22 Jun 2004 02:07:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BceRd-0006rA-6n for ldapext@ietf.org; Tue, 22 Jun 2004 02:07:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BceQO-0006R2-00 for ldapext@ietf.org; Tue, 22 Jun 2004 02:06:29 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BceOH-0005Y2-00 for ldapext@ietf.org; Tue, 22 Jun 2004 02:04:18 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Tue, 22 Jun 2004 16:02:05 +1000 Received: (qmail 5274 invoked from network); 22 Jun 2004 06:03:44 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 22 Jun 2004 06:03:44 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5M63iF30031; Tue, 22 Jun 2004 16:03:44 +1000 Message-ID: <40D7CBBE.1050307@adacel.com> Date: Tue, 22 Jun 2004 16:03:42 +1000 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, I keep forgetting to mention I think the extended operation is the right approach too. - Mark. Jim Sermersheim wrote: > Thanks Mark, > > Yes, I do need to add better semantics and some implementation details. > If people agree that this operation should be sent as an extended > request, I'll do that and submit. > > I couldn't find a reason why operationProgress was needed. For example, > today's LDAP servers return referrals and search result references which > LDAP clients can follow. Nothing is conveyed regarding the operation > progress when those clients follow these referrals and search referral > references. > > Furthermore, I don't understand what a receiving DSA does with this > information. A receiving DSA will not get a nameResolutionPhase of > completed, thus it's either notStarted or proceeding. Regardless of > whether it's notStarted or proceeding, the targetObject contains the DN > to be resolved (unless the value is the same as the base DN of the > embedded operation). Will you let me know what I'm missing here? > > Some of the other fields are left for future controls that I haven't > had time to write up (specifically referenceType, timeLimit, > excludeShadows, and nameResolveOnMaster). Each of these have utility > outside of the chained operation, so I think defining them as controls > in their own documents would be better. > > Jim > > >>>>Mark Ennis 6/21/04 6:35:13 PM >>> > > Jim, > > It is my opinion that you need to define your procedures for > distributed > operations and define your chaining argument and chaining result based > > on those procedures. If you choose to assume that the procedures for > distributed operations are those defined in X.518, then you will need > to > include fields in the chaining arguments and results that are required > > by those procedures. In particular, the operation progress information > > is critical to the name resolution procedures defined in X.518 and I do > > not see how you can use these procedures without this field in the > chaining arguments and in the trace information (and in referrals). > > Where information critical to X.518 procedures for distributed > operations is not supported, new procedures need to be defined to > accomodate chaining of LDAP operations. > > - Mark. > > Jim Sermersheim wrote: > > >>All, >> >>I'm attaching a not-ready-for-prime-time I-D which describes an LDAP >>chained operation. Following X.518, I described it as an operation >>(well, an extended operation) which contains the original message > > and > >>some chaining arguments. Some of my peers here have repeatedly > > argued > >>that there is no reason to define it as an extended operation, and > > that > >>a control makes more sense. >> >>What do others think? I can go either way. >> >>If it's a control, I'd want to reconsider the targetObject and >>entryOnly fields. If the control holds these, and is sent as >>non-critical, and the receiving server doesn't support the control, > > the > >>outcome will be erroneous. >> >>As an extended operation, we have two sets of resultCode, matchedDN, >>errorMessage, and referral. This can be resolved by chosing yet > > another > >>solution: Create a whole new operation (don't use an extended >>operation). The new operation would not include the elements of >>LDAPResult (well, the resultCode might be nice, but referral and >>matchedDN is confusing). >> >>I'll publish once I get some feedback on this, and fix up some >>editorial issues. >> >>Jim >> >> >> > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jun 22 09:24:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07686 for ; Tue, 22 Jun 2004 09:24:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcko9-0002Jj-QN; Tue, 22 Jun 2004 08:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcfQ1-0004XP-Vs for ldapext@megatron.ietf.org; Tue, 22 Jun 2004 03:10:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12631 for ; Tue, 22 Jun 2004 03:10:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcfPz-00034s-Tc for ldapext@ietf.org; Tue, 22 Jun 2004 03:10:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcfP2-0002lN-00 for ldapext@ietf.org; Tue, 22 Jun 2004 03:09:09 -0400 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1BcfO4-0002BS-00 for ldapext@ietf.org; Tue, 22 Jun 2004 03:08:08 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Jun 2004 17:07:37 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) Date: Tue, 22 Jun 2004 17:07:36 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B6381017EB6B7@ausyms21.ca.com> Thread-Topic: [ldapext] Chained Operation (control, extended op, or op?) Thread-Index: AcRYHZYmtu38gjPOTsqjWIMPU+tUyQACUFOA From: "Ramsay, Ron" To: "Jim Sermersheim" X-OriginalArrivalTime: 22 Jun 2004 07:07:37.0326 (UTC) FILETIME=[995E00E0:01C45827] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: mark.ennis@adacel.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Jim, Operation progress is the only way of differentiating chaining from = multichaining. For example, a request is sent to Server A, which *chains* it to Server = B. Name resolution is not complete. Server B performs it and, if it is a = search request, *multichains* is to subordinates A and C. Name = resolution is completed. Note that, with the name-resolution indicator, = Server A would normally return "loop detected" instead of performing the = request. Also note that, without the name-resolution indication, Server = A would want to chain the multichained request to Server B, again! Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Tuesday, 22 June 2004 11:18 To: mark.ennis@adacel.com Cc: ldapext@ietf.org Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Thanks Mark, Yes, I do need to add better semantics and some implementation details. If people agree that this operation should be sent as an extended request, I'll do that and submit. I couldn't find a reason why operationProgress was needed. For example, today's LDAP servers return referrals and search result references which LDAP clients can follow. Nothing is conveyed regarding the operation progress when those clients follow these referrals and search referral references.=20 Furthermore, I don't understand what a receiving DSA does with this information. A receiving DSA will not get a nameResolutionPhase of completed, thus it's either notStarted or proceeding. Regardless of whether it's notStarted or proceeding, the targetObject contains the DN to be resolved (unless the value is the same as the base DN of the embedded operation). Will you let me know what I'm missing here? Some of the other fields are left for future controls that I haven't had time to write up (specifically referenceType, timeLimit, excludeShadows, and nameResolveOnMaster). Each of these have utility outside of the chained operation, so I think defining them as controls in their own documents would be better. Jim >>> Mark Ennis 6/21/04 6:35:13 PM >>> Jim, It is my opinion that you need to define your procedures for distributed=20 operations and define your chaining argument and chaining result based on those procedures. If you choose to assume that the procedures for=20 distributed operations are those defined in X.518, then you will need to=20 include fields in the chaining arguments and results that are required by those procedures. In particular, the operation progress information is critical to the name resolution procedures defined in X.518 and I do not see how you can use these procedures without this field in the=20 chaining arguments and in the trace information (and in referrals). Where information critical to X.518 procedures for distributed=20 operations is not supported, new procedures need to be defined to=20 accomodate chaining of LDAP operations. - Mark. Jim Sermersheim wrote: > All, >=20 > I'm attaching a not-ready-for-prime-time I-D which describes an LDAP > chained operation. Following X.518, I described it as an operation > (well, an extended operation) which contains the original message and > some chaining arguments. Some of my peers here have repeatedly argued > that there is no reason to define it as an extended operation, and that > a control makes more sense. >=20 > What do others think? I can go either way. >=20 > If it's a control, I'd want to reconsider the targetObject and > entryOnly fields. If the control holds these, and is sent as > non-critical, and the receiving server doesn't support the control, the > outcome will be erroneous.=20 >=20 > As an extended operation, we have two sets of resultCode, matchedDN, > errorMessage, and referral. This can be resolved by chosing yet another > solution: Create a whole new operation (don't use an extended > operation). The new operation would not include the elements of > LDAPResult (well, the resultCode might be nice, but referral and > matchedDN is confusing). >=20 > I'll publish once I get some feedback on this, and fix up some > editorial issues. >=20 > Jim >=20 >=20 >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jun 22 19:13:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08496 for ; Tue, 22 Jun 2004 19:13:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctnQ-00083b-OZ; Tue, 22 Jun 2004 18:31:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcqJZ-0002xE-Pk for ldapext@megatron.ietf.org; Tue, 22 Jun 2004 14:48:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16988 for ; Tue, 22 Jun 2004 14:48:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcqJY-0005PK-Ky for ldapext@ietf.org; Tue, 22 Jun 2004 14:48:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcq4X-0002J5-00 for ldapext@ietf.org; Tue, 22 Jun 2004 14:32:43 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcpdP-0005Ej-00 for ldapext@ietf.org; Tue, 22 Jun 2004 14:04:39 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 22 Jun 2004 12:08:20 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 22 Jun 2004 12:03:48 -0600 From: "Jim Sermersheim" To: Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, mark.ennis@adacel.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I assumed that the host *and* target object were considered when performing loop detection. I haven't put this much detail in the draft yet, but I assumed I had it covered. Here's what I should have said about ChainedRequestValue.chainingArguments.traceInformation: << This contains a set of URIs. Each value represents the address of a DSA and DN that has already been contacted while trying to service the operation. The receiving DSA adds to this list, a URI (or URIs if it may be contacted using multiple addresses or ports) value containing its address and the target object of the operation. The target object is constructed using the value of ChainedRequestValue.chainingArguments.targetObject. If that value not present, then the value of the base object in the ChainedRequestValue.operationRequest is used. If, after adding its own URI(s) to this list, there are any two URIs that match a loopDetect (54) error is returned. Otherwise, the modified list is used if the operation is to be chained to a further DSA >> Thus, in your example, the new target object is different from the original target object when the operation is chained back to Server A, thus no loop. Similarly, since the target object points to a local naming context when the operation is chained back to Server A, it would not want to chain to Server B. There must be some scenario that I haven't thought about where the targetObject and dsa are not enough to detect a loop (or that they would cause a loop to be erroneously detected). Jim >>> "Ramsay, Ron" 6/22/04 1:07:36 AM >>> Jim, Operation progress is the only way of differentiating chaining from multichaining. For example, a request is sent to Server A, which *chains* it to Server B. Name resolution is not complete. Server B performs it and, if it is a search request, *multichains* is to subordinates A and C. Name resolution is completed. Note that, with the name-resolution indicator, Server A would normally return "loop detected" instead of performing the request. Also note that, without the name-resolution indication, Server A would want to chain the multichained request to Server B, again! Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Tuesday, 22 June 2004 11:18 To: mark.ennis@adacel.com Cc: ldapext@ietf.org Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Thanks Mark, Yes, I do need to add better semantics and some implementation details. If people agree that this operation should be sent as an extended request, I'll do that and submit. I couldn't find a reason why operationProgress was needed. For example, today's LDAP servers return referrals and search result references which LDAP clients can follow. Nothing is conveyed regarding the operation progress when those clients follow these referrals and search referral references. Furthermore, I don't understand what a receiving DSA does with this information. A receiving DSA will not get a nameResolutionPhase of completed, thus it's either notStarted or proceeding. Regardless of whether it's notStarted or proceeding, the targetObject contains the DN to be resolved (unless the value is the same as the base DN of the embedded operation). Will you let me know what I'm missing here? Some of the other fields are left for future controls that I haven't had time to write up (specifically referenceType, timeLimit, excludeShadows, and nameResolveOnMaster). Each of these have utility outside of the chained operation, so I think defining them as controls in their own documents would be better. Jim >>> Mark Ennis 6/21/04 6:35:13 PM >>> Jim, It is my opinion that you need to define your procedures for distributed operations and define your chaining argument and chaining result based on those procedures. If you choose to assume that the procedures for distributed operations are those defined in X.518, then you will need to include fields in the chaining arguments and results that are required by those procedures. In particular, the operation progress information is critical to the name resolution procedures defined in X.518 and I do not see how you can use these procedures without this field in the chaining arguments and in the trace information (and in referrals). Where information critical to X.518 procedures for distributed operations is not supported, new procedures need to be defined to accomodate chaining of LDAP operations. - Mark. Jim Sermersheim wrote: > All, > > I'm attaching a not-ready-for-prime-time I-D which describes an LDAP > chained operation. Following X.518, I described it as an operation > (well, an extended operation) which contains the original message and > some chaining arguments. Some of my peers here have repeatedly argued > that there is no reason to define it as an extended operation, and that > a control makes more sense. > > What do others think? I can go either way. > > If it's a control, I'd want to reconsider the targetObject and > entryOnly fields. If the control holds these, and is sent as > non-critical, and the receiving server doesn't support the control, the > outcome will be erroneous. > > As an extended operation, we have two sets of resultCode, matchedDN, > errorMessage, and referral. This can be resolved by chosing yet another > solution: Create a whole new operation (don't use an extended > operation). The new operation would not include the elements of > LDAPResult (well, the resultCode might be nice, but referral and > matchedDN is confusing). > > I'll publish once I get some feedback on this, and fix up some > editorial issues. > > Jim > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jun 22 19:59:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14098 for ; Tue, 22 Jun 2004 19:59:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctoW-0008Hq-TK; Tue, 22 Jun 2004 18:32:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcrPi-0006jx-FL for ldapext@megatron.ietf.org; Tue, 22 Jun 2004 15:58:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24552 for ; Tue, 22 Jun 2004 15:58:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcrPg-00073X-M0 for ldapext@ietf.org; Tue, 22 Jun 2004 15:58:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcrOs-0006g3-00 for ldapext@ietf.org; Tue, 22 Jun 2004 15:57:47 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcrO7-0006FZ-00 for ldapext@ietf.org; Tue, 22 Jun 2004 15:56:59 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 22 Jun 2004 14:00:44 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 22 Jun 2004 13:56:05 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >>> Mark Ennis 6/21/04 10:48:20 PM >>> >Jim, > >The operationProgress becomes important in name resolution when DSAs=20 >have subordinate/superior relationships. Traditionally LDAP servers = are=20 >defined as "First-level DSAs" which means that the operationProgress=20 >information is of little value in processing of referrals. I'm not sure I agree with this statement. Many LDAP servers are required = to be populated with the context prefixes of the naming contexts they = hold. Some allow a superior referral, but others don't. I think the = distributed data model has never been fully defined for LDAP servers, so = to date, the servers are a mish-mash of different elements of First Level = DSAs and non First Level DSAs.=20 Regardless of that, I am interested in finding out what scenarios require = operationProgress. >It is not true that a receiving DSA will not get a nameResolutionPhase=20 >of "completed". This can occur when processing a search operation, = where=20 >name resolution has completed, but the scope of the search includes a=20 >reference to a subordinate DSA.=20 You're right * I wasn't thinking. >The search will be chained with the=20 >targetObject of the chainingArguments set to the name of the superior = of=20 >the DSE containing the subordinate reference=20 This is not what LDAP returns as the DN part of a referral URI. So if we = did it this way, the target object in a chained operation would be = different from the 'target object' of a referral. If there's a way to keep = the 'target object' consistent between these, I'd prefer it. >and the=20 >operationProgress.nameResolutionPhase set to completed (cf. X.518=20 >19.3.2.2.1 7a). This allows the subordinate DSA to confirm the=20 >targetObject is an immSupr DSE and proceed with the search from this=20 >point.=20 >If the subordinate DSA cannot resolve the targetObject as an=20 >immSupr DSE then it should generate ServiceError.unableToProceed to=20 >indicate an inconsistency in the hierarchical operational binding = (i.e.=20 >the knowledge) between these DSAs. My draft doesn't consider the need for checking the consistency of the = distributed data model. If that is a requirement, I need to refactor it. I = do have a couple questions relating to this. 1) Why must the immediatly superior name be passed as the targetObject? If = the receiving DSA knows a chained operation is due to a subordinate = reference (yes, that would require more information than the draft = currently has), and the targetObject is set to the name of the DSE which = caused the referral, then the receiving DSA can examine the parent of the = targetObject if it wishes to perform a consistency check. Are there other = reasons that the parent is sent as the targetObject? 2) LDAP Servers often store a DN in the URI which represents knowledge = information (RFC 3296). This DN does not have to name the DSE that holds = the knowledge information. This can be useful (though potentially = dangerous) when mapping a local name to a different remote name (let's = call this "name mapping"). For example, I may have a server that holds a = subr DSE (well, a RFC 3296 referral) named id=3DSharks,id=3DMyStuff where = the ref attribute holds a value ldap://zoology.org/order=3DSelachimorpha,su= blcass=3DElasmobranchii,class=3DChondrichthyes,superclass=3DGnathostomata. = I wouldn't clasify this as a good practice, but one that is allowed and = used. If we pass the local name of a reference's parent as the target = object (where that reference holds mapped names), it will surely cause any = validation check to fail (in fact it will cause the operation to fail = regardless of a validation check). So I guess two questions for the list are: a) Is it required that the chained operation facilitate distributed data = consistency checks? If so, must it be done in the same manner as X.518? b) Is it required that the chained operation allow for a distributed data = model where disparate namespaces can be joined via "name mapping"? >X.518 assume that the first step for the processing of any operation = is=20 >name resolution. The operationProgress is used to determine if the=20 >hierarchical operation binding (represented by the knowledge such as=20 >subordinate and superior references) is consistent. In the absence of=20 >the operationProgress, a subordinate DSA, on receiving a request for a=20 >naming context it does not recognise, will chain the request to a=20 >superior DSA. Where the hierarchical operational binding has become=20 >inconsistent between the superior and subordinate DSA, this could lead=20 >to a loop condition or an incorrect NameError.noSuchObject. Right, for these scenarios I assumed that the return of either of these = errors (loopDetected or noSuchObject) would suffice. >The operatonProgress in the traceInformation of the chaining arguments=20 >is used to support a situation where one DSA contains both superior = and=20 >subordinate parts of the DIT to a second DSA. Because of aliases, the=20 >first DSA could have the same request chained to it at different = points=20 >in the name resolution and needs to be able to distinguish between the=20 >incidents in order to allow the name resolution to complete. If the targetObject sent to the first DSA is different each time the = operation is chained to it, it should not detect a loop, and thus allow = name resolution to progress. >N.B. I have used the ITU-T Rec. X.518 (1993 E) as my reference for the=20 >X.500 procedures for distributed operations. As far as I am aware = there=20 >are no significant differences in more recent editions of this=20 >recommendation. > >- Mark. Thanks for the feedback. As you can tell, I have not implemented this, I = have only used it as a guide in experimentally implementing enough of it = in an LDAP server to come up to speed enough to start the I-D. I very much = appreciate the help. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 23 11:09:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06337 for ; Wed, 23 Jun 2004 11:09:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd9K0-0002H0-Bz; Wed, 23 Jun 2004 11:05:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd1Fe-0002Ol-9C for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 02:28:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04609 for ; Wed, 23 Jun 2004 02:28:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd1FT-0006pK-Oe for ldapext@ietf.org; Wed, 23 Jun 2004 02:28:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcye7-0004Fm-00 for ldapext@ietf.org; Tue, 22 Jun 2004 23:42:01 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BcwVG-0004tR-00 for ldapext@ietf.org; Tue, 22 Jun 2004 21:24:42 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Wed, 23 Jun 2004 11:23:25 +1000 Received: (qmail 17858 invoked from network); 23 Jun 2004 01:24:09 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 23 Jun 2004 01:24:09 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5N1O9F04132; Wed, 23 Jun 2004 11:24:09 +1000 Message-ID: <40D8DBB8.90004@adacel.com> Date: Wed, 23 Jun 2004 11:24:08 +1000 From: "Ennis, Mark" User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, My concern is not that you are not following X.518, but that you appear to be implying the X.518 procedures without providing the information required by those procedures. I think your draft needs to define the procedures for distributed operations for LDAP directories in order to ensure the information provided in the chaining arguments and results are sufficient to the procedures defined. More response in-line below. - Mark. Jim Sermersheim wrote: >>>>Mark Ennis 6/21/04 10:48:20 PM >>> >> >>The search will be chained with the >>targetObject of the chainingArguments set to the name of the superior of >>the DSE containing the subordinate reference > > > This is not what LDAP returns as the DN part of a referral URI. So if we did it this way, the target object in a chained operation would be different from the 'target object' of a referral. If there's a way to keep the 'target object' consistent between these, I'd prefer it. If I remember correctly, the argument for using the name of the superior of the subr DSE is so that multiple sibling subr DSEs, where the subordinate entries are in the same subordinate DSA, will result in a single continuation reference instead of one for each sibling, thereby reducing the number of chained operations required to complete the operation. It also makes the subr and nssr reference types generate equivalent continuation references. This may be another reason for the ChainingResults.alreadySearched field. > > >>and the >>operationProgress.nameResolutionPhase set to completed (cf. X.518 >>19.3.2.2.1 7a). This allows the subordinate DSA to confirm the >>targetObject is an immSupr DSE and proceed with the search from this >>point. >>If the subordinate DSA cannot resolve the targetObject as an >>immSupr DSE then it should generate ServiceError.unableToProceed to >>indicate an inconsistency in the hierarchical operational binding (i.e. >>the knowledge) between these DSAs. > > > My draft doesn't consider the need for checking the consistency of the distributed data model. If that is a requirement, I need to refactor it. I do have a couple questions relating to this. > > 1) Why must the immediatly superior name be passed as the targetObject? If the receiving DSA knows a chained operation is due to a subordinate reference (yes, that would require more information than the draft currently has), and the targetObject is set to the name of the DSE which caused the referral, then the receiving DSA can examine the parent of the targetObject if it wishes to perform a consistency check. Are there other reasons that the parent is sent as the targetObject? The targetObject is not set to the name of the superior of the subr DSE during name resolution. It is set to the target object of the operation, which may change from the originally supplied target object due to the dereferencing of aliases during name resolution. The operationProgress.nextRDNToBeResolved informs the subordinate DSA which RDN in the target object is the name of the context prefix to begin local name resolution on. > > 2) LDAP Servers often store a DN in the URI which represents knowledge information (RFC 3296). This DN does not have to name the DSE that holds the knowledge information. This can be useful (though potentially dangerous) when mapping a local name to a different remote name (let's call this "name mapping"). For example, I may have a server that holds a subr DSE (well, a RFC 3296 referral) named id=Sharks,id=MyStuff where the ref attribute holds a value ldap://zoology.org/order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata. I wouldn't clasify this as a good practice, but one that is allowed and used. If we pass the local name of a reference's parent as the target object (where that reference holds mapped names), it will surely cause any validation check to fail (in fact it will cause the operation to fail regardless of a validation check). The target object of the chainingArgument is not the superior of the subr DSE during name resolution. In the case of a named subordinate reference as defined in RFC 3296, it looks to me like a combination of an alias and a subordinate reference. I would re-write the target object by replacing the resolved portion with the name in the reference and then chain the request to the indicated server, if I was following X.518 procedures for distributed operation. > > So I guess two questions for the list are: > a) Is it required that the chained operation facilitate distributed data consistency checks? If so, must it be done in the same manner as X.518? > b) Is it required that the chained operation allow for a distributed data model where disparate namespaces can be joined via "name mapping"? > > >>X.518 assume that the first step for the processing of any operation is >>name resolution. The operationProgress is used to determine if the >>hierarchical operation binding (represented by the knowledge such as >>subordinate and superior references) is consistent. In the absence of >>the operationProgress, a subordinate DSA, on receiving a request for a >>naming context it does not recognise, will chain the request to a >>superior DSA. Where the hierarchical operational binding has become >>inconsistent between the superior and subordinate DSA, this could lead >>to a loop condition or an incorrect NameError.noSuchObject. > > > Right, for these scenarios I assumed that the return of either of these errors (loopDetected or noSuchObject) would suffice. The main difference is that normally ServiceError.unableToProceed is used by the X.518 procedures to cause another continuation reference to be used if one is available, while the NameError.noSuchObject and ServiceError.loopDetected cause the operation to complete with an error. This is particularly relevant to processing of non-specific subordinate references, where the problem is not due inconsistency in the HOB, but is due to lack of knowledge in the superior about which naming contexts exist in which subordinate DSAs. > > >>The operatonProgress in the traceInformation of the chaining arguments >>is used to support a situation where one DSA contains both superior and >>subordinate parts of the DIT to a second DSA. Because of aliases, the >>first DSA could have the same request chained to it at different points >>in the name resolution and needs to be able to distinguish between the >>incidents in order to allow the name resolution to complete. > > > If the targetObject sent to the first DSA is different each time the operation is chained to it, it should not detect a loop, and thus allow name resolution to progress. I can think of an example where the X.518 procedures would permit the same request to be chained to a DSA more than once, each time with the same target object but a different nextRDNToBeResolved. The example may not be very likely but is potentially possible in a complex topology. Suppose we have the following DSAs: DSA1 has two context prefixes: c=au and ou=development,o=adacel,c=au. DSA2 has one context prefix: o=adacel,c=au. DSA3 has one context prefix: ou=view500,ou=development,o=adacel,c=au. Appropriate hierarchical operational bindings have been established for: DSA1 -> DSA2 -> DSA1 -> DSA3. We are attempting name resolution on ou=testing,ou=view500,ou=development,o=adacel,c=au with from DSA1, but DSA3 in unavailable. DSA1 attempts name resolution and ends up with two candidate references, one to DSA2 and one to DSA3. Attempting to chain to DSA3 gets an unavailable error so the operation is chained to DSA2. DSA2 attempts name resolution and chains the operations back to DSA1. DSA1 now has a second go at the name resolution on the request which fails due to DSA3 being unavailable. The first attempt DSA1 makes to resolve the target object it has an operation progress of { nameResolutionPhase proceeding, nextRDNToBeResolved 1 } and the second time of { nameResolutionPhase proceeding, nextRDNToBeResolved 3 }. In X.518, the target object is the same. Without the operation progress information, the chained request from DSA2 to DSA1 would generate an incorrect loopDetected error. The X.518 procedures allow a implementation the choice on how to proceed based on an attempt to chain receiving a busy, unavailable, unwillingToPerform or invalidReference error. They can try a different candidate continuation reference or return an error. This choice leads to the situation I have described. I think situations with partial replicas could cause similar situations to occur. > > >>N.B. I have used the ITU-T Rec. X.518 (1993 E) as my reference for the >>X.500 procedures for distributed operations. As far as I am aware there >>are no significant differences in more recent editions of this >>recommendation. >> >>- Mark. > > > Thanks for the feedback. As you can tell, I have not implemented this, I have only used it as a guide in experimentally implementing enough of it in an LDAP server to come up to speed enough to start the I-D. I very much appreciate the help. > > Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 23 15:23:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08571 for ; Wed, 23 Jun 2004 15:23:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdDDe-0006Jk-Ke; Wed, 23 Jun 2004 15:15:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd1lM-0005zM-Ij for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:01:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17924 for ; Wed, 23 Jun 2004 03:01:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd1lK-00058q-61 for ldapext@ietf.org; Wed, 23 Jun 2004 03:01:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BczrY-00044n-00 for ldapext@ietf.org; Wed, 23 Jun 2004 00:59:59 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1Bcwxv-0001lc-00 for ldapext@ietf.org; Tue, 22 Jun 2004 21:54:19 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 22 Jun 2004 19:53:51 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 22 Jun 2004 19:53:29 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I agree, it needs to state which procedures are to be followed (X.518, or yet-to-be document procedures in the I-D). I'm struggling with trying to understand the subtleties of the X.518 procedures enough to judge which direction is best. The X.518 procedures are a pain to follow because rather than stating the problems and then providing solutions, it just provides the solution and occasionally hints at the problems being solved. I will spend some time trying to put together a problem set, and then test whether the procedures I had in mind will solve that set. This message is getting long, so I'll reply to the remainder in different messages. Jim >>> "Ennis, Mark" 6/22/04 7:24:08 PM >>> Jim, My concern is not that you are not following X.518, but that you appear to be implying the X.518 procedures without providing the information required by those procedures. I think your draft needs to define the procedures for distributed operations for LDAP directories in order to ensure the information provided in the chaining arguments and results are sufficient to the procedures defined. More response in-line below. - Mark. Jim Sermersheim wrote: >>>>Mark Ennis 6/21/04 10:48:20 PM >>> >> >>The search will be chained with the >>targetObject of the chainingArguments set to the name of the superior of >>the DSE containing the subordinate reference > > > This is not what LDAP returns as the DN part of a referral URI. So if we did it this way, the target object in a chained operation would be different from the 'target object' of a referral. If there's a way to keep the 'target object' consistent between these, I'd prefer it. If I remember correctly, the argument for using the name of the superior of the subr DSE is so that multiple sibling subr DSEs, where the subordinate entries are in the same subordinate DSA, will result in a single continuation reference instead of one for each sibling, thereby reducing the number of chained operations required to complete the operation. It also makes the subr and nssr reference types generate equivalent continuation references. This may be another reason for the ChainingResults.alreadySearched field. > > >>and the >>operationProgress.nameResolutionPhase set to completed (cf. X.518 >>19.3.2.2.1 7a). This allows the subordinate DSA to confirm the >>targetObject is an immSupr DSE and proceed with the search from this >>point. >>If the subordinate DSA cannot resolve the targetObject as an >>immSupr DSE then it should generate ServiceError.unableToProceed to >>indicate an inconsistency in the hierarchical operational binding (i.e. >>the knowledge) between these DSAs. > > > My draft doesn't consider the need for checking the consistency of the distributed data model. If that is a requirement, I need to refactor it. I do have a couple questions relating to this. > > 1) Why must the immediatly superior name be passed as the targetObject? If the receiving DSA knows a chained operation is due to a subordinate reference (yes, that would require more information than the draft currently has), and the targetObject is set to the name of the DSE which caused the referral, then the receiving DSA can examine the parent of the targetObject if it wishes to perform a consistency check. Are there other reasons that the parent is sent as the targetObject? The targetObject is not set to the name of the superior of the subr DSE during name resolution. It is set to the target object of the operation, which may change from the originally supplied target object due to the dereferencing of aliases during name resolution. The operationProgress.nextRDNToBeResolved informs the subordinate DSA which RDN in the target object is the name of the context prefix to begin local name resolution on. > > 2) LDAP Servers often store a DN in the URI which represents knowledge information (RFC 3296). This DN does not have to name the DSE that holds the knowledge information. This can be useful (though potentially dangerous) when mapping a local name to a different remote name (let's call this "name mapping"). For example, I may have a server that holds a subr DSE (well, a RFC 3296 referral) named id=Sharks,id=MyStuff where the ref attribute holds a value ldap://zoology.org/order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata. I wouldn't clasify this as a good practice, but one that is allowed and used. If we pass the local name of a reference's parent as the target object (where that reference holds mapped names), it will surely cause any validation check to fail (in fact it will cause the operation to fail regardless of a validation check). The target object of the chainingArgument is not the superior of the subr DSE during name resolution. In the case of a named subordinate reference as defined in RFC 3296, it looks to me like a combination of an alias and a subordinate reference. I would re-write the target object by replacing the resolved portion with the name in the reference and then chain the request to the indicated server, if I was following X.518 procedures for distributed operation. > > So I guess two questions for the list are: > a) Is it required that the chained operation facilitate distributed data consistency checks? If so, must it be done in the same manner as X.518? > b) Is it required that the chained operation allow for a distributed data model where disparate namespaces can be joined via "name mapping"? > > >>X.518 assume that the first step for the processing of any operation is >>name resolution. The operationProgress is used to determine if the >>hierarchical operation binding (represented by the knowledge such as >>subordinate and superior references) is consistent. In the absence of >>the operationProgress, a subordinate DSA, on receiving a request for a >>naming context it does not recognise, will chain the request to a >>superior DSA. Where the hierarchical operational binding has become >>inconsistent between the superior and subordinate DSA, this could lead >>to a loop condition or an incorrect NameError.noSuchObject. > > > Right, for these scenarios I assumed that the return of either of these errors (loopDetected or noSuchObject) would suffice. The main difference is that normally ServiceError.unableToProceed is used by the X.518 procedures to cause another continuation reference to be used if one is available, while the NameError.noSuchObject and ServiceError.loopDetected cause the operation to complete with an error. This is particularly relevant to processing of non-specific subordinate references, where the problem is not due inconsistency in the HOB, but is due to lack of knowledge in the superior about which naming contexts exist in which subordinate DSAs. > > >>The operatonProgress in the traceInformation of the chaining arguments >>is used to support a situation where one DSA contains both superior and >>subordinate parts of the DIT to a second DSA. Because of aliases, the >>first DSA could have the same request chained to it at different points >>in the name resolution and needs to be able to distinguish between the >>incidents in order to allow the name resolution to complete. > > > If the targetObject sent to the first DSA is different each time the operation is chained to it, it should not detect a loop, and thus allow name resolution to progress. I can think of an example where the X.518 procedures would permit the same request to be chained to a DSA more than once, each time with the same target object but a different nextRDNToBeResolved. The example may not be very likely but is potentially possible in a complex topology. Suppose we have the following DSAs: DSA1 has two context prefixes: c=au and ou=development,o=adacel,c=au. DSA2 has one context prefix: o=adacel,c=au. DSA3 has one context prefix: ou=view500,ou=development,o=adacel,c=au. Appropriate hierarchical operational bindings have been established for: DSA1 -> DSA2 -> DSA1 -> DSA3. We are attempting name resolution on ou=testing,ou=view500,ou=development,o=adacel,c=au with from DSA1, but DSA3 in unavailable. DSA1 attempts name resolution and ends up with two candidate references, one to DSA2 and one to DSA3. Attempting to chain to DSA3 gets an unavailable error so the operation is chained to DSA2. DSA2 attempts name resolution and chains the operations back to DSA1. DSA1 now has a second go at the name resolution on the request which fails due to DSA3 being unavailable. The first attempt DSA1 makes to resolve the target object it has an operation progress of { nameResolutionPhase proceeding, nextRDNToBeResolved 1 } and the second time of { nameResolutionPhase proceeding, nextRDNToBeResolved 3 }. In X.518, the target object is the same. Without the operation progress information, the chained request from DSA2 to DSA1 would generate an incorrect loopDetected error. The X.518 procedures allow a implementation the choice on how to proceed based on an attempt to chain receiving a busy, unavailable, unwillingToPerform or invalidReference error. They can try a different candidate continuation reference or return an error. This choice leads to the situation I have described. I think situations with partial replicas could cause similar situations to occur. > > >>N.B. I have used the ITU-T Rec. X.518 (1993 E) as my reference for the >>X.500 procedures for distributed operations. As far as I am aware there >>are no significant differences in more recent editions of this >>recommendation. >> >>- Mark. > > > Thanks for the feedback. As you can tell, I have not implemented this, I have only used it as a guide in experimentally implementing enough of it in an LDAP server to come up to speed enough to start the I-D. I very much appreciate the help. > > Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:48:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28186 for ; Thu, 24 Jun 2004 12:48:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXHa-0000zW-7j; Thu, 24 Jun 2004 12:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd24V-0003JX-Jb for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:21:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23158 for ; Wed, 23 Jun 2004 03:21:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd24S-0000qT-U0 for ldapext@ietf.org; Wed, 23 Jun 2004 03:21:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0jm-0001L0-00 for ldapext@ietf.org; Wed, 23 Jun 2004 01:55:59 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcxLX-0004OY-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:18:43 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 22 Jun 2004 20:18:15 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 22 Jun 2004 20:17:49 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: [ldapext] superior of subrDSE while chaining a resolved operation X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >>> "Ennis, Mark" 6/22/04 7:24:08 PM >>> >If I remember correctly, the argument for using the name of the superior >of the subr DSE is so that multiple sibling subr DSEs, where the >subordinate entries are in the same subordinate DSA, will result in a >single continuation reference instead of one for each sibling, thereby >reducing the number of chained operations required to complete the >operation. I see (after reading a bit of the X.518 Continuation Reference procedures). This helps the case you mention, but gives rise to the case where each sibling subr DSE points to a different DSA. If each of those DSAs holds copies of the naming contexts of the others (those named by the other sibling subr DSEs), then the exclusions field must be used to ensure that duplicates aren't returned. >It also makes the subr and nssr reference types generate >equivalent continuation references. This may be another reason for the >ChainingResults.alreadySearched field. Yes. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:50:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28325 for ; Thu, 24 Jun 2004 12:50:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXHt-00011R-KB; Thu, 24 Jun 2004 12:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd25T-0003ZE-Qo for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:22:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23382 for ; Wed, 23 Jun 2004 03:22:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd25R-00011g-JD for ldapext@ietf.org; Wed, 23 Jun 2004 03:22:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0oq-00021R-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:01:13 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcxUG-0005F6-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:27:44 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 22 Jun 2004 20:27:16 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 22 Jun 2004 20:26:53 -0600 From: "Jim Sermersheim" To: Subject: ref DN != reference name (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,PLING_QUERY autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >>> "Ennis, Mark" 6/22/04 7:24:08 PM >>> >> 2) LDAP Servers often store a DN in the URI which represents knowledge information (RFC 3296). This DN does not have to name the DSE that holds the knowledge information. This can be useful (though potentially dangerous) when mapping a local name to a different remote name (let's call this "name mapping"). For example, I may have a server that holds a subr DSE (well, a RFC 3296 referral) named id=Sharks,id=MyStuff where the ref attribute holds a value ldap://zoology.org/order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata. I wouldn't clasify this as a good practice, but one that is allowed and used. If we pass the local name of a reference's parent as the target object (where that reference holds mapped names), it will surely cause any validation check to fail (in fact it will cause the operation to fail regardless of a validation check). > >The target object of the chainingArgument is not the superior of the >subr DSE during name resolution. I understand. I should have been more precise. >In the case of a named subordinate >reference as defined in RFC 3296, it looks to me like a combination of >an alias and a subordinate reference. I would re-write the target object >by replacing the resolved portion with the name in the reference and >then chain the request to the indicated server, if I was following X.518 >procedures for distributed operation. So you would re-write the target object as "id=Sharks,order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata". This wouldn't work, because the intent is that the name id=Sharks,id=MyStuff on my server is the same as the name order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata on the remote server. I'm still interested in what people think of allowing a name in the ref attribute to differ from the name of the reference object. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:50:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28378 for ; Thu, 24 Jun 2004 12:50:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXHt-00011W-U2; Thu, 24 Jun 2004 12:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd25a-0003ZO-Ot for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:22:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23406 for ; Wed, 23 Jun 2004 03:22:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd25X-00012b-8n for ldapext@ietf.org; Wed, 23 Jun 2004 03:22:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0pL-00027K-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:01:44 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BcxVW-0005Nb-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:29:02 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Wed, 23 Jun 2004 12:27:45 +1000 Received: (qmail 880 invoked from network); 23 Jun 2004 02:28:29 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 23 Jun 2004 02:28:29 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5N2SSF04476; Wed, 23 Jun 2004 12:28:28 +1000 Message-ID: <40D8EACB.4050905@adacel.com> Date: Wed, 23 Jun 2004 12:28:27 +1000 From: "Ennis, Mark" User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: [ldapext] Re: superior of subrDSE while chaining a resolved operation X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: >>>>"Ennis, Mark" 6/22/04 7:24:08 PM >>> > > > >>If I remember correctly, the argument for using the name of the > > superior > >>of the subr DSE is so that multiple sibling subr DSEs, where the >>subordinate entries are in the same subordinate DSA, will result in a > > >>single continuation reference instead of one for each sibling, thereby > > >>reducing the number of chained operations required to complete the >>operation. > > > I see (after reading a bit of the X.518 Continuation Reference > procedures). This helps the case you mention, but gives rise to the case > where each sibling subr DSE points to a different DSA. If each of those > DSAs holds copies of the naming contexts of the others (those named by > the other sibling subr DSEs), then the exclusions field must be used to > ensure that duplicates aren't returned. Either exclusions or dontUseCopy. > > >>It also makes the subr and nssr reference types generate >>equivalent continuation references. This may be another reason for the > > >>ChainingResults.alreadySearched field. > > > Yes. > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:50:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28466 for ; Thu, 24 Jun 2004 12:50:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXHu-00011g-B7; Thu, 24 Jun 2004 12:41:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd25u-0003e8-Qk for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:22:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23486 for ; Wed, 23 Jun 2004 03:22:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd25s-00016Z-Mk for ldapext@ietf.org; Wed, 23 Jun 2004 03:22:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0rL-0002Ug-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:03:48 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcxaM-0005t3-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:34:02 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 22 Jun 2004 20:33:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 22 Jun 2004 20:33:06 -0600 From: "Jim Sermersheim" To: Subject: Purpose of unableToProceed (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >>> "Ennis, Mark" 6/22/04 7:24:08 PM >>> >>>X.518 assume that the first step for the processing of any operation is >>>name resolution. The operationProgress is used to determine if the >>>hierarchical operation binding (represented by the knowledge such as >>>subordinate and superior references) is consistent. In the absence of >>>the operationProgress, a subordinate DSA, on receiving a request for a >>>naming context it does not recognise, will chain the request to a >>>superior DSA. Where the hierarchical operational binding has become >>>inconsistent between the superior and subordinate DSA, this could lead >>>to a loop condition or an incorrect NameError.noSuchObject. >> >> >> Right, for these scenarios I assumed that the return of either of these errors (loopDetected or noSuchObject) would suffice. > >The main difference is that normally ServiceError.unableToProceed is >used by the X.518 procedures to cause another continuation reference to >be used if one is available, while the NameError.noSuchObject and >ServiceError.loopDetected cause the operation to complete with an error. >This is particularly relevant to processing of non-specific subordinate >references, where the problem is not due inconsistency in the HOB, but >is due to lack of knowledge in the superior about which naming contexts >exist in which subordinate DSAs. So if a DSA holds inconsistent data which causes unableToProceed, but there is always other continuation reference information avaliable to progress the operation, will the inconsistency will go unnoticed? I failed to realize that this was a 'soft' error like busy, and unavailable are (also points I haven't yet mentioned in the I-D). Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:53:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28619 for ; Thu, 24 Jun 2004 12:53:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXHu-00011r-Qc; Thu, 24 Jun 2004 12:41:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd26A-0003ef-2r for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23567 for ; Wed, 23 Jun 2004 03:23:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd267-00019l-Px for ldapext@ietf.org; Wed, 23 Jun 2004 03:23:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0sD-0002f5-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:04:43 -0400 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcxci-00067u-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:36:28 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jun 2004 12:35:57 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) Date: Wed, 23 Jun 2004 12:35:56 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638101808324@ausyms21.ca.com> Thread-Topic: [ldapext] Chained Operation (control, extended op, or op?) Thread-Index: AcRYroILdqxX4c1iR8OrpbxKEOzdmgAGmS2w From: "Ramsay, Ron" To: "Jim Sermersheim" X-OriginalArrivalTime: 23 Jun 2004 02:35:57.0098 (UTC) FILETIME=[D01658A0:01C458CA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: mark.ennis@adacel.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable If the target object were the naming context of Server B, it would not = be changed when multichaining back to A? Therefore, without looking at = the state of name resolution, Server A would detect a loop. (You can't set the targetObject to the naming context of the server you = are sending the request *to* without changing the original request, = because a one-level search may have to be performed as a base-object = search. Mark has already said, I believe, that the target object in = X.500 is set to the context prefix of the server *sending* the request.) Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Wednesday, 23 June 2004 04:04 To: Ramsay, Ron Cc: ldapext@ietf.org; mark.ennis@adacel.com Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) I assumed that the host *and* target object were considered when performing loop detection. I haven't put this much detail in the draft yet, but I assumed I had it covered. Here's what I should have said about ChainedRequestValue.chainingArguments.traceInformation: << This contains a set of URIs. Each value represents the address of a DSA and DN that has already been contacted while trying to service the operation. The receiving DSA adds to this list, a URI (or URIs if it may be contacted using multiple addresses or ports) value containing its address and the target object of the operation. The target object is constructed using the value of ChainedRequestValue.chainingArguments.targetObject. If that value not present, then the value of the base object in the ChainedRequestValue.operationRequest is used. If, after adding its own URI(s) to this list, there are any two URIs that match a loopDetect (54) error is returned. Otherwise, the modified list is used if the operation is to be chained to a further DSA >> Thus, in your example, the new target object is different from the original target object when the operation is chained back to Server A, thus no loop. Similarly, since the target object points to a local naming context when the operation is chained back to Server A, it would not want to chain to Server B. There must be some scenario that I haven't thought about where the targetObject and dsa are not enough to detect a loop (or that they would cause a loop to be erroneously detected). Jim >>> "Ramsay, Ron" 6/22/04 1:07:36 AM >>> Jim, Operation progress is the only way of differentiating chaining from multichaining. For example, a request is sent to Server A, which *chains* it to Server B. Name resolution is not complete. Server B performs it and, if it is a search request, *multichains* is to subordinates A and C. Name resolution is completed. Note that, with the name-resolution indicator, Server A would normally return "loop detected" instead of performing the request. Also note that, without the name-resolution indication, Server A would want to chain the multichained request to Server B, again! Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On=20 Behalf Of Jim Sermersheim Sent: Tuesday, 22 June 2004 11:18 To: mark.ennis@adacel.com=20 Cc: ldapext@ietf.org=20 Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Thanks Mark, Yes, I do need to add better semantics and some implementation details. If people agree that this operation should be sent as an extended request, I'll do that and submit. I couldn't find a reason why operationProgress was needed. For example, today's LDAP servers return referrals and search result references which LDAP clients can follow. Nothing is conveyed regarding the operation progress when those clients follow these referrals and search referral references.=20 Furthermore, I don't understand what a receiving DSA does with this information. A receiving DSA will not get a nameResolutionPhase of completed, thus it's either notStarted or proceeding. Regardless of whether it's notStarted or proceeding, the targetObject contains the DN to be resolved (unless the value is the same as the base DN of the embedded operation). Will you let me know what I'm missing here? Some of the other fields are left for future controls that I haven't had time to write up (specifically referenceType, timeLimit, excludeShadows, and nameResolveOnMaster). Each of these have utility outside of the chained operation, so I think defining them as controls in their own documents would be better. Jim >>> Mark Ennis 6/21/04 6:35:13 PM >>> Jim, It is my opinion that you need to define your procedures for distributed=20 operations and define your chaining argument and chaining result based on those procedures. If you choose to assume that the procedures for=20 distributed operations are those defined in X.518, then you will need to=20 include fields in the chaining arguments and results that are required by those procedures. In particular, the operation progress information is critical to the name resolution procedures defined in X.518 and I do not see how you can use these procedures without this field in the=20 chaining arguments and in the trace information (and in referrals). Where information critical to X.518 procedures for distributed=20 operations is not supported, new procedures need to be defined to=20 accomodate chaining of LDAP operations. - Mark. Jim Sermersheim wrote: > All, >=20 > I'm attaching a not-ready-for-prime-time I-D which describes an LDAP > chained operation. Following X.518, I described it as an operation > (well, an extended operation) which contains the original message and > some chaining arguments. Some of my peers here have repeatedly argued > that there is no reason to define it as an extended operation, and that > a control makes more sense. >=20 > What do others think? I can go either way. >=20 > If it's a control, I'd want to reconsider the targetObject and > entryOnly fields. If the control holds these, and is sent as > non-critical, and the receiving server doesn't support the control, the > outcome will be erroneous.=20 >=20 > As an extended operation, we have two sets of resultCode, matchedDN, > errorMessage, and referral. This can be resolved by chosing yet another > solution: Create a whole new operation (don't use an extended > operation). The new operation would not include the elements of > LDAPResult (well, the resultCode might be nice, but referral and > matchedDN is confusing). >=20 > I'll publish once I get some feedback on this, and fix up some > editorial issues. >=20 > Jim >=20 >=20 >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:54:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28802 for ; Thu, 24 Jun 2004 12:54:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXHv-00012V-45; Thu, 24 Jun 2004 12:41:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd26O-0003kT-Mz for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:23:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23603 for ; Wed, 23 Jun 2004 03:23:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd26M-0001CL-HZ for ldapext@ietf.org; Wed, 23 Jun 2004 03:23:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0t7-0002od-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:05:39 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BcxfB-0006M4-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:39:01 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 22 Jun 2004 20:38:33 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 22 Jun 2004 20:38:05 -0600 From: "Jim Sermersheim" To: Subject: Need for operationProgress (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1256 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >>> "Ennis, Mark" 6/22/04 7:24:08 PM >>> For the example below, the procedures I was thinking of would work because = DSA1 would never attempt DSA2 (they don't keep track of all candidates = while taversing the hierarchy). Keeping track of all candidates does seem = beneficial though. Jim *---- Forwarded Message *---- =20 I can think of an example where the X.518 procedures would permit the=20 same request to be chained to a DSA more than once, each time with the=20 same target object but a different nextRDNToBeResolved. The example may=20 not be very likely but is potentially possible in a complex topology. Suppose we have the following DSAs: DSA1 has two context prefixes: c=3Dau and ou=3Ddevelopment,o=3Dadacel,c=3Da= u. DSA2 has one context prefix: o=3Dadacel,c=3Dau. DSA3 has one context prefix: ou=3Dview500,ou=3Ddevelopment,o=3Dadacel,c=3Da= u. Appropriate hierarchical operational bindings have been established for: DSA1 -> DSA2 -> DSA1 -> DSA3. We are attempting name resolution on=20 ou=3Dtesting,ou=3Dview500,ou=3Ddevelopment,o=3Dadacel,c=3Dau with from = DSA1, but=20 DSA3 in unavailable. DSA1 attempts name resolution and ends up with two candidate references,=20= one to DSA2 and one to DSA3. Attempting to chain to DSA3 gets an=20 unavailable error so the operation is chained to DSA2. DSA2 attempts=20 name resolution and chains the operations back to DSA1. DSA1 now has a=20 second go at the name resolution on the request which fails due to DSA3=20 being unavailable. The first attempt DSA1 makes to resolve the target object it has an=20 operation progress of { nameResolutionPhase proceeding,=20 nextRDNToBeResolved 1 } and the second time of { nameResolutionPhase=20 proceeding, nextRDNToBeResolved 3 }. In X.518, the target object is the=20 same. Without the operation progress information, the chained request=20 from DSA2 to DSA1 would generate an incorrect loopDetected error. The X.518 procedures allow a implementation the choice on how to proceed=20= based on an attempt to chain receiving a busy, unavailable,=20 unwillingToPerform or invalidReference error. They can try a different=20 candidate continuation reference or return an error. This choice leads=20 to the situation I have described. I think situations with partial replicas could cause similar situations=20 to occur. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:55:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28903 for ; Thu, 24 Jun 2004 12:55:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXI3-00015s-Sj; Thu, 24 Jun 2004 12:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd26g-0003ku-T0 for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:23:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23708 for ; Wed, 23 Jun 2004 03:23:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd26e-0001F0-KP for ldapext@ietf.org; Wed, 23 Jun 2004 03:23:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0uB-0002zk-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:06:45 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BcxhZ-0006al-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:41:29 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Wed, 23 Jun 2004 12:40:14 +1000 Received: (qmail 3625 invoked from network); 23 Jun 2004 02:40:59 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 23 Jun 2004 02:40:59 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5N2exF04540; Wed, 23 Jun 2004 12:40:59 +1000 Message-ID: <40D8EDB9.7060103@adacel.com> Date: Wed, 23 Jun 2004 12:40:57 +1000 From: "Ennis, Mark" User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: ref DN != reference name (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,PLING_QUERY autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: >>>>"Ennis, Mark" 6/22/04 7:24:08 PM >>> > > > >>>2) LDAP Servers often store a DN in the URI which represents > > knowledge information (RFC 3296). This DN does not have to name the DSE > that holds the knowledge information. This can be useful (though > potentially dangerous) when mapping a local name to a different remote > name (let's call this "name mapping"). For example, I may have a server > that holds a subr DSE (well, a RFC 3296 referral) named > id=Sharks,id=MyStuff where the ref attribute holds a value > ldap://zoology.org/order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata. > I wouldn't clasify this as a good practice, but one that is allowed and > used. If we pass the local name of a reference's parent as the target > object (where that reference holds mapped names), it will surely cause > any validation check to fail (in fact it will cause the operation to > fail regardless of a validation check). > >>The target object of the chainingArgument is not the superior of the >>subr DSE during name resolution. > > > I understand. I should have been more precise. > > >>In the case of a named subordinate >>reference as defined in RFC 3296, it looks to me like a combination of > > >>an alias and a subordinate reference. I would re-write the target > > object > >>by replacing the resolved portion with the name in the reference and >>then chain the request to the indicated server, if I was following > > X.518 > >>procedures for distributed operation. > > > So you would re-write the target object as > "id=Sharks,order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata". > This wouldn't work, because the intent is that the name > id=Sharks,id=MyStuff on my server is the same as the name > order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata > on the remote server. Well no, I would rewrite the name as though the named subordinate reference were an alias entry, i.e. the name would become order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata. In X.500 information model, I would represent the id=Sharks,id=MyStuff entry using an alias to order=Selachimorpha,sublcass=Elasmobranchii,class=Chondrichthyes,superclass=Gnathostomata and I would use an subr DSE at superclass=Gnathostomata to chain the request. > > I'm still interested in what people think of allowing a name in the ref > attribute to differ from the name of the reference object. > > Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:56:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29022 for ; Thu, 24 Jun 2004 12:56:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXI4-00015x-8V; Thu, 24 Jun 2004 12:41:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd26q-0003mk-FJ for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:23:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23743 for ; Wed, 23 Jun 2004 03:23:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd26o-0001H4-AP for ldapext@ietf.org; Wed, 23 Jun 2004 03:23:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0v3-00039h-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:07:39 -0400 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcxjw-0006po-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:43:56 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jun 2004 12:43:26 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) Date: Wed, 23 Jun 2004 12:43:26 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638101808346@ausyms21.ca.com> Thread-Topic: [ldapext] Chained Operation (control, extended op, or op?) Thread-Index: AcRYtQRnguTrF4LuR6m5FDjnUKHSJwAFo04A From: "Ramsay, Ron" To: "Jim Sermersheim" X-OriginalArrivalTime: 23 Jun 2004 02:43:26.0405 (UTC) FILETIME=[DBE52750:01C458CB] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: mark.ennis@adacel.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I would think that the simplest method would be to only change the = target object if an alias was dereferenced (or a name was *mapped*) and = use operationProgress to prevent errors. Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On = Behalf Of Jim Sermersheim Sent: Wednesday, 23 June 2004 05:56 To: mark.ennis@adacel.com Cc: ldapext@ietf.org Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) >>> Mark Ennis 6/21/04 10:48:20 PM >>> >Jim, > >The operationProgress becomes important in name resolution when DSAs=20 >have subordinate/superior relationships. Traditionally LDAP servers are = >defined as "First-level DSAs" which means that the operationProgress=20 >information is of little value in processing of referrals. I'm not sure I agree with this statement. Many LDAP servers are required = to be populated with the context prefixes of the naming contexts they = hold. Some allow a superior referral, but others don't. I think the = distributed data model has never been fully defined for LDAP servers, so = to date, the servers are a mish-mash of different elements of First = Level DSAs and non First Level DSAs.=20 Regardless of that, I am interested in finding out what scenarios = require operationProgress. >It is not true that a receiving DSA will not get a nameResolutionPhase=20 >of "completed". This can occur when processing a search operation, = where=20 >name resolution has completed, but the scope of the search includes a=20 >reference to a subordinate DSA.=20 You're right * I wasn't thinking. >The search will be chained with the=20 >targetObject of the chainingArguments set to the name of the superior = of=20 >the DSE containing the subordinate reference=20 This is not what LDAP returns as the DN part of a referral URI. So if we = did it this way, the target object in a chained operation would be = different from the 'target object' of a referral. If there's a way to = keep the 'target object' consistent between these, I'd prefer it. >and the=20 >operationProgress.nameResolutionPhase set to completed (cf. X.518=20 >19.3.2.2.1 7a). This allows the subordinate DSA to confirm the=20 >targetObject is an immSupr DSE and proceed with the search from this=20 >point.=20 >If the subordinate DSA cannot resolve the targetObject as an=20 >immSupr DSE then it should generate ServiceError.unableToProceed to=20 >indicate an inconsistency in the hierarchical operational binding (i.e. = >the knowledge) between these DSAs. My draft doesn't consider the need for checking the consistency of the = distributed data model. If that is a requirement, I need to refactor it. = I do have a couple questions relating to this. 1) Why must the immediatly superior name be passed as the targetObject? = If the receiving DSA knows a chained operation is due to a subordinate = reference (yes, that would require more information than the draft = currently has), and the targetObject is set to the name of the DSE which = caused the referral, then the receiving DSA can examine the parent of = the targetObject if it wishes to perform a consistency check. Are there = other reasons that the parent is sent as the targetObject? 2) LDAP Servers often store a DN in the URI which represents knowledge = information (RFC 3296). This DN does not have to name the DSE that holds = the knowledge information. This can be useful (though potentially = dangerous) when mapping a local name to a different remote name (let's = call this "name mapping"). For example, I may have a server that holds a = subr DSE (well, a RFC 3296 referral) named id=3DSharks,id=3DMyStuff = where the ref attribute holds a value = ldap://zoology.org/order=3DSelachimorpha,sublcass=3DElasmobranchii,class=3D= Chondrichthyes,superclass=3DGnathostomata. I wouldn't clasify this as a = good practice, but one that is allowed and used. If we pass the local = name of a reference's parent as the target object (where that reference = holds mapped names), it will surely cause any validation check to fail = (in fact it will cause the operation to fail regardless of a validation = check). So I guess two questions for the list are: a) Is it required that the chained operation facilitate distributed data = consistency checks? If so, must it be done in the same manner as X.518? b) Is it required that the chained operation allow for a distributed = data model where disparate namespaces can be joined via "name mapping"? >X.518 assume that the first step for the processing of any operation is = >name resolution. The operationProgress is used to determine if the=20 >hierarchical operation binding (represented by the knowledge such as=20 >subordinate and superior references) is consistent. In the absence of=20 >the operationProgress, a subordinate DSA, on receiving a request for a=20 >naming context it does not recognise, will chain the request to a=20 >superior DSA. Where the hierarchical operational binding has become=20 >inconsistent between the superior and subordinate DSA, this could lead=20 >to a loop condition or an incorrect NameError.noSuchObject. Right, for these scenarios I assumed that the return of either of these = errors (loopDetected or noSuchObject) would suffice. >The operatonProgress in the traceInformation of the chaining arguments=20 >is used to support a situation where one DSA contains both superior and = >subordinate parts of the DIT to a second DSA. Because of aliases, the=20 >first DSA could have the same request chained to it at different points = >in the name resolution and needs to be able to distinguish between the=20 >incidents in order to allow the name resolution to complete. If the targetObject sent to the first DSA is different each time the = operation is chained to it, it should not detect a loop, and thus allow = name resolution to progress. >N.B. I have used the ITU-T Rec. X.518 (1993 E) as my reference for the=20 >X.500 procedures for distributed operations. As far as I am aware there = >are no significant differences in more recent editions of this=20 >recommendation. > >- Mark. Thanks for the feedback. As you can tell, I have not implemented this, I = have only used it as a guide in experimentally implementing enough of it = in an LDAP server to come up to speed enough to start the I-D. I very = much appreciate the help. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:58:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29215 for ; Thu, 24 Jun 2004 12:58:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXI5-00016P-Kd; Thu, 24 Jun 2004 12:41:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd27m-0003xS-Tr for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:24:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23955 for ; Wed, 23 Jun 2004 03:24:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd27k-0001Qc-Jl for ldapext@ietf.org; Wed, 23 Jun 2004 03:24:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0xz-0003h8-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:10:40 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcxr8-0007n4-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:51:22 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Wed, 23 Jun 2004 12:50:07 +1000 Received: (qmail 5788 invoked from network); 23 Jun 2004 02:50:51 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 23 Jun 2004 02:50:51 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5N2opF04598; Wed, 23 Jun 2004 12:50:51 +1000 Message-ID: <40D8F00A.40101@adacel.com> Date: Wed, 23 Jun 2004 12:50:50 +1000 From: "Ennis, Mark" User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: Purpose of unableToProceed (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: >>>>"Ennis, Mark" 6/22/04 7:24:08 PM >>> > > > >>>>X.518 assume that the first step for the processing of any operation > > is > >>>>name resolution. The operationProgress is used to determine if the >>>>hierarchical operation binding (represented by the knowledge such as > > >>>>subordinate and superior references) is consistent. In the absence > > of > >>>>the operationProgress, a subordinate DSA, on receiving a request for > > a > >>>>naming context it does not recognise, will chain the request to a >>>>superior DSA. Where the hierarchical operational binding has become > > >>>>inconsistent between the superior and subordinate DSA, this could > > lead > >>>>to a loop condition or an incorrect NameError.noSuchObject. >>> >>> >>>Right, for these scenarios I assumed that the return of either of > > these errors (loopDetected or noSuchObject) would suffice. > >>The main difference is that normally ServiceError.unableToProceed is >>used by the X.518 procedures to cause another continuation reference > > to > >>be used if one is available, while the NameError.noSuchObject and >>ServiceError.loopDetected cause the operation to complete with an > > error. > >>This is particularly relevant to processing of non-specific > > subordinate > >>references, where the problem is not due inconsistency in the HOB, but > > >>is due to lack of knowledge in the superior about which naming > > contexts > >>exist in which subordinate DSAs. > > > So if a DSA holds inconsistent data which causes unableToProceed, but > there is always other continuation reference information avaliable to > progress the operation, will the inconsistency will go unnoticed? I > failed to realize that this was a 'soft' error like busy, and > unavailable are (also points I haven't yet mentioned in the I-D). unableToProceed is definitely a "soft" error. "Real" inconsistencies in the HOB should result in an invalidReference error. The problem I see is where X.518 is being used without the operationProgress. This could result in error messages which do not accurately represent the situation in the distributed directory environment. > > Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 12:58:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29232 for ; Thu, 24 Jun 2004 12:58:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXI5-00016U-W8; Thu, 24 Jun 2004 12:41:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd285-00041b-GJ for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:25:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24039 for ; Wed, 23 Jun 2004 03:25:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd283-0001Tu-BC for ldapext@ietf.org; Wed, 23 Jun 2004 03:25:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd0yq-0003rC-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:11:34 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1Bcxsv-0000BX-00 for ldapext@ietf.org; Tue, 22 Jun 2004 22:53:13 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 22 Jun 2004 20:52:45 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 22 Jun 2004 20:52:21 -0600 From: "Jim Sermersheim" To: Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, mark.ennis@adacel.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit >>> "Ramsay, Ron" 6/22/04 8:35:56 PM >>> >If the target object were the naming context of Server B, it would not be changed when multichaining back to A? Therefore, without looking at the state of name resolution, Server A would detect a loop. No, when Server B multichains the request to Server A, it sets the ChainingArguments.targetObject to the subordinate naming context (or in the case of the X.518 procedures, to the parent DN of that naming context). >(You can't set the targetObject to the naming context of the server you are sending the request *to* without changing the original request, because a one-level search may have to be performed as a base-object search. Mark has already said, I believe, that the target object in X.500 is set to the context prefix of the server *sending* the request.) Ok, then I'm confused. I thought in this case, X.518 says that the ChainingArguments.targetObject is set to the parent of the subr DSE. So unless that is a cp, it wouldn't be set to any cp. Furthermore, if the original search has a scope of one-level, the X.518 procedures, by passing the parent of the naming context in the ChainingArguments.targetObject, automatically solve the problem since the recieving DSA only has a single child under that targetObject. Jim >Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Wednesday, 23 June 2004 04:04 To: Ramsay, Ron Cc: ldapext@ietf.org; mark.ennis@adacel.com Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) I assumed that the host *and* target object were considered when performing loop detection. I haven't put this much detail in the draft yet, but I assumed I had it covered. Here's what I should have said about ChainedRequestValue.chainingArguments.traceInformation: << This contains a set of URIs. Each value represents the address of a DSA and DN that has already been contacted while trying to service the operation. The receiving DSA adds to this list, a URI (or URIs if it may be contacted using multiple addresses or ports) value containing its address and the target object of the operation. The target object is constructed using the value of ChainedRequestValue.chainingArguments.targetObject. If that value not present, then the value of the base object in the ChainedRequestValue.operationRequest is used. If, after adding its own URI(s) to this list, there are any two URIs that match a loopDetect (54) error is returned. Otherwise, the modified list is used if the operation is to be chained to a further DSA >> Thus, in your example, the new target object is different from the original target object when the operation is chained back to Server A, thus no loop. Similarly, since the target object points to a local naming context when the operation is chained back to Server A, it would not want to chain to Server B. There must be some scenario that I haven't thought about where the targetObject and dsa are not enough to detect a loop (or that they would cause a loop to be erroneously detected). Jim >>> "Ramsay, Ron" 6/22/04 1:07:36 AM >>> Jim, Operation progress is the only way of differentiating chaining from multichaining. For example, a request is sent to Server A, which *chains* it to Server B. Name resolution is not complete. Server B performs it and, if it is a search request, *multichains* is to subordinates A and C. Name resolution is completed. Note that, with the name-resolution indicator, Server A would normally return "loop detected" instead of performing the request. Also note that, without the name-resolution indication, Server A would want to chain the multichained request to Server B, again! Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Tuesday, 22 June 2004 11:18 To: mark.ennis@adacel.com Cc: ldapext@ietf.org Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Thanks Mark, Yes, I do need to add better semantics and some implementation details. If people agree that this operation should be sent as an extended request, I'll do that and submit. I couldn't find a reason why operationProgress was needed. For example, today's LDAP servers return referrals and search result references which LDAP clients can follow. Nothing is conveyed regarding the operation progress when those clients follow these referrals and search referral references. Furthermore, I don't understand what a receiving DSA does with this information. A receiving DSA will not get a nameResolutionPhase of completed, thus it's either notStarted or proceeding. Regardless of whether it's notStarted or proceeding, the targetObject contains the DN to be resolved (unless the value is the same as the base DN of the embedded operation). Will you let me know what I'm missing here? Some of the other fields are left for future controls that I haven't had time to write up (specifically referenceType, timeLimit, excludeShadows, and nameResolveOnMaster). Each of these have utility outside of the chained operation, so I think defining them as controls in their own documents would be better. Jim >>> Mark Ennis 6/21/04 6:35:13 PM >>> Jim, It is my opinion that you need to define your procedures for distributed operations and define your chaining argument and chaining result based on those procedures. If you choose to assume that the procedures for distributed operations are those defined in X.518, then you will need to include fields in the chaining arguments and results that are required by those procedures. In particular, the operation progress information is critical to the name resolution procedures defined in X.518 and I do not see how you can use these procedures without this field in the chaining arguments and in the trace information (and in referrals). Where information critical to X.518 procedures for distributed operations is not supported, new procedures need to be defined to accomodate chaining of LDAP operations. - Mark. Jim Sermersheim wrote: > All, > > I'm attaching a not-ready-for-prime-time I-D which describes an LDAP > chained operation. Following X.518, I described it as an operation > (well, an extended operation) which contains the original message and > some chaining arguments. Some of my peers here have repeatedly argued > that there is no reason to define it as an extended operation, and that > a control makes more sense. > > What do others think? I can go either way. > > If it's a control, I'd want to reconsider the targetObject and > entryOnly fields. If the control holds these, and is sent as > non-critical, and the receiving server doesn't support the control, the > outcome will be erroneous. > > As an extended operation, we have two sets of resultCode, matchedDN, > errorMessage, and referral. This can be resolved by chosing yet another > solution: Create a whole new operation (don't use an extended > operation). The new operation would not include the elements of > LDAPResult (well, the resultCode might be nice, but referral and > matchedDN is confusing). > > I'll publish once I get some feedback on this, and fix up some > editorial issues. > > Jim > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 13:03:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29697 for ; Thu, 24 Jun 2004 13:03:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXIC-00019C-94; Thu, 24 Jun 2004 12:41:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2FT-0005NR-LK for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:32:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25544 for ; Wed, 23 Jun 2004 03:32:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2FR-0002ju-4O for ldapext@ietf.org; Wed, 23 Jun 2004 03:32:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd1FX-0006qp-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:28:48 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BcyeV-0004FD-00 for ldapext@ietf.org; Tue, 22 Jun 2004 23:42:23 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Wed, 23 Jun 2004 13:41:06 +1000 Received: (qmail 16978 invoked from network); 23 Jun 2004 03:41:51 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 23 Jun 2004 03:41:51 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5N3fpF04841; Wed, 23 Jun 2004 13:41:51 +1000 Message-ID: <40D8FBFD.8010101@adacel.com> Date: Wed, 23 Jun 2004 13:41:49 +1000 From: "Ennis, Mark" User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: Need for operationProgress (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: >>>>"Ennis, Mark" 6/22/04 7:24:08 PM >>> > > > For the example below, the procedures I was thinking of would work because DSA1 would never attempt DSA2 (they don't keep track of all candidates while taversing the hierarchy). Keeping track of all candidates does seem beneficial though. It can be useful as it potentially allows use of alternate routes through the network and can take advantage of systems' differing knowledge of available replicas for particular parts of the DIT. On the other hand it can lead to extra work which ultimately leads to the same result. - Mark. > > Jim > > *---- Forwarded Message *---- > > > I can think of an example where the X.518 procedures would permit the > same request to be chained to a DSA more than once, each time with the > same target object but a different nextRDNToBeResolved. The example may > not be very likely but is potentially possible in a complex topology. > > Suppose we have the following DSAs: > > DSA1 has two context prefixes: c=au and ou=development,o=adacel,c=au. > DSA2 has one context prefix: o=adacel,c=au. > DSA3 has one context prefix: ou=view500,ou=development,o=adacel,c=au. > > Appropriate hierarchical operational bindings have been established for: > DSA1 -> DSA2 -> DSA1 -> DSA3. > > We are attempting name resolution on > ou=testing,ou=view500,ou=development,o=adacel,c=au with from DSA1, but > DSA3 in unavailable. > > DSA1 attempts name resolution and ends up with two candidate references, > one to DSA2 and one to DSA3. Attempting to chain to DSA3 gets an > unavailable error so the operation is chained to DSA2. DSA2 attempts > name resolution and chains the operations back to DSA1. DSA1 now has a > second go at the name resolution on the request which fails due to DSA3 > being unavailable. > > The first attempt DSA1 makes to resolve the target object it has an > operation progress of { nameResolutionPhase proceeding, > nextRDNToBeResolved 1 } and the second time of { nameResolutionPhase > proceeding, nextRDNToBeResolved 3 }. In X.518, the target object is the > same. Without the operation progress information, the chained request > from DSA2 to DSA1 would generate an incorrect loopDetected error. > > The X.518 procedures allow a implementation the choice on how to proceed > based on an attempt to chain receiving a busy, unavailable, > unwillingToPerform or invalidReference error. They can try a different > candidate continuation reference or return an error. This choice leads > to the situation I have described. > > I think situations with partial replicas could cause similar situations > to occur. > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 13:11:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00539 for ; Thu, 24 Jun 2004 13:11:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXIM-0001Do-R0; Thu, 24 Jun 2004 12:41:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2PV-0007V5-VJ for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:43:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27478 for ; Wed, 23 Jun 2004 03:43:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2PT-0004vy-Ny for ldapext@ietf.org; Wed, 23 Jun 2004 03:43:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd1fT-00044X-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:55:36 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BczcV-0002c1-00 for ldapext@ietf.org; Wed, 23 Jun 2004 00:44:23 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 22 Jun 2004 22:43:54 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 22 Jun 2004 22:43:30 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I'm currently judging consensus in favor of using an extended operation to pass the chained operation between DSAs. If you disagree, please reply. Some other things to consider are: Would it be better to create a new operation? Is it strange to allow intermediate responses to be returned in a chained response? Let me know if you have any issues, otherwise, I'll try to move forward. Jim >>> "Jim Sermersheim" 6/21/04 11:51:31 AM >>> All, I'm attaching a not-ready-for-prime-time I-D which describes an LDAP chained operation. Following X.518, I described it as an operation (well, an extended operation) which contains the original message and some chaining arguments. Some of my peers here have repeatedly argued that there is no reason to define it as an extended operation, and that a control makes more sense. What do others think? I can go either way. If it's a control, I'd want to reconsider the targetObject and entryOnly fields. If the control holds these, and is sent as non-critical, and the receiving server doesn't support the control, the outcome will be erroneous. As an extended operation, we have two sets of resultCode, matchedDN, errorMessage, and referral. This can be resolved by chosing yet another solution: Create a whole new operation (don't use an extended operation). The new operation would not include the elements of LDAPResult (well, the resultCode might be nice, but referral and matchedDN is confusing). I'll publish once I get some feedback on this, and fix up some editorial issues. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 13:12:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00652 for ; Thu, 24 Jun 2004 13:12:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXIO-0001Ey-J0; Thu, 24 Jun 2004 12:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2Ru-0007jS-VV for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:45:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28170 for ; Wed, 23 Jun 2004 03:45:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2Rs-0005L1-LB for ldapext@ietf.org; Wed, 23 Jun 2004 03:45:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd1nY-0005Rs-00 for ldapext@ietf.org; Wed, 23 Jun 2004 03:03:59 -0400 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1BczxR-0004Pk-00 for ldapext@ietf.org; Wed, 23 Jun 2004 01:06:01 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jun 2004 15:05:30 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) Date: Wed, 23 Jun 2004 15:05:30 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B63810180857A@ausyms21.ca.com> Thread-Topic: [ldapext] Chained Operation (control, extended op, or op?) Thread-Index: AcRYzTfqQBQ7eqDhSVW8YEdmpwGhowABQ47Q From: "Ramsay, Ron" To: "Jim Sermersheim" X-OriginalArrivalTime: 23 Jun 2004 05:05:30.0561 (UTC) FILETIME=[B4B02310:01C458DF] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org, mark.ennis@adacel.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable After reading through X.518 I'm a little confused, too. Firstly, it = seems to say that, when multichaining, targetObject should be set to the = name of the reference, which is usually the context prefix of the target = system. For a one-level search, entryOnly is also set. However, Figure 23 seems to imply that targetObject is set to the = immediate superior of the reference. If you were to proceed on the basis of setting targetObject to the DN of = the reference when multichaining, I think you are right that you don't = need operationProgress. However, you will need entryOnly for one-level = searches. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Wednesday, 23 June 2004 12:52 To: Ramsay, Ron Cc: mark.ennis@adacel.com; ldapext@ietf.org Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) >>> "Ramsay, Ron" 6/22/04 8:35:56 PM >>> >If the target object were the naming context of Server B, it would not be changed when multichaining back to A? Therefore, without looking at the state of name resolution, Server A would detect a loop. No, when Server B multichains the request to Server A, it sets the ChainingArguments.targetObject to the subordinate naming context (or in the case of the X.518 procedures, to the parent DN of that naming context). >(You can't set the targetObject to the naming context of the server you are sending the request *to* without changing the original request, because a one-level search may have to be performed as a base-object search. Mark has already said, I believe, that the target object in X.500 is set to the context prefix of the server *sending* the request.) Ok, then I'm confused. I thought in this case, X.518 says that the ChainingArguments.targetObject is set to the parent of the subr DSE. So unless that is a cp, it wouldn't be set to any cp. Furthermore, if the original search has a scope of one-level, the X.518 procedures, by passing the parent of the naming context in the ChainingArguments.targetObject, automatically solve the problem since the recieving DSA only has a single child under that targetObject. Jim >Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On=20 Behalf Of Jim Sermersheim Sent: Wednesday, 23 June 2004 04:04 To: Ramsay, Ron Cc: ldapext@ietf.org; mark.ennis@adacel.com=20 Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) I assumed that the host *and* target object were considered when performing loop detection. I haven't put this much detail in the draft yet, but I assumed I had it covered. Here's what I should have said about ChainedRequestValue.chainingArguments.traceInformation: << This contains a set of URIs. Each value represents the address of a DSA and DN that has already been contacted while trying to service the operation. The receiving DSA adds to this list, a URI (or URIs if it may be contacted using multiple addresses or ports) value containing its address and the target object of the operation. The target object is constructed using the value of ChainedRequestValue.chainingArguments.targetObject. If that value not present, then the value of the base object in the ChainedRequestValue.operationRequest is used. If, after adding its own URI(s) to this list, there are any two URIs that match a loopDetect (54) error is returned. Otherwise, the modified list is used if the operation is to be chained to a further DSA >> Thus, in your example, the new target object is different from the original target object when the operation is chained back to Server A, thus no loop. Similarly, since the target object points to a local naming context when the operation is chained back to Server A, it would not want to chain to Server B. There must be some scenario that I haven't thought about where the targetObject and dsa are not enough to detect a loop (or that they would cause a loop to be erroneously detected). Jim >>> "Ramsay, Ron" 6/22/04 1:07:36 AM >>> Jim, Operation progress is the only way of differentiating chaining from multichaining. For example, a request is sent to Server A, which *chains* it to Server B. Name resolution is not complete. Server B performs it and, if it is a search request, *multichains* is to subordinates A and C. Name resolution is completed. Note that, with the name-resolution indicator, Server A would normally return "loop detected" instead of performing the request. Also note that, without the name-resolution indication, Server A would want to chain the multichained request to Server B, again! Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On=20 Behalf Of Jim Sermersheim Sent: Tuesday, 22 June 2004 11:18 To: mark.ennis@adacel.com=20 Cc: ldapext@ietf.org=20 Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Thanks Mark, Yes, I do need to add better semantics and some implementation details. If people agree that this operation should be sent as an extended request, I'll do that and submit. I couldn't find a reason why operationProgress was needed. For example, today's LDAP servers return referrals and search result references which LDAP clients can follow. Nothing is conveyed regarding the operation progress when those clients follow these referrals and search referral references.=20 Furthermore, I don't understand what a receiving DSA does with this information. A receiving DSA will not get a nameResolutionPhase of completed, thus it's either notStarted or proceeding. Regardless of whether it's notStarted or proceeding, the targetObject contains the DN to be resolved (unless the value is the same as the base DN of the embedded operation). Will you let me know what I'm missing here? Some of the other fields are left for future controls that I haven't had time to write up (specifically referenceType, timeLimit, excludeShadows, and nameResolveOnMaster). Each of these have utility outside of the chained operation, so I think defining them as controls in their own documents would be better. Jim >>> Mark Ennis 6/21/04 6:35:13 PM >>> Jim, It is my opinion that you need to define your procedures for distributed=20 operations and define your chaining argument and chaining result based on those procedures. If you choose to assume that the procedures for=20 distributed operations are those defined in X.518, then you will need to=20 include fields in the chaining arguments and results that are required by those procedures. In particular, the operation progress information is critical to the name resolution procedures defined in X.518 and I do not see how you can use these procedures without this field in the=20 chaining arguments and in the trace information (and in referrals). Where information critical to X.518 procedures for distributed=20 operations is not supported, new procedures need to be defined to=20 accomodate chaining of LDAP operations. - Mark. Jim Sermersheim wrote: > All, >=20 > I'm attaching a not-ready-for-prime-time I-D which describes an LDAP > chained operation. Following X.518, I described it as an operation > (well, an extended operation) which contains the original message and > some chaining arguments. Some of my peers here have repeatedly argued > that there is no reason to define it as an extended operation, and that > a control makes more sense. >=20 > What do others think? I can go either way. >=20 > If it's a control, I'd want to reconsider the targetObject and > entryOnly fields. If the control holds these, and is sent as > non-critical, and the receiving server doesn't support the control, the > outcome will be erroneous.=20 >=20 > As an extended operation, we have two sets of resultCode, matchedDN, > errorMessage, and referral. This can be resolved by chosing yet another > solution: Create a whole new operation (don't use an extended > operation). The new operation would not include the elements of > LDAPResult (well, the resultCode might be nice, but referral and > matchedDN is confusing). >=20 > I'll publish once I get some feedback on this, and fix up some > editorial issues. >=20 > Jim >=20 >=20 >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 13:16:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01168 for ; Thu, 24 Jun 2004 13:16:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXIZ-0001NK-Vy; Thu, 24 Jun 2004 12:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2YK-0000f8-QV for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:52:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29545 for ; Wed, 23 Jun 2004 03:52:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2YI-0006RQ-LM for ldapext@ietf.org; Wed, 23 Jun 2004 03:52:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd26A-0001AN-00 for ldapext@ietf.org; Wed, 23 Jun 2004 03:23:13 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1Bd0sY-0002dA-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:05:02 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 23 Jun 2004 00:04:33 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 23 Jun 2004 00:04:03 -0600 From: "Jim Sermersheim" To: Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, mark.ennis@adacel.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Yes, this was my initial (mis)understanding of entryOnly. It seems that it's only needed when a one-level search encounters an alias that it must dereference (after name resolution has completed). I still need to read more. I get confused by the type of pseudo-code found in 19.3.2.2.1.7)b) where it says "if the value of the subset parameter is oneLevel, set entryOnly to True". Are they talking about ChainingArguments.entryOnly, ContinuationReference.entryOnly, or some local entryOnly? I guess I'm discouraged by the notion that one needs to reverse engineer pseudo-code to understand the subtleties of the arguments being passed around. Your last statement makes sense, other than it removes some of the niceties explained by Mark in other messages (consistency checks and indirectly, alternate referral candidates). I'll likely lose sleep tonight. Jim >>> "Ramsay, Ron" 6/22/04 11:05:30 PM >>> After reading through X.518 I'm a little confused, too. Firstly, it seems to say that, when multichaining, targetObject should be set to the name of the reference, which is usually the context prefix of the target system. For a one-level search, entryOnly is also set. However, Figure 23 seems to imply that targetObject is set to the immediate superior of the reference. If you were to proceed on the basis of setting targetObject to the DN of the reference when multichaining, I think you are right that you don't need operationProgress. However, you will need entryOnly for one-level searches. Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Wednesday, 23 June 2004 12:52 To: Ramsay, Ron Cc: mark.ennis@adacel.com; ldapext@ietf.org Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) >>> "Ramsay, Ron" 6/22/04 8:35:56 PM >>> >If the target object were the naming context of Server B, it would not be changed when multichaining back to A? Therefore, without looking at the state of name resolution, Server A would detect a loop. No, when Server B multichains the request to Server A, it sets the ChainingArguments.targetObject to the subordinate naming context (or in the case of the X.518 procedures, to the parent DN of that naming context). >(You can't set the targetObject to the naming context of the server you are sending the request *to* without changing the original request, because a one-level search may have to be performed as a base-object search. Mark has already said, I believe, that the target object in X.500 is set to the context prefix of the server *sending* the request.) Ok, then I'm confused. I thought in this case, X.518 says that the ChainingArguments.targetObject is set to the parent of the subr DSE. So unless that is a cp, it wouldn't be set to any cp. Furthermore, if the original search has a scope of one-level, the X.518 procedures, by passing the parent of the naming context in the ChainingArguments.targetObject, automatically solve the problem since the recieving DSA only has a single child under that targetObject. Jim >Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Wednesday, 23 June 2004 04:04 To: Ramsay, Ron Cc: ldapext@ietf.org; mark.ennis@adacel.com Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) I assumed that the host *and* target object were considered when performing loop detection. I haven't put this much detail in the draft yet, but I assumed I had it covered. Here's what I should have said about ChainedRequestValue.chainingArguments.traceInformation: << This contains a set of URIs. Each value represents the address of a DSA and DN that has already been contacted while trying to service the operation. The receiving DSA adds to this list, a URI (or URIs if it may be contacted using multiple addresses or ports) value containing its address and the target object of the operation. The target object is constructed using the value of ChainedRequestValue.chainingArguments.targetObject. If that value not present, then the value of the base object in the ChainedRequestValue.operationRequest is used. If, after adding its own URI(s) to this list, there are any two URIs that match a loopDetect (54) error is returned. Otherwise, the modified list is used if the operation is to be chained to a further DSA >> Thus, in your example, the new target object is different from the original target object when the operation is chained back to Server A, thus no loop. Similarly, since the target object points to a local naming context when the operation is chained back to Server A, it would not want to chain to Server B. There must be some scenario that I haven't thought about where the targetObject and dsa are not enough to detect a loop (or that they would cause a loop to be erroneously detected). Jim >>> "Ramsay, Ron" 6/22/04 1:07:36 AM >>> Jim, Operation progress is the only way of differentiating chaining from multichaining. For example, a request is sent to Server A, which *chains* it to Server B. Name resolution is not complete. Server B performs it and, if it is a search request, *multichains* is to subordinates A and C. Name resolution is completed. Note that, with the name-resolution indicator, Server A would normally return "loop detected" instead of performing the request. Also note that, without the name-resolution indication, Server A would want to chain the multichained request to Server B, again! Ron -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Jim Sermersheim Sent: Tuesday, 22 June 2004 11:18 To: mark.ennis@adacel.com Cc: ldapext@ietf.org Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Thanks Mark, Yes, I do need to add better semantics and some implementation details. If people agree that this operation should be sent as an extended request, I'll do that and submit. I couldn't find a reason why operationProgress was needed. For example, today's LDAP servers return referrals and search result references which LDAP clients can follow. Nothing is conveyed regarding the operation progress when those clients follow these referrals and search referral references. Furthermore, I don't understand what a receiving DSA does with this information. A receiving DSA will not get a nameResolutionPhase of completed, thus it's either notStarted or proceeding. Regardless of whether it's notStarted or proceeding, the targetObject contains the DN to be resolved (unless the value is the same as the base DN of the embedded operation). Will you let me know what I'm missing here? Some of the other fields are left for future controls that I haven't had time to write up (specifically referenceType, timeLimit, excludeShadows, and nameResolveOnMaster). Each of these have utility outside of the chained operation, so I think defining them as controls in their own documents would be better. Jim >>> Mark Ennis 6/21/04 6:35:13 PM >>> Jim, It is my opinion that you need to define your procedures for distributed operations and define your chaining argument and chaining result based on those procedures. If you choose to assume that the procedures for distributed operations are those defined in X.518, then you will need to include fields in the chaining arguments and results that are required by those procedures. In particular, the operation progress information is critical to the name resolution procedures defined in X.518 and I do not see how you can use these procedures without this field in the chaining arguments and in the trace information (and in referrals). Where information critical to X.518 procedures for distributed operations is not supported, new procedures need to be defined to accomodate chaining of LDAP operations. - Mark. Jim Sermersheim wrote: > All, > > I'm attaching a not-ready-for-prime-time I-D which describes an LDAP > chained operation. Following X.518, I described it as an operation > (well, an extended operation) which contains the original message and > some chaining arguments. Some of my peers here have repeatedly argued > that there is no reason to define it as an extended operation, and that > a control makes more sense. > > What do others think? I can go either way. > > If it's a control, I'd want to reconsider the targetObject and > entryOnly fields. If the control holds these, and is sent as > non-critical, and the receiving server doesn't support the control, the > outcome will be erroneous. > > As an extended operation, we have two sets of resultCode, matchedDN, > errorMessage, and referral. This can be resolved by chosing yet another > solution: Create a whole new operation (don't use an extended > operation). The new operation would not include the elements of > LDAPResult (well, the resultCode might be nice, but referral and > matchedDN is confusing). > > I'll publish once I get some feedback on this, and fix up some > editorial issues. > > Jim > > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 13:18:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01389 for ; Thu, 24 Jun 2004 13:18:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXIm-0001RU-Oh; Thu, 24 Jun 2004 12:42:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2fR-0002lc-O3 for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 03:59:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01104 for ; Wed, 23 Jun 2004 03:59:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2fM-0007RG-3q for ldapext@ietf.org; Wed, 23 Jun 2004 03:59:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2FV-0002kh-00 for ldapext@ietf.org; Wed, 23 Jun 2004 03:32:51 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd1Fx-0006pr-00 for ldapext@ietf.org; Wed, 23 Jun 2004 02:29:13 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Wed, 23 Jun 2004 16:27:56 +1000 Received: (qmail 23630 invoked from network); 23 Jun 2004 06:28:42 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 23 Jun 2004 06:28:42 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5N6SfF05757; Wed, 23 Jun 2004 16:28:42 +1000 Message-ID: <40D92317.60407@adacel.com> Date: Wed, 23 Jun 2004 16:28:39 +1000 From: "Ennis, Mark" User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, Ron.Ramsay@ca.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim, I agree with your interpretation of the ChainingArguments.entryOnly only being required for a oneLevel search when a subordinate of the target object is an alias. I think the use of entryOnly in sentences like the one you quoted are local parameters for the pseudo code. I also agree it is confusing. - Mark. Jim Sermersheim wrote: > Yes, this was my initial (mis)understanding of entryOnly. It seems that > it's only needed when a one-level search encounters an alias that it > must dereference (after name resolution has completed). I still need to > read more. I get confused by the type of pseudo-code found in > 19.3.2.2.1.7)b) where it says "if the value of the subset parameter is > oneLevel, set entryOnly to True". Are they talking about > ChainingArguments.entryOnly, ContinuationReference.entryOnly, or some > local entryOnly? I guess I'm discouraged by the notion that one needs to > reverse engineer pseudo-code to understand the subtleties of the > arguments being passed around. > > Your last statement makes sense, other than it removes some of the > niceties explained by Mark in other messages (consistency checks and > indirectly, alternate referral candidates). I'll likely lose sleep > tonight. > > Jim > > >>>>"Ramsay, Ron" 6/22/04 11:05:30 PM >>> > > After reading through X.518 I'm a little confused, too. Firstly, it > seems to say that, when multichaining, targetObject should be set to the > name of the reference, which is usually the context prefix of the target > system. For a one-level search, entryOnly is also set. > > However, Figure 23 seems to imply that targetObject is set to the > immediate superior of the reference. > > If you were to proceed on the basis of setting targetObject to the DN > of the reference when multichaining, I think you are right that you > don't need operationProgress. However, you will need entryOnly for > one-level searches. > > Ron > > -----Original Message----- > From: Jim Sermersheim [mailto:jimse@novell.com] > Sent: Wednesday, 23 June 2004 12:52 > To: Ramsay, Ron > Cc: mark.ennis@adacel.com; ldapext@ietf.org > Subject: RE: [ldapext] Chained Operation (control, extended op, or > op?) > > > >>>>"Ramsay, Ron" 6/22/04 8:35:56 PM >>> >> >>If the target object were the naming context of Server B, it would > > not > be changed when multichaining back to A? Therefore, without looking at > the state of name resolution, Server A would detect a loop. > > No, when Server B multichains the request to Server A, it sets the > ChainingArguments.targetObject to the subordinate naming context (or > in > the case of the X.518 procedures, to the parent DN of that naming > context). > > >>(You can't set the targetObject to the naming context of the server > > you are sending the request *to* without changing the original > request, > because a one-level search may have to be performed as a base-object > search. Mark has already said, I believe, that the target object in > X.500 is set to the context prefix of the server *sending* the > request.) > > Ok, then I'm confused. I thought in this case, X.518 says that the > ChainingArguments.targetObject is set to the parent of the subr DSE. > So > unless that is a cp, it wouldn't be set to any cp. Furthermore, if the > original search has a scope of one-level, the X.518 procedures, by > passing the parent of the naming context in the > ChainingArguments.targetObject, automatically solve the problem since > the recieving DSA only has a single child under that targetObject. > > Jim > > >>Ron > > > -----Original Message----- > From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On > Behalf Of Jim Sermersheim > Sent: Wednesday, 23 June 2004 04:04 > To: Ramsay, Ron > Cc: ldapext@ietf.org; mark.ennis@adacel.com > Subject: RE: [ldapext] Chained Operation (control, extended op, or > op?) > > > I assumed that the host *and* target object were considered when > performing loop detection. I haven't put this much detail in the draft > yet, but I assumed I had it covered. Here's what I should have said > about ChainedRequestValue.chainingArguments.traceInformation: > << > This contains a set of URIs. Each value represents the address of a > DSA > and DN that has already been contacted while trying to service the > operation. > > The receiving DSA adds to this list, a URI (or URIs if it may be > contacted using multiple addresses or ports) value containing its > address and the target object of the operation. The target object is > constructed using the value of > ChainedRequestValue.chainingArguments.targetObject. If that value not > present, then the value of the base object in the > ChainedRequestValue.operationRequest is used. > > If, after adding its own URI(s) to this list, there are any two URIs > that match a loopDetect (54) > error > is returned. Otherwise, the modified list is used if the operation is > to > be chained to a further DSA > > > Thus, in your example, the new target object is different from the > original target object when the operation is chained back to Server A, > thus no loop. Similarly, since the target object points to a local > naming context when the operation is chained back to Server A, it > would > not want to chain to Server B. > > There must be some scenario that I haven't thought about where the > targetObject and dsa are not enough to detect a loop (or that they > would > cause a loop to be erroneously detected). > > Jim > > >>>>"Ramsay, Ron" 6/22/04 1:07:36 AM >>> > > Jim, > > Operation progress is the only way of differentiating chaining from > multichaining. > > For example, a request is sent to Server A, which *chains* it to > Server > B. Name resolution is not complete. Server B performs it and, if it is > a > search request, *multichains* is to subordinates A and C. Name > resolution is completed. Note that, with the name-resolution > indicator, > Server A would normally return "loop detected" instead of performing > the > request. Also note that, without the name-resolution indication, > Server > A would want to chain the multichained request to Server B, again! > > Ron > > -----Original Message----- > From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On > Behalf Of Jim Sermersheim > Sent: Tuesday, 22 June 2004 11:18 > To: mark.ennis@adacel.com > Cc: ldapext@ietf.org > Subject: Re: [ldapext] Chained Operation (control, extended op, or > op?) > > > Thanks Mark, > > Yes, I do need to add better semantics and some implementation > details. > If people agree that this operation should be sent as an extended > request, I'll do that and submit. > > I couldn't find a reason why operationProgress was needed. For > example, > today's LDAP servers return referrals and search result references > which > LDAP clients can follow. Nothing is conveyed regarding the operation > progress when those clients follow these referrals and search referral > references. > > Furthermore, I don't understand what a receiving DSA does with this > information. A receiving DSA will not get a nameResolutionPhase of > completed, thus it's either notStarted or proceeding. Regardless of > whether it's notStarted or proceeding, the targetObject contains the > DN > to be resolved (unless the value is the same as the base DN of the > embedded operation). Will you let me know what I'm missing here? > > Some of the other fields are left for future controls that I haven't > had time to write up (specifically referenceType, timeLimit, > excludeShadows, and nameResolveOnMaster). Each of these have utility > outside of the chained operation, so I think defining them as controls > in their own documents would be better. > > Jim > > >>>>Mark Ennis 6/21/04 6:35:13 PM >>> > > Jim, > > It is my opinion that you need to define your procedures for > distributed > operations and define your chaining argument and chaining result based > > on those procedures. If you choose to assume that the procedures for > distributed operations are those defined in X.518, then you will need > to > include fields in the chaining arguments and results that are required > > by those procedures. In particular, the operation progress information > > is critical to the name resolution procedures defined in X.518 and I > do > > not see how you can use these procedures without this field in the > chaining arguments and in the trace information (and in referrals). > > Where information critical to X.518 procedures for distributed > operations is not supported, new procedures need to be defined to > accomodate chaining of LDAP operations. > > - Mark. > > Jim Sermersheim wrote: > > >>All, >> >>I'm attaching a not-ready-for-prime-time I-D which describes an LDAP >>chained operation. Following X.518, I described it as an operation >>(well, an extended operation) which contains the original message > > and > >>some chaining arguments. Some of my peers here have repeatedly > > argued > >>that there is no reason to define it as an extended operation, and > > that > >>a control makes more sense. >> >>What do others think? I can go either way. >> >>If it's a control, I'd want to reconsider the targetObject and >>entryOnly fields. If the control holds these, and is sent as >>non-critical, and the receiving server doesn't support the control, > > the > >>outcome will be erroneous. >> >>As an extended operation, we have two sets of resultCode, matchedDN, >>errorMessage, and referral. This can be resolved by chosing yet > > another > >>solution: Create a whole new operation (don't use an extended >>operation). The new operation would not include the elements of >>LDAPResult (well, the resultCode might be nice, but referral and >>matchedDN is confusing). >> >>I'll publish once I get some feedback on this, and fix up some >>editorial issues. >> >>Jim >> >> >> > > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 13:20:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01628 for ; Thu, 24 Jun 2004 13:20:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJ2-0001Xq-Ap; Thu, 24 Jun 2004 12:42:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd2mz-0004O9-9j for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 04:07:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02209 for ; Wed, 23 Jun 2004 04:07:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd2mx-0001OR-2l for ldapext@ietf.org; Wed, 23 Jun 2004 04:07:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd2RD-0005Eb-00 for ldapext@ietf.org; Wed, 23 Jun 2004 03:44:58 -0400 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd1lC-000519-00 for ldapext@ietf.org; Wed, 23 Jun 2004 03:01:30 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jun 2004 17:00:59 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) Date: Wed, 23 Jun 2004 17:00:59 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B6381018087F4@ausyms21.ca.com> Thread-Topic: [ldapext] Chained Operation (control, extended op, or op?) Thread-Index: AcRY64qiHmSG9vlWSqyb9OPfpRz8kQAA4/zw From: "Ramsay, Ron" To: "Ennis, Mark" , "Jim Sermersheim" X-OriginalArrivalTime: 23 Jun 2004 07:00:59.0613 (UTC) FILETIME=[D6B990D0:01C458EF] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I would think entryOnly is required even if an alias was not = dereferenced. The target DSA will receive a one-level search from its = root so it will perform it. But the sender may be wanting it to do a = base-object search. The target DSA will not know which is required. The pseudo-code maintains a list of continuation references, and this is = where targetObject and entryOnly are placed. When the request is = multichained to another DSA, these items are copied into the chaining = arguments. If the request is not sent, the continuation reference can be = added to the result. Ron -----Original Message----- From: Ennis, Mark [mailto:mark.ennis@adacel.com] Sent: Wednesday, 23 June 2004 16:29 To: Jim Sermersheim Cc: Ramsay, Ron; ldapext@ietf.org Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Jim, I agree with your interpretation of the ChainingArguments.entryOnly only = being required for a oneLevel search when a subordinate of the target=20 object is an alias. I think the use of entryOnly in sentences like the=20 one you quoted are local parameters for the pseudo code. I also agree it = is confusing. - Mark. Jim Sermersheim wrote: > Yes, this was my initial (mis)understanding of entryOnly. It seems = that > it's only needed when a one-level search encounters an alias that it > must dereference (after name resolution has completed). I still need = to > read more. I get confused by the type of pseudo-code found in > 19.3.2.2.1.7)b) where it says "if the value of the subset parameter is > oneLevel, set entryOnly to True". Are they talking about > ChainingArguments.entryOnly, ContinuationReference.entryOnly, or some > local entryOnly? I guess I'm discouraged by the notion that one needs = to > reverse engineer pseudo-code to understand the subtleties of the > arguments being passed around. >=20 > Your last statement makes sense, other than it removes some of the > niceties explained by Mark in other messages (consistency checks and > indirectly, alternate referral candidates). I'll likely lose sleep > tonight. >=20 > Jim >=20 >=20 >>>>"Ramsay, Ron" 6/22/04 11:05:30 PM >>> >=20 > After reading through X.518 I'm a little confused, too. Firstly, it > seems to say that, when multichaining, targetObject should be set to = the > name of the reference, which is usually the context prefix of the = target > system. For a one-level search, entryOnly is also set. >=20 > However, Figure 23 seems to imply that targetObject is set to the > immediate superior of the reference. >=20 > If you were to proceed on the basis of setting targetObject to the DN > of the reference when multichaining, I think you are right that you > don't need operationProgress. However, you will need entryOnly for > one-level searches. >=20 > Ron >=20 > -----Original Message----- > From: Jim Sermersheim [mailto:jimse@novell.com]=20 > Sent: Wednesday, 23 June 2004 12:52 > To: Ramsay, Ron > Cc: mark.ennis@adacel.com; ldapext@ietf.org=20 > Subject: RE: [ldapext] Chained Operation (control, extended op, or > op?) >=20 >=20 >=20 >>>>"Ramsay, Ron" 6/22/04 8:35:56 PM >>> >> >>If the target object were the naming context of Server B, it would >=20 > not > be changed when multichaining back to A? Therefore, without looking at > the state of name resolution, Server A would detect a loop. >=20 > No, when Server B multichains the request to Server A, it sets the > ChainingArguments.targetObject to the subordinate naming context (or > in > the case of the X.518 procedures, to the parent DN of that naming > context). >=20 >=20 >>(You can't set the targetObject to the naming context of the server >=20 > you are sending the request *to* without changing the original > request, > because a one-level search may have to be performed as a base-object > search. Mark has already said, I believe, that the target object in > X.500 is set to the context prefix of the server *sending* the > request.) >=20 > Ok, then I'm confused. I thought in this case, X.518 says that the > ChainingArguments.targetObject is set to the parent of the subr DSE. > So > unless that is a cp, it wouldn't be set to any cp. Furthermore, if the > original search has a scope of one-level, the X.518 procedures, by > passing the parent of the naming context in the > ChainingArguments.targetObject, automatically solve the problem since > the recieving DSA only has a single child under that targetObject. >=20 > Jim >=20 >=20 >>Ron >=20 >=20 > -----Original Message----- > From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On=20 > Behalf Of Jim Sermersheim > Sent: Wednesday, 23 June 2004 04:04 > To: Ramsay, Ron > Cc: ldapext@ietf.org; mark.ennis@adacel.com=20 > Subject: RE: [ldapext] Chained Operation (control, extended op, or > op?) >=20 >=20 > I assumed that the host *and* target object were considered when > performing loop detection. I haven't put this much detail in the draft > yet, but I assumed I had it covered. Here's what I should have said > about ChainedRequestValue.chainingArguments.traceInformation: > << > This contains a set of URIs. Each value represents the address of a > DSA > and DN that has already been contacted while trying to service the > operation. >=20 > The receiving DSA adds to this list, a URI (or URIs if it may be > contacted using multiple addresses or ports) value containing its > address and the target object of the operation. The target object is > constructed using the value of > ChainedRequestValue.chainingArguments.targetObject. If that value not > present, then the value of the base object in the > ChainedRequestValue.operationRequest is used. >=20 > If, after adding its own URI(s) to this list, there are any two URIs > that match a loopDetect (54) > error > is returned. Otherwise, the modified list is used if the operation is > to > be chained to a further DSA >=20 >=20 > Thus, in your example, the new target object is different from the > original target object when the operation is chained back to Server A, > thus no loop. Similarly, since the target object points to a local > naming context when the operation is chained back to Server A, it > would > not want to chain to Server B. >=20 > There must be some scenario that I haven't thought about where the > targetObject and dsa are not enough to detect a loop (or that they > would > cause a loop to be erroneously detected). >=20 > Jim >=20 >=20 >>>>"Ramsay, Ron" 6/22/04 1:07:36 AM >>> >=20 > Jim, >=20 > Operation progress is the only way of differentiating chaining from > multichaining. >=20 > For example, a request is sent to Server A, which *chains* it to > Server > B. Name resolution is not complete. Server B performs it and, if it is > a > search request, *multichains* is to subordinates A and C. Name > resolution is completed. Note that, with the name-resolution > indicator, > Server A would normally return "loop detected" instead of performing > the > request. Also note that, without the name-resolution indication, > Server > A would want to chain the multichained request to Server B, again! >=20 > Ron >=20 > -----Original Message----- > From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On=20 > Behalf Of Jim Sermersheim > Sent: Tuesday, 22 June 2004 11:18 > To: mark.ennis@adacel.com=20 > Cc: ldapext@ietf.org=20 > Subject: Re: [ldapext] Chained Operation (control, extended op, or > op?) >=20 >=20 > Thanks Mark, >=20 > Yes, I do need to add better semantics and some implementation > details. > If people agree that this operation should be sent as an extended > request, I'll do that and submit. >=20 > I couldn't find a reason why operationProgress was needed. For > example, > today's LDAP servers return referrals and search result references > which > LDAP clients can follow. Nothing is conveyed regarding the operation > progress when those clients follow these referrals and search referral > references.=20 >=20 > Furthermore, I don't understand what a receiving DSA does with this > information. A receiving DSA will not get a nameResolutionPhase of > completed, thus it's either notStarted or proceeding. Regardless of > whether it's notStarted or proceeding, the targetObject contains the > DN > to be resolved (unless the value is the same as the base DN of the > embedded operation). Will you let me know what I'm missing here? >=20 > Some of the other fields are left for future controls that I haven't > had time to write up (specifically referenceType, timeLimit, > excludeShadows, and nameResolveOnMaster). Each of these have utility > outside of the chained operation, so I think defining them as controls > in their own documents would be better. >=20 > Jim >=20 >=20 >>>>Mark Ennis 6/21/04 6:35:13 PM >>> >=20 > Jim, >=20 > It is my opinion that you need to define your procedures for > distributed=20 > operations and define your chaining argument and chaining result based >=20 > on those procedures. If you choose to assume that the procedures for=20 > distributed operations are those defined in X.518, then you will need > to=20 > include fields in the chaining arguments and results that are required >=20 > by those procedures. In particular, the operation progress information >=20 > is critical to the name resolution procedures defined in X.518 and I > do >=20 > not see how you can use these procedures without this field in the=20 > chaining arguments and in the trace information (and in referrals). >=20 > Where information critical to X.518 procedures for distributed=20 > operations is not supported, new procedures need to be defined to=20 > accomodate chaining of LDAP operations. >=20 > - Mark. >=20 > Jim Sermersheim wrote: >=20 >=20 >>All, >> >>I'm attaching a not-ready-for-prime-time I-D which describes an LDAP >>chained operation. Following X.518, I described it as an operation >>(well, an extended operation) which contains the original message >=20 > and >=20 >>some chaining arguments. Some of my peers here have repeatedly >=20 > argued >=20 >>that there is no reason to define it as an extended operation, and >=20 > that >=20 >>a control makes more sense. >> >>What do others think? I can go either way. >> >>If it's a control, I'd want to reconsider the targetObject and >>entryOnly fields. If the control holds these, and is sent as >>non-critical, and the receiving server doesn't support the control, >=20 > the >=20 >>outcome will be erroneous.=20 >> >>As an extended operation, we have two sets of resultCode, matchedDN, >>errorMessage, and referral. This can be resolved by chosing yet >=20 > another >=20 >>solution: Create a whole new operation (don't use an extended >>operation). The new operation would not include the elements of >>LDAPResult (well, the resultCode might be nice, but referral and >>matchedDN is confusing). >> >>I'll publish once I get some feedback on this, and fix up some >>editorial issues. >> >>Jim >> >> >> >=20 >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ldapext=20 >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ldapext=20 >=20 >=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 15:32:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18491 for ; Thu, 24 Jun 2004 15:32:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPk-0003Yu-3V; Thu, 24 Jun 2004 12:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdFFv-0006LV-05 for ldapext@megatron.ietf.org; Wed, 23 Jun 2004 17:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19827 for ; Wed, 23 Jun 2004 17:26:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdFFt-0001gK-BV for ldapext@ietf.org; Wed, 23 Jun 2004 17:26:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdFF7-0001JE-00 for ldapext@ietf.org; Wed, 23 Jun 2004 17:25:18 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BdFEV-0000uA-00 for ldapext@ietf.org; Wed, 23 Jun 2004 17:24:39 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 23 Jun 2004 15:24:09 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 23 Jun 2004 15:23:51 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] ChainedOperation.targetObject (are nssr's required)? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit All, As has been discussed recently, X.518 sets the ChainedOperation.targetObject to the parent of the next naming context when multi-chaining (post name resolution) a one-level or subtree search subrequest. There are a number of reasons for doing this -- some of which seem to address consistency checks and performance issues. But there is at least one reason that is required. When multi-chaining a search subrequest due to an nssr DSE, one has no choice but to pass the parent of the next naming context (since the next naming context's name is unknown). Given that there is this requirement for multi-chaining due to an nssr DSE, I can see proceeding in one of these ways: 1) State that for subrequests (chained requests after name resolution has completed), ChainedOperation.targetObject is set to the name of the reference DSE that caused chaining to happen (this may be overridden by a DN in the ref attribute). In the case of a subr DSE, it will be the name of the next naming context. In the case of an nssr, it is the name of the parent of the next naming context. 2)To support the other (performance and consistency) benefits, and to more seamlessly integrate with existing X.500 implementations, follow the X.518 model in this regard. I'm just trying to test the waters to see which path to give preference to. If lots of people strongly prefer #2, I might as well not even investigate #1 any further. Thanks. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 15:55:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22013 for ; Thu, 24 Jun 2004 15:55:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXQr-00047V-7Y; Thu, 24 Jun 2004 12:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdN32-00015b-4h for ldapext@megatron.ietf.org; Thu, 24 Jun 2004 01:45:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20282 for ; Thu, 24 Jun 2004 01:45:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdN2z-0000X7-KW for ldapext@ietf.org; Thu, 24 Jun 2004 01:45:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdN26-0000Aj-00 for ldapext@ietf.org; Thu, 24 Jun 2004 01:44:23 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BdN12-0007G2-00 for ldapext@ietf.org; Thu, 24 Jun 2004 01:43:16 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 23 Jun 2004 23:42:46 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 23 Jun 2004 23:42:17 -0600 From: "Jim Sermersheim" To: , "Jim Sermersheim" Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Regarding intermediate response (like searchResultEntry) embedded in a ChainedResponse Extended Response. I think the proper way to do this is to use an IntermediateResponse message to embed these. So, for a chained search, the searchResultEntry and searchResultReference messages woul dbe returned in a ChainedResponse IntermediateResponse message, while the searchResultDone would be returned in a ChainedResponse ExtendedResponse message. Jim >>> Jim Sermersheim 6/23/04 11:37:46 PM >>> I'm currently judging consensus in favor of using an extended operation to pass the chained operation between DSAs. If you disagree, please reply. Some other things to consider are: Would it be better to create a new operation? Is it strange to allow intermediate responses to be returned in a chained response? Let me know if you have any issues, otherwise, I'll try to move forward. Jim >>> "Jim Sermersheim" 6/21/04 11:51:31 AM >>> All, I'm attaching a not-ready-for-prime-time I-D which describes an LDAP chained operation. Following X.518, I described it as an operation (well, an extended operation) which contains the original message and some chaining arguments. Some of my peers here have repeatedly argued that there is no reason to define it as an extended operation, and that a control makes more sense. What do others think? I can go either way. If it's a control, I'd want to reconsider the targetObject and entryOnly fields. If the control holds these, and is sent as non-critical, and the receiving server doesn't support the control, the outcome will be erroneous. As an extended operation, we have two sets of resultCode, matchedDN, errorMessage, and referral. This can be resolved by chosing yet another solution: Create a whole new operation (don't use an extended operation). The new operation would not include the elements of LDAPResult (well, the resultCode might be nice, but referral and matchedDN is confusing). I'll publish once I get some feedback on this, and fix up some editorial issues. Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 17:31:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14154 for ; Thu, 24 Jun 2004 17:31:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdbFe-0006mc-Ow; Thu, 24 Jun 2004 16:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdYm5-0002BK-V9 for ldapext@megatron.ietf.org; Thu, 24 Jun 2004 14:16:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08272 for ; Thu, 24 Jun 2004 14:16:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdYm4-0006qw-NY for ldapext@ietf.org; Thu, 24 Jun 2004 14:16:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdYYt-00043S-00 for ldapext@ietf.org; Thu, 24 Jun 2004 14:02:59 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BdYJN-0001Oh-00 for ldapext@ietf.org; Thu, 24 Jun 2004 13:46:57 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 24 Jun 2004 11:46:27 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 24 Jun 2004 11:45:58 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] searchable archive? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit The archive at http://www.openldap.org/lists/ietf-ldapext/ is only current up through April, The archive at ftp://ftp.ietf.org/ietf-mail-archive/ldapext/ isn't very searchable. Is there just a problem with the openldap archive that needs to be fixed, or is it being decommissioned? Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 19:54:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03917 for ; Thu, 24 Jun 2004 19:54:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bddn3-0006Ps-5T; Thu, 24 Jun 2004 19:37:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BddS5-0000ic-Nu for ldapext@megatron.ietf.org; Thu, 24 Jun 2004 19:16:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28955 for ; Thu, 24 Jun 2004 19:16:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddDk-0007Ye-0c for ldapext@ietf.org; Thu, 24 Jun 2004 19:01:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdcbd-00064m-00 for ldapext@ietf.org; Thu, 24 Jun 2004 18:22:06 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BdbvI-0005n9-00 for ldapext@ietf.org; Thu, 24 Jun 2004 17:38:21 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5OLcKMC014667; Thu, 24 Jun 2004 21:38:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040624143713.048a2720@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 24 Jun 2004 14:38:25 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] searchable archive? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 10:45 AM 6/24/2004, Jim Sermersheim wrote: >The archive at http://www.openldap.org/lists/ietf-ldapext/ is only >current up through April, I'll fix this in a bit... >The archive at >ftp://ftp.ietf.org/ietf-mail-archive/ldapext/ isn't very searchable. Many of the IETF lists have search archives off of www1.ietf.org. Don't know if that includes the ldapext list or not. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 24 19:56:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04081 for ; Thu, 24 Jun 2004 19:56:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BddoF-0006nq-IB; Thu, 24 Jun 2004 19:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bddgo-0003QZ-Hs for ldapext@megatron.ietf.org; Thu, 24 Jun 2004 19:31:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29878 for ; Thu, 24 Jun 2004 19:31:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddfQ-0006fL-FM for ldapext@ietf.org; Thu, 24 Jun 2004 19:30:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BddSi-0003bM-00 for ldapext@ietf.org; Thu, 24 Jun 2004 19:16:56 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1Bdd4v-0004p6-00 for ldapext@ietf.org; Thu, 24 Jun 2004 18:52:21 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 24 Jun 2004 16:51:51 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 24 Jun 2004 16:51:30 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] searchable archive? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit I should have mentioned that the one https://www1.ietf.org/mailman/private/ldapext/ is empty. >>> "Kurt D. Zeilenga" 6/24/04 3:38:25 PM >>> At 10:45 AM 6/24/2004, Jim Sermersheim wrote: >The archive at http://www.openldap.org/lists/ietf-ldapext/ is only >current up through April, I'll fix this in a bit... >The archive at >ftp://ftp.ietf.org/ietf-mail-archive/ldapext/ isn't very searchable. Many of the IETF lists have search archives off of www1.ietf.org. Don't know if that includes the ldapext list or not. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 03:21:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13300 for ; Fri, 25 Jun 2004 03:21:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdkrZ-0001ar-Tn; Fri, 25 Jun 2004 03:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdkYS-0004iU-3D for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 02:51:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11587 for ; Fri, 25 Jun 2004 02:51:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdkYL-0001D4-FB for ldapext@ietf.org; Fri, 25 Jun 2004 02:51:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdkWZ-0000KC-00 for ldapext@ietf.org; Fri, 25 Jun 2004 02:49:24 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 1BdkUz-0007GI-00 for ldapext@ietf.org; Fri, 25 Jun 2004 02:47:45 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.6.7) id ; Fri, 25 Jun 2004 16:46:11 +1000 Received: (qmail 11915 invoked from network); 25 Jun 2004 06:47:12 -0000 Received: from unknown (HELO edmund.mtwav.adacel.com.au) (10.32.24.160) by nexus.adacel.com with SMTP; 25 Jun 2004 06:47:12 -0000 Received: from adacel.com (xenon.mtwav.adacel.com.au [10.32.24.164]) by edmund.mtwav.adacel.com.au (8.11.6/8.11.6) with ESMTP id i5P6lAF26466; Fri, 25 Jun 2004 16:47:11 +1000 Message-ID: <40DBCA6C.2010703@adacel.com> Date: Fri, 25 Jun 2004 16:47:08 +1000 From: Mark Ennis User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) References: <6.0.1.1.0.20040621154840.02c97a48@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040621154840.02c97a48@127.0.0.1> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > BTW, I'd like to add support for chaining SASL bind exchanges. > This will require some fields beyond those offered by the > X.518 ChainingArguments/ChainingResults structures. I agree that a mechanism for chaining SASL bind exchanges would be useful, however, current chaining mechanisms (e.g. X.518 or LDAP referrals) depend on name resolution of a base object. The bind operation, particularly when using a SASL mechanism, does not have a base object for the name resolution process. This would mean special procedures for "chaining" this operation. Does this also require formalising some type of trust model between DSAs if we are going to delegate authentication operations to another server? Is it possible to translate this SASL bind exchange into a LDAP operation the initiating DSA invokes, e.g. a search for the SASL "username" with a control used to transmit the SASL credentials and receive the SASL auth-response? Such an operation may then be chained by the responding DSA(s) and authorization decisions will be done using the initiating DSA as the authorization identity? - Mark. > > Kurt > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 04:15:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15914 for ; Fri, 25 Jun 2004 04:15:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdlc6-0007hF-9D; Fri, 25 Jun 2004 03:59:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdla3-0006HV-0O for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 03:57:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15264 for ; Fri, 25 Jun 2004 03:56:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdlZz-0001SN-Ms for ldapext@ietf.org; Fri, 25 Jun 2004 03:56:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdlZB-00017p-00 for ldapext@ietf.org; Fri, 25 Jun 2004 03:56:09 -0400 Received: from mail17.ca.com ([155.35.248.106] helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 1BdlYG-0000T1-00 for ldapext@ietf.org; Fri, 25 Jun 2004 03:55:12 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Jun 2004 17:54:39 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6547.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ldapext] Chained Operation (control, extended op, or op?) Date: Fri, 25 Jun 2004 17:54:39 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B638101825082@ausyms21.ca.com> Thread-Topic: [ldapext] Chained Operation (control, extended op, or op?) Thread-Index: AcRahRBdr/tp4zOlS+a4YU6aB3T+uQAA/ueQ From: "Ramsay, Ron" To: "Mark Ennis" , "Kurt D. Zeilenga" X-OriginalArrivalTime: 25 Jun 2004 07:54:39.0770 (UTC) FILETIME=[AAEA07A0:01C45A89] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ldapext@ietf.org, Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: quoted-printable It seems a funny model. The X.500 approach would be to bind to the other = DSA at the appropriate authentication level and pass the requester and = the auth level in the request. In fact, I don't even understand what is = meant by chaining SASL bind exchanges as some of these would be point to = point and no third party would/should be able to participate. -----Original Message----- From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On Behalf Of Mark Ennis Sent: Friday, 25 June 2004 16:47 To: Kurt D. Zeilenga Cc: ldapext@ietf.org; Jim Sermersheim Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) Kurt D. Zeilenga wrote: > BTW, I'd like to add support for chaining SASL bind exchanges. > This will require some fields beyond those offered by the > X.518 ChainingArguments/ChainingResults structures. I agree that a mechanism for chaining SASL bind exchanges would be=20 useful, however, current chaining mechanisms (e.g. X.518 or LDAP=20 referrals) depend on name resolution of a base object. The bind=20 operation, particularly when using a SASL mechanism, does not have a=20 base object for the name resolution process. This would mean special=20 procedures for "chaining" this operation. Does this also require formalising some type of trust model between DSAs = if we are going to delegate authentication operations to another server? Is it possible to translate this SASL bind exchange into a LDAP=20 operation the initiating DSA invokes, e.g. a search for the SASL=20 "username" with a control used to transmit the SASL credentials and=20 receive the SASL auth-response? Such an operation may then be chained by = the responding DSA(s) and authorization decisions will be done using the = initiating DSA as the authorization identity? - Mark. >=20 > Kurt=20 >=20 >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 04:31:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16768 for ; Fri, 25 Jun 2004 04:31:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdlsX-0003UO-Ql; Fri, 25 Jun 2004 04:16:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdlgp-0008BB-QW for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 04:04:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15490 for ; Fri, 25 Jun 2004 04:04:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdlgm-0003dc-Ox for ldapext@ietf.org; Fri, 25 Jun 2004 04:04:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdlfr-0003L9-00 for ldapext@ietf.org; Fri, 25 Jun 2004 04:03:04 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1Bdlf4-0002jn-00 for ldapext@ietf.org; Fri, 25 Jun 2004 04:02:14 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 25 Jun 2004 02:01:45 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 25 Jun 2004 02:00:49 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] Distributed Procedures Requirements X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit All, Mark Ennis suggested, and I agree, that more detailed instructions (than I provided in my rough draft of the chained operation) are needed for distributed LDAP operations Before diving too deeply into precisely defining the semantics of the chained operation, I need to get a sense for what are seen as the required attributes of the LDAP distributed procedures. So, I've summarized what I believe to be debatable requirements/goals. I haven't included obvious things like: loop detection, allowing all operations other than abandon/cancel to be chained, removing duplicate results, etc.. Following is the list, along with a brief description of what the concept means. If possible, can you provide feedback as to whether you think each should be included in the considerations or instructions for chaining operations? 1) PartialOutcomeQualifier (X.511). LDAP has not yet defined this as a control. If LDAP were to support it, then there are four cases when chaining that will cause it to be returned: 1.a) When a DSA encounters an unsupported critical control while progressing a subrequest. (X.518 : 15.5.2) 1.b) When a time limit was exceeded while outstanding subrequests were in progress. (X.518 : 16.1.4.1) 1.c) When a size limit was exceeded while outstanding subrequests were in progress. (X.518 : 16.1.4.4) 1.d) When an association between another DSA progressing a subrequest was lost. (16.1.4.2.3) As far as I can tell, the use of the PartialOutcomeQualifier has no bearing on other aspects of the chained operation (no other phases of the progression of a chained operation rely on its values). Therefore, I believe considerations and instructions for PartialOutcomeQualifier can be omitted and left for a future specification. 2 Time and size limit enforcement. Currently, LDAP only allows for these limit specifications on the search operation. It's reasonable to assume a future control will be defined which allows a time limit to be specified for any operation. Regardless of that, I believe the chained operation specification must include considerations and instructions where needed to properly handle these limits while chaining. 3) Priority. X.518 basically says all DSAs need to handle this if present. I don't think considerations need to be made for it. 4) preferChaining, chainingProhibited, localScope. These seem to obviously need consideration and instructions. BTW, I plan to resubmit draft-sermersheim-ldap-chaining-xx which introduces these concepts to LDAP. 5) partialNameResolution. I vote to not make considerations for this, but I could easily be swayed. 6) nameResolveOnMaster, copyShallDo, dontUseCopy, dontDereferenceAliases, etc. I think (at least hope) these types of policies can be noted in a general way rather than cluttering up the spec with detailed instructions regarding them. 7) scopeOfReferrral (if a referral is returned, it must be within the specified scope). I vote to ignore this for now. Similarly, some have asked for a scopeOfChaining (don't chain outside the specified scope). I think this could be addressed later. 8) Loop Avoidance. While loop detection is obviously required, should we give instructions for loop avoidance? 9) Emulated Chained Operation. When a remote DSA does not support the chained operation, the chaining DSA could emulate (to a degree) the chaining of the operation by sending the original (or a modification of the original) operation to the remote DSA. Instructions for modifying the incoming operation would likely be very similar to what a DUA must do to follow a referral. 10) Mechanisms for better performance. As was recently brought up, The X.518 chained operation passes a targetObject of the parent of the next naming context when chaining a search subrequest. A benefit of this is that in certain circumstances, a single DSA (holding a number of naming contexts, all below the same parent) can be contacted once rather than once for each naming context. I believe this is a marginal reason to follow the X.518 procedures in this regard. 11) Mechanisms for consistency checks. Another reason pointed at for passing a targetObject of the parent of the next naming context when chaining a search subrequest (and also passing operationProgress) is so that the receiving DSA can perform consistency checks on the distributed data model. If this is a requirement, there are different ways to achieve it. 12) Failover and use less likely candidates when chaining. The X.518 procedures keep a list of candidate references while resolving the name. One benefit of this is that when a DSA is unavailable to progress an operation, a less likely candidate can be tried. Allowing this behavior brings also with it the need to pass operationProgress in order to properly perform loop detection. I don't see the benefit outweighing the overhead of the added processes. 13) Loss of association between DSAs. I believe direction must be provided for handling the case where the connection between DSAs is lost while chaining. 14) Administrative limits. I think this is basically the same as #6 except the policies are set on the server rather than passed with the operation. So I vote to follow #6 on this. 15) DSABind. I was planning to allow for two things: A) a chained simple bind (the DN is found to be on a remote DSA, so the bind is chained). B) other. A DSA may simply bind to another DSA using whatever method it can/wants, and use whatever proxy auth it wants while chaining. Meaning, I was planning on punting and allowing a future, more robust spec talk about this as it has uses outside chaining (such as DISP, DOP, etc). I can't think of any other requirements/goals right now. If there are others, let me know. If you think it would be better for me to place these requirements/goals into an I-D, let me know that too. Whatever ends up being left out, I hope can be specified later. Meaning, I hope to write the spec in a way that future considerations don't require the chained operation spec to be updated. Thanks for helping, Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 10:10:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02165 for ; Fri, 25 Jun 2004 10:10:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdrMx-0005Gf-00; Fri, 25 Jun 2004 10:07:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdr6o-0007Fp-JF for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 09:51:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00484 for ; Fri, 25 Jun 2004 09:51:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdr6m-0007TE-Gx for ldapext@ietf.org; Fri, 25 Jun 2004 09:51:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdr5n-00079p-00 for ldapext@ietf.org; Fri, 25 Jun 2004 09:50:12 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Bdr4o-0006n1-00 for ldapext@ietf.org; Fri, 25 Jun 2004 09:49:10 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PDn4MC021643; Fri, 25 Jun 2004 13:49:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625063852.04aa38b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 06:49:08 -0700 To: Mark Ennis From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) In-Reply-To: <40DBCA6C.2010703@adacel.com> References: <6.0.1.1.0.20040621154840.02c97a48@127.0.0.1> <40DBCA6C.2010703@adacel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org, Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 11:47 PM 6/24/2004, Mark Ennis wrote: >Kurt D. Zeilenga wrote: >>BTW, I'd like to add support for chaining SASL bind exchanges. >>This will require some fields beyond those offered by the >>X.518 ChainingArguments/ChainingResults structures. > >I agree that a mechanism for chaining SASL bind exchanges would be useful, however, current chaining mechanisms (e.g. X.518 or LDAP referrals) depend on name resolution of a base object. The bind operation, particularly when using a SASL mechanism, does not have a base object for the name resolution process. This would mean special procedures for "chaining" this operation. > >Does this also require formalising some type of trust model between DSAs if we are going to delegate authentication operations to another server? Yes. >Is it possible to translate this SASL bind exchange into a LDAP operation the initiating DSA invokes, e.g. a search for the SASL "username" with a control used to transmit the SASL credentials and receive the SASL auth-response? Depending on mechanism, depending on assumptions, yes. >Such an operation may then be chained by the responding DSA(s) and authorization decisions will be done using the initiating DSA as the authorization identity? Possibly. I, however, was considering an approach where the initiating server would pass through the original request with some additional information so that the chained server can form the proper response, and return that response with some additional information needed by the chaining server to make use of the response. This may be an area better left to a separate document (and separate extended operation). If I have time in the next few weeks, I'll try to outline a proposal here in an I-D. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 11:30:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10642 for ; Fri, 25 Jun 2004 11:30:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdsIR-0007GH-2b; Fri, 25 Jun 2004 11:07:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdrPG-0006Xr-Nm for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 10:10:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02088 for ; Fri, 25 Jun 2004 10:10:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdrPF-0004hG-A1 for ldapext@ietf.org; Fri, 25 Jun 2004 10:10:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdrOG-0004Ny-00 for ldapext@ietf.org; Fri, 25 Jun 2004 10:09:17 -0400 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1BdrNG-0003og-00 for ldapext@ietf.org; Fri, 25 Jun 2004 10:08:14 -0400 Received: from [127.0.0.1] (pcp04150285pcs.sanarb01.mi.comcast.net[68.41.55.52]) by comcast.net (sccrmhc12) with ESMTP id <20040625140743012008aitbe> (Authid: mcs); Fri, 25 Jun 2004 14:07:43 +0000 Message-ID: <40DC31A9.3050409@pearlcrescent.com> Date: Fri, 25 Jun 2004 10:07:37 -0400 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim Subject: Re: [ldapext] searchable archive? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: >I should have mentioned that the one >https://www1.ietf.org/mailman/private/ldapext/ is empty. > > For some reason archiving was disabled. I just enabled it and made the archive public. It is here now: http://www1.ietf.org/pipermail/ldapext/ There are some older messages there, although it is incomplete (for example, the recent chaining discussion is not in the archive). -Mark _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 11:36:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11666 for ; Fri, 25 Jun 2004 11:36:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdsb1-0005Oh-OU; Fri, 25 Jun 2004 11:26:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdrvb-0004fm-Vj for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 10:43:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05599 for ; Fri, 25 Jun 2004 10:43:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdrvb-0000Xg-7w for ldapext@ietf.org; Fri, 25 Jun 2004 10:43:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdruM-000032-00 for ldapext@ietf.org; Fri, 25 Jun 2004 10:42:27 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Bdrsw-0007EY-00 for ldapext@ietf.org; Fri, 25 Jun 2004 10:40:59 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PEewMC022290; Fri, 25 Jun 2004 14:40:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625073930.04bb0978@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 07:41:02 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] searchable archive? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 10:45 AM 6/24/2004, Jim Sermersheim wrote: >The archive at http://www.openldap.org/lists/ietf-ldapext/ I've repaired this archive, backfilling posts from the IETF archives as needed. Enjoy! Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 11:36:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11826 for ; Fri, 25 Jun 2004 11:36:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdsc5-0006bn-8n; Fri, 25 Jun 2004 11:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bds3S-0008Rh-I2 for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 10:51:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06183 for ; Fri, 25 Jun 2004 10:51:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bds3R-0002ht-P0 for ldapext@ietf.org; Fri, 25 Jun 2004 10:51:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdryU-0001P4-00 for ldapext@ietf.org; Fri, 25 Jun 2004 10:46:43 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdrvS-0000Sv-01 for ldapext@ietf.org; Fri, 25 Jun 2004 10:43:34 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bdrnu-0003Wv-M4 for ldapext@ietf.org; Fri, 25 Jun 2004 10:35:46 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PEZDMC022115; Fri, 25 Jun 2004 14:35:14 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625065723.04ab8d08@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 07:35:17 -0700 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: chaining SASL binds (Was: [ldapext] Chained Operation (control, extended op, or op?)) In-Reply-To: <1395B4B334FCC143B36AF788E68B638101825082@ausyms21.ca.com> References: <1395B4B334FCC143B36AF788E68B638101825082@ausyms21.ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org, Mark Ennis , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I changed the subject as it likely best to separate this discussion from the more general chained operation discussion. At 12:54 AM 6/25/2004, Ramsay, Ron wrote: >It seems a funny model. The X.500 approach would be to bind to the other DSA at the appropriate authentication level and pass the requester and the auth level in the request. In fact, I don't even understand what is meant by chaining SASL bind exchanges as some of these would be point to point and no third party would/should be able to participate. s/no third party/no untrusted third party (e.g., an attacker)/ Mechanisms are often designed to offer protection from MITM attack. While these mechanisms can make it hard for trusted 3rd parties to participate in the exchange, they don't generally preclude such participation. It is often possible for trusted 3rd parties to participate without losing the MITM protective services. The reason why I want to formalize a mechanism for trusted 3rd party participation is to ensure the MITM protective services are preserved. Kurt >-----Original Message----- >From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On >Behalf Of Mark Ennis >Sent: Friday, 25 June 2004 16:47 >To: Kurt D. Zeilenga >Cc: ldapext@ietf.org; Jim Sermersheim >Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) > > >Kurt D. Zeilenga wrote: >> BTW, I'd like to add support for chaining SASL bind exchanges. >> This will require some fields beyond those offered by the >> X.518 ChainingArguments/ChainingResults structures. > >I agree that a mechanism for chaining SASL bind exchanges would be >useful, however, current chaining mechanisms (e.g. X.518 or LDAP >referrals) depend on name resolution of a base object. The bind >operation, particularly when using a SASL mechanism, does not have a >base object for the name resolution process. This would mean special >procedures for "chaining" this operation. > >Does this also require formalising some type of trust model between DSAs >if we are going to delegate authentication operations to another server? > >Is it possible to translate this SASL bind exchange into a LDAP >operation the initiating DSA invokes, e.g. a search for the SASL >"username" with a control used to transmit the SASL credentials and >receive the SASL auth-response? Such an operation may then be chained by >the responding DSA(s) and authorization decisions will be done using the >initiating DSA as the authorization identity? > >- Mark. > >> >> Kurt >> >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www1.ietf.org/mailman/listinfo/ldapext > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 11:44:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13031 for ; Fri, 25 Jun 2004 11:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdseG-00087B-Eh; Fri, 25 Jun 2004 11:29:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdsG6-00068L-MS for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 11:04:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07940 for ; Fri, 25 Jun 2004 11:04:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdsG5-0005nq-PQ for ldapext@ietf.org; Fri, 25 Jun 2004 11:04:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdsBF-0004U0-00 for ldapext@ietf.org; Fri, 25 Jun 2004 10:59:54 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Bds6X-0003E4-00 for ldapext@ietf.org; Fri, 25 Jun 2004 10:55:01 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PEsxMC022629; Fri, 25 Jun 2004 14:54:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625075104.04bb2980@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 07:55:02 -0700 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: chaining binds (Was: [ldapext] Chained Operation (control, extended op, or op?)) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: Jim Sermersheim , ldapext@ietf.org, mark.ennis@adacel.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 07:37 AM 6/25/2004, Ed Reed wrote: >Or am I off in la-la-land, again? I think you're on target. I'm going to pursue 2) separately for now. That will allow Jim and others to move forward on 1) without having to worry about 2). Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 12:55:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22401 for ; Fri, 25 Jun 2004 12:55:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdtKS-0007nb-DB; Fri, 25 Jun 2004 12:13:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdt5E-0003KL-VB for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 11:57:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15514 for ; Fri, 25 Jun 2004 11:57:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdt5E-0000zJ-6G for ldapext@ietf.org; Fri, 25 Jun 2004 11:57:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdt0Z-0007TS-00 for ldapext@ietf.org; Fri, 25 Jun 2004 11:52:56 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BdstV-0005iL-00 for ldapext@ietf.org; Fri, 25 Jun 2004 11:45:37 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 25 Jun 2004 09:45:07 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 25 Jun 2004 09:42:34 -0600 From: "Jim Sermersheim" To: , "Ed Reed" , Subject: Proxied AuthZ (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit One (albeit simple) mechanism for this has been around for a while (http://www.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-12.txt). This seems to meet a few of the criteria that people want. It allows the sender to pass a control which says "use this identity for this operation". Though it doesn't say so, it seems able to be used between DSAs (it uses client and server terms). When used between DSAs, one would sasume the sending DSA has ensured that the sent identity has already authenticated somehow. Maybe this only meets some minimal requirements. I think the chained bind that Kurt is talking about is a little different. It allows the one DSA to forward some forms of a bind operation to a second DSA. Jim >>> Ed Reed 6/25/04 8:37:08 AM >>> I'd really love to see an extended, chained operation that: 1) relies on the chaining DSA to authenticate, using it's own identity and crendentials, to establish a secure connection (probably over SSL) over which the chaining DSA and the target DSA (the one who will receive the chained request) will communicate; 2) a chained, or perhaps alltogether new, operation that authenticates a user and their bind credentials, but doens't result in a separate authentication connection on the target DSA, but rather results in a "yeah, I'd accept that, perhaps with these limitations" result on which the chaining DSA (or other intermediary service speaking as though it were a trusted chaining DSA) could rely. This would allow a proxy, whether a web service, a firewall, or another directory, to open a single connection to each target DSA, and then utter "is this guy okay" requests, perhaps with multiple round trips so any challenge-response transactions used in the authentication mechanism used by the end users could be satisfied. Such a multiplexing of the single trusted connection would reduce resource consumption by the intermediary as well as the target DSAs. Doing this for SASL, generally, would seem like a good idea. Target DSAs could then be configured to allow or not allow such intermediary multiplexing connections, and if allow them rely on the strength and confidence in the authentication of the chaining server to guide its responses. In the most simple sense, if a simple compare of a presented password to a user's password attribute would satisfy the chaining DSA of the authentication of the user, there would be no need to lash up a whole connection with bind and SSL handshakes for the relying system to know the user is authenticated. SASL presents a more challenging design, but this notion of chaining, if done correctly, would seem to fit the bill. Or am I off in la-la-land, again? Ed >>>"Kurt D. Zeilenga" 06/25 9:49 am >>> At 11:47 PM 6/24/2004, Mark Ennis wrote: >Kurt D. Zeilenga wrote: >>BTW, I'd like to add support for chaining SASL bind exchanges. >>This will require some fields beyond those offered by the >>X.518 ChainingArguments/ChainingResults structures. > >I agree that a mechanism for chaining SASL bind exchanges would be useful, however, current chaining mechanisms (e.g. X.518 or LDAP referrals) depend on name resolution of a base object. The bind operation, particularly when using a SASL mechanism, does not have a base object for the name resolution process. This would mean special procedures for "chaining" this operation. > >Does this also require formalising some type of trust model between DSAs if we are going to delegate authentication operations to another server? Yes. >Is it possible to translate this SASL bind exchange into a LDAP operation the initiating DSA invokes, e.g. a search for the SASL "username" with a control used to transmit the SASL credentials and receive the SASL auth-response? Depending on mechanism, depending on assumptions, yes. >Such an operation may then be chained by the responding DSA(s) and authorization decisions will be done using the initiating DSA as the authorization identity? Possibly. I, however, was considering an approach where the initiating server would pass through the original request with some additional information so that the chained server can form the proper response, and return that response with some additional information needed by the chaining server to make use of the response. This may be an area better left to a separate document (and separate extended operation). If I have time in the next few weeks, I'll try to outline a proposal here in an I-D. Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 12:55:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22418 for ; Fri, 25 Jun 2004 12:55:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdtKz-00089X-UV; Fri, 25 Jun 2004 12:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdt6Z-0003Wr-92 for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 11:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15632 for ; Fri, 25 Jun 2004 11:59:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdt6Y-0001Qt-El for ldapext@ietf.org; Fri, 25 Jun 2004 11:59:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdt2S-0000Ev-00 for ldapext@ietf.org; Fri, 25 Jun 2004 11:54:53 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1Bdswy-0006bf-00 for ldapext@ietf.org; Fri, 25 Jun 2004 11:49:13 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 25 Jun 2004 09:48:42 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 25 Jun 2004 09:48:22 -0600 From: "Jim Sermersheim" To: , Subject: Re: chaining SASL binds (Was: [ldapext] Chained Operation (control, extended op, or op?)) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, Hal Henderson , mark.ennis@adacel.com, Tammy Green X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit When I've talked about this with people in the past, I was told that some SASL mechanisms will work with a man in the middle, but others won't. Of course, I don't remember the details. Is there such a thing as a recognized trusted MITM? Does the concept exist in the SASL framework? It would be great if this research could happen in parallel, but somewhat separately, from the chained operation (just one less set of problems for me to focus on). Jim >>> "Kurt D. Zeilenga" 6/25/04 8:35:17 AM >>> I changed the subject as it likely best to separate this discussion from the more general chained operation discussion. At 12:54 AM 6/25/2004, Ramsay, Ron wrote: >It seems a funny model. The X.500 approach would be to bind to the other DSA at the appropriate authentication level and pass the requester and the auth level in the request. In fact, I don't even understand what is meant by chaining SASL bind exchanges as some of these would be point to point and no third party would/should be able to participate. s/no third party/no untrusted third party (e.g., an attacker)/ Mechanisms are often designed to offer protection from MITM attack. While these mechanisms can make it hard for trusted 3rd parties to participate in the exchange, they don't generally preclude such participation. It is often possible for trusted 3rd parties to participate without losing the MITM protective services. The reason why I want to formalize a mechanism for trusted 3rd party participation is to ensure the MITM protective services are preserved. Kurt >-----Original Message----- >From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On >Behalf Of Mark Ennis >Sent: Friday, 25 June 2004 16:47 >To: Kurt D. Zeilenga >Cc: ldapext@ietf.org; Jim Sermersheim >Subject: Re: [ldapext] Chained Operation (control, extended op, or op?) > > >Kurt D. Zeilenga wrote: >> BTW, I'd like to add support for chaining SASL bind exchanges. >> This will require some fields beyond those offered by the >> X.518 ChainingArguments/ChainingResults structures. > >I agree that a mechanism for chaining SASL bind exchanges would be >useful, however, current chaining mechanisms (e.g. X.518 or LDAP >referrals) depend on name resolution of a base object. The bind >operation, particularly when using a SASL mechanism, does not have a >base object for the name resolution process. This would mean special >procedures for "chaining" this operation. > >Does this also require formalising some type of trust model between DSAs >if we are going to delegate authentication operations to another server? > >Is it possible to translate this SASL bind exchange into a LDAP >operation the initiating DSA invokes, e.g. a search for the SASL >"username" with a control used to transmit the SASL credentials and >receive the SASL auth-response? Such an operation may then be chained by >the responding DSA(s) and authorization decisions will be done using the >initiating DSA as the authorization identity? > >- Mark. > >> >> Kurt >> >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www1.ietf.org/mailman/listinfo/ldapext > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 13:07:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23748 for ; Fri, 25 Jun 2004 13:07:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdtvc-0005pc-Eg; Fri, 25 Jun 2004 12:51:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdtGi-00067c-R9 for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 12:09:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19198 for ; Fri, 25 Jun 2004 12:09:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdtGh-0004ng-Lr for ldapext@ietf.org; Fri, 25 Jun 2004 12:09:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdtG1-0004T3-00 for ldapext@ietf.org; Fri, 25 Jun 2004 12:08:54 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BdtEs-00048G-00 for ldapext@ietf.org; Fri, 25 Jun 2004 12:07:42 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PG7ZMC023723; Fri, 25 Jun 2004 16:07:35 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625085555.04a85638@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 09:07:39 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: Proxied AuthZ (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: Ed Reed , mark.ennis@adacel.com, ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 08:42 AM 6/25/2004, Jim Sermersheim wrote: >One (albeit simple) mechanism for this has been around for a while >(http://www.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-12.txt). >This seems to meet a few of the criteria that people want. It allows the >sender to pass a control which says "use this identity for this >operation". But who's asking to use this identity? The originating client or the chaining server? >Though it doesn't say so, it seems able to be used between >DSAs (it uses client and server terms). When used between DSAs, one >would sasume the sending DSA has ensured that the sent identity has >already authenticated somehow. > >Maybe this only meets some minimal requirements. I think, in order to make it clear that as who is asking what, there needs to be good separation between what belongs to original request and the chaining request. The chained operation exop provides that. >I think the chained bind that Kurt is talking about is a little >different. It allows the one DSA to forward some forms of a bind >operation to a second DSA. Yes. I'm looking at mechanisms for distributed authentication operations in addition to mechanisms for distributed (non-authentication) operations. Kurt >Jim > >>>> Ed Reed 6/25/04 8:37:08 AM >>> >I'd really love to see an extended, chained operation that: > >1) relies on the chaining DSA to authenticate, using it's own identity >and crendentials, to establish a secure connection (probably over SSL) >over which the chaining DSA and the target DSA (the one who will receive >the chained request) will communicate; >2) a chained, or perhaps alltogether new, operation that authenticates >a user and their bind credentials, but doens't result in a separate >authentication connection on the target DSA, but rather results in a >"yeah, I'd accept that, perhaps with these limitations" result on which >the chaining DSA (or other intermediary service speaking as though it >were a trusted chaining DSA) could rely. > >This would allow a proxy, whether a web service, a firewall, or another >directory, to open a single connection to each target DSA, and then >utter "is this guy okay" requests, perhaps with multiple round trips so >any challenge-response transactions used in the authentication mechanism >used by the end users could be satisfied. > >Such a multiplexing of the single trusted connection would reduce >resource consumption by the intermediary as well as the target DSAs. >Doing this for SASL, generally, would seem like a good idea. Target DSAs >could then be configured to allow or not allow such intermediary >multiplexing connections, and if allow them rely on the strength and >confidence in the authentication of the chaining server to guide its >responses. > >In the most simple sense, if a simple compare of a presented password >to a user's password attribute would satisfy the chaining DSA of the >authentication of the user, there would be no need to lash up a whole >connection with bind and SSL handshakes for the relying system to know >the user is authenticated. > >SASL presents a more challenging design, but this notion of chaining, >if done correctly, would seem to fit the bill. > >Or am I off in la-la-land, again? > >Ed > > >>>>"Kurt D. Zeilenga" 06/25 9:49 am >>> >At 11:47 PM 6/24/2004, Mark Ennis wrote: >>Kurt D. Zeilenga wrote: >>>BTW, I'd like to add support for chaining SASL bind exchanges. >>>This will require some fields beyond those offered by the >>>X.518 ChainingArguments/ChainingResults structures. >> >>I agree that a mechanism for chaining SASL bind exchanges would be >useful, however, current chaining mechanisms (e.g. X.518 or LDAP >referrals) depend on name resolution of a base object. The bind >operation, particularly when using a SASL mechanism, does not have a >base object for the name resolution process. This would mean special >procedures for "chaining" this operation. >> >>Does this also require formalising some type of trust model between >DSAs if we are going to delegate authentication operations to another >server? > >Yes. > >>Is it possible to translate this SASL bind exchange into a LDAP >operation the initiating DSA invokes, e.g. a search for the SASL >"username" with a control used to transmit the SASL credentials and >receive the SASL auth-response? > >Depending on mechanism, depending on assumptions, yes. > >>Such an operation may then be chained by the responding DSA(s) and >authorization decisions will be done using the initiating DSA as the >authorization identity? > >Possibly. > >I, however, was considering an approach where the initiating server >would pass through the original request with some additional >information >so that the chained server can form the proper response, and return >that response with some additional information needed by the chaining >server to make use of the response. > >This may be an area better left to a separate document (and >separate extended operation). If I have time in the next few >weeks, I'll try to outline a proposal here in an I-D. > > > >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 13:17:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25187 for ; Fri, 25 Jun 2004 13:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdu1v-0000Pp-Oh; Fri, 25 Jun 2004 12:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdtWx-0003j9-Nk for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 12:26:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20092 for ; Fri, 25 Jun 2004 12:26:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdtWw-00027j-Qc for ldapext@ietf.org; Fri, 25 Jun 2004 12:26:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdtVv-0001p5-00 for ldapext@ietf.org; Fri, 25 Jun 2004 12:25:20 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BdtUw-0001GI-00 for ldapext@ietf.org; Fri, 25 Jun 2004 12:24:18 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 25 Jun 2004 10:23:47 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 25 Jun 2004 10:23:10 -0600 From: "Jim Sermersheim" To: Subject: Re: Proxied AuthZ (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, mark.ennis@adacel.com, Ed Reed X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit The proxied authN control would be used in the case where the chaining server has at some point established a single connection and authenticated as a trusted identity to a remote DSA (this identity would be trusted to chain operations). As the first DSA needs to chain to the second, it will re-use the same outbound connection for any number of different inbound connections. This is only one mode of operation, some other modes would require a 1:1 relationship between in and out connections. Jim >>> "Kurt D. Zeilenga" 6/25/04 10:07:39 AM >>> At 08:42 AM 6/25/2004, Jim Sermersheim wrote: >One (albeit simple) mechanism for this has been around for a while >(http://www.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-12.txt). >This seems to meet a few of the criteria that people want. It allows the >sender to pass a control which says "use this identity for this >operation". But who's asking to use this identity? The originating client or the chaining server? >Though it doesn't say so, it seems able to be used between >DSAs (it uses client and server terms). When used between DSAs, one >would sasume the sending DSA has ensured that the sent identity has >already authenticated somehow. > >Maybe this only meets some minimal requirements. I think, in order to make it clear that as who is asking what, there needs to be good separation between what belongs to original request and the chaining request. The chained operation exop provides that. >I think the chained bind that Kurt is talking about is a little >different. It allows the one DSA to forward some forms of a bind >operation to a second DSA. Yes. I'm looking at mechanisms for distributed authentication operations in addition to mechanisms for distributed (non-authentication) operations. Kurt >Jim > >>>> Ed Reed 6/25/04 8:37:08 AM >>> >I'd really love to see an extended, chained operation that: > >1) relies on the chaining DSA to authenticate, using it's own identity >and crendentials, to establish a secure connection (probably over SSL) >over which the chaining DSA and the target DSA (the one who will receive >the chained request) will communicate; >2) a chained, or perhaps alltogether new, operation that authenticates >a user and their bind credentials, but doens't result in a separate >authentication connection on the target DSA, but rather results in a >"yeah, I'd accept that, perhaps with these limitations" result on which >the chaining DSA (or other intermediary service speaking as though it >were a trusted chaining DSA) could rely. > >This would allow a proxy, whether a web service, a firewall, or another >directory, to open a single connection to each target DSA, and then >utter "is this guy okay" requests, perhaps with multiple round trips so >any challenge-response transactions used in the authentication mechanism >used by the end users could be satisfied. > >Such a multiplexing of the single trusted connection would reduce >resource consumption by the intermediary as well as the target DSAs. >Doing this for SASL, generally, would seem like a good idea. Target DSAs >could then be configured to allow or not allow such intermediary >multiplexing connections, and if allow them rely on the strength and >confidence in the authentication of the chaining server to guide its >responses. > >In the most simple sense, if a simple compare of a presented password >to a user's password attribute would satisfy the chaining DSA of the >authentication of the user, there would be no need to lash up a whole >connection with bind and SSL handshakes for the relying system to know >the user is authenticated. > >SASL presents a more challenging design, but this notion of chaining, >if done correctly, would seem to fit the bill. > >Or am I off in la-la-land, again? > >Ed > > >>>>"Kurt D. Zeilenga" 06/25 9:49 am >>> >At 11:47 PM 6/24/2004, Mark Ennis wrote: >>Kurt D. Zeilenga wrote: >>>BTW, I'd like to add support for chaining SASL bind exchanges. >>>This will require some fields beyond those offered by the >>>X.518 ChainingArguments/ChainingResults structures. >> >>I agree that a mechanism for chaining SASL bind exchanges would be >useful, however, current chaining mechanisms (e.g. X.518 or LDAP >referrals) depend on name resolution of a base object. The bind >operation, particularly when using a SASL mechanism, does not have a >base object for the name resolution process. This would mean special >procedures for "chaining" this operation. >> >>Does this also require formalising some type of trust model between >DSAs if we are going to delegate authentication operations to another >server? > >Yes. > >>Is it possible to translate this SASL bind exchange into a LDAP >operation the initiating DSA invokes, e.g. a search for the SASL >"username" with a control used to transmit the SASL credentials and >receive the SASL auth-response? > >Depending on mechanism, depending on assumptions, yes. > >>Such an operation may then be chained by the responding DSA(s) and >authorization decisions will be done using the initiating DSA as the >authorization identity? > >Possibly. > >I, however, was considering an approach where the initiating server >would pass through the original request with some additional >information >so that the chained server can form the proper response, and return >that response with some additional information needed by the chaining >server to make use of the response. > >This may be an area better left to a separate document (and >separate extended operation). If I have time in the next few >weeks, I'll try to outline a proposal here in an I-D. > > > >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 13:21:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25697 for ; Fri, 25 Jun 2004 13:21:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdu9I-0004AN-JV; Fri, 25 Jun 2004 13:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdtn9-0001Gy-R1 for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 12:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21073 for ; Fri, 25 Jun 2004 12:43:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdtn8-0007Na-Pm for ldapext@ietf.org; Fri, 25 Jun 2004 12:43:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdtl4-0006a7-00 for ldapext@ietf.org; Fri, 25 Jun 2004 12:40:59 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BdtjI-0005uE-00 for ldapext@ietf.org; Fri, 25 Jun 2004 12:39:08 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5PGd2MC023917; Fri, 25 Jun 2004 16:39:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040625091259.04be09f8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 25 Jun 2004 09:39:06 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: chaining SASL binds (Was: [ldapext] Chained Operation (control, extended op, or op?)) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: mark.ennis@adacel.com, Hal Henderson , Ron.Ramsay@ca.com, Tammy Green , ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 08:48 AM 6/25/2004, Jim Sermersheim wrote: >When I've talked about this with people in the past, I was told that >some SASL mechanisms will work with a man in the middle, but others >won't. Of course, I don't remember the details. Some mechanisms (DIGEST-MD5's digest-uri, integrity layers) have protections to hinder MITM attacks, but can made to work through trusted active intermediate systems. >Is there such a thing as a recognized trusted MITM? Does the concept >exist in the SASL framework? The SASL framework is client/server authentication. But it doesn't preclude either the client or the server implementations from being distributed, but if they are, then they have to take appropriate steps to ensure interoperability. To effectively chain a DIGEST-MD5, the intermediate box (which the client has connected to) needs to advise the remote box (fulfilling the authentication) what digest-uri to use in its responses to the client (passed back through the intermediate). Another feature would be pass enough information back to the intermediate to allow it to establish security layers between it and the client, preferably without exposing the shared secret (the A1 hash) to the intermediate. Whether or not this is possible depends on the layer particulars. I note that this kind of "distributed authentication" can be applied where the communication between the client and intermediate is not over LDAP, but over some other SASL-supporting protocol. For instance, it could be used in implementation of SOAP/BEEP -> LDAP application level gateway. >It would be great if this research could happen in parallel, It does seems a bit "experimental". Another good reason to keep it separate from the "distributed operation" work. Another reason to keep this "distributed authentication" stuff separate is ease security considerations discussions. >but >somewhat separately, from the chained operation (just one less set of >problems for me to focus on). > >Jim > >>>> "Kurt D. Zeilenga" 6/25/04 8:35:17 AM >>> >I changed the subject as it likely best to separate this >discussion from the more general chained operation discussion. > >At 12:54 AM 6/25/2004, Ramsay, Ron wrote: >>It seems a funny model. The X.500 approach would be to bind to the >other DSA at the appropriate authentication level and pass the requester >and the auth level in the request. In fact, I don't even understand what >is meant by chaining SASL bind exchanges as some of these would be point >to point and no third party would/should be able to participate. > >s/no third party/no untrusted third party (e.g., an attacker)/ > >Mechanisms are often designed to offer protection from MITM attack. >While these mechanisms can make it hard for trusted 3rd parties >to participate in the exchange, they don't generally preclude >such participation. It is often possible for trusted 3rd >parties to participate without losing the MITM protective >services. > >The reason why I want to formalize a mechanism for trusted 3rd >party participation is to ensure the MITM protective services >are preserved. > >Kurt > >>-----Original Message----- >>From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On >>Behalf Of Mark Ennis >>Sent: Friday, 25 June 2004 16:47 >>To: Kurt D. Zeilenga >>Cc: ldapext@ietf.org; Jim Sermersheim >>Subject: Re: [ldapext] Chained Operation (control, extended op, or >op?) >> >> >>Kurt D. Zeilenga wrote: >>> BTW, I'd like to add support for chaining SASL bind exchanges. >>> This will require some fields beyond those offered by the >>> X.518 ChainingArguments/ChainingResults structures. >> >>I agree that a mechanism for chaining SASL bind exchanges would be >>useful, however, current chaining mechanisms (e.g. X.518 or LDAP >>referrals) depend on name resolution of a base object. The bind >>operation, particularly when using a SASL mechanism, does not have a >>base object for the name resolution process. This would mean special >>procedures for "chaining" this operation. >> >>Does this also require formalising some type of trust model between >DSAs >>if we are going to delegate authentication operations to another >server? >> >>Is it possible to translate this SASL bind exchange into a LDAP >>operation the initiating DSA invokes, e.g. a search for the SASL >>"username" with a control used to transmit the SASL credentials and >>receive the SASL auth-response? Such an operation may then be chained >by >>the responding DSA(s) and authorization decisions will be done using >the >>initiating DSA as the authorization identity? >> >>- Mark. >> >>> >>> Kurt >>> >>> >>> _______________________________________________ >>> Ldapext mailing list >>> Ldapext@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ldapext >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext >> >> >>_______________________________________________ >>Ldapext mailing list >>Ldapext@ietf.org >>https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jun 25 14:03:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28900 for ; Fri, 25 Jun 2004 14:03:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdurl-0005EW-R6; Fri, 25 Jun 2004 13:51:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdunT-0003BB-Ru for ldapext@megatron.ietf.org; Fri, 25 Jun 2004 13:47:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27546 for ; Fri, 25 Jun 2004 13:47:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdunS-0002sx-N7 for ldapext@ietf.org; Fri, 25 Jun 2004 13:47:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdumS-0002by-00 for ldapext@ietf.org; Fri, 25 Jun 2004 13:46:29 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 1Bdum1-0002Ky-00 for ldapext@ietf.org; Fri, 25 Jun 2004 13:46:01 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5PHjVDk757196; Fri, 25 Jun 2004 13:45:31 -0400 Received: from d27ml001.rchland.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5PHkEEN108962; Fri, 25 Jun 2004 13:46:15 -0400 In-Reply-To: Subject: Re: Proxied AuthZ (was: Re: [ldapext] Chained Operation (control, extended op, or op?)) To: "Jim Sermersheim" X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: John McMeeking Date: Fri, 25 Jun 2004 12:45:22 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.5.2|June 01, 2004) at 06/25/2004 12:45:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Jim, Potentially, the proxied authN control can be used at two points in the scenario. 1) the chaining DSA uses it to pass along the client's identity. 2) the end application can be use it on behalf of a client it has authenticated For example, assume the chaining DSA authenticates as cn=chainingDsa, an application authenticates as cn=application, and some user has authenticated to the application as some identity associated with the LDAP id cn=user. The application uses the proxy control to perform some request under the authority of the user - but it sends this request to the proxy server. The chaining DSA needs to pass along two identities to the remote server so it can determine if cn=application is authorized to request authzid cn=user -- maybe use it for other purposes. Keep the stuff you need for chaining where it is clearly part of the chaining mechanism. This may apply to other controls you had mentioned as being related to chaining but possibly being useful elsewhere. It can get messy really fast when a DSA uses a control for chaining and a client can also attach the control to requests sent to the chaining DSA. John McMeeking ldapext-bounces@ietf.org wrote on 06/25/2004 11:23:10 AM: > The proxied authN control would be used in the case where the chaining > server has at some point established a single connection and > authenticated as a trusted identity to a remote DSA (this identity would > be trusted to chain operations). As the first DSA needs to chain to the > second, it will re-use the same outbound connection for any number of > different inbound connections. > > This is only one mode of operation, some other modes would require a > 1:1 relationship between in and out connections. > > Jim > > >>> "Kurt D. Zeilenga" 6/25/04 10:07:39 AM >>> > At 08:42 AM 6/25/2004, Jim Sermersheim wrote: > >One (albeit simple) mechanism for this has been around for a while > >(http://www.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-12.txt). > >This seems to meet a few of the criteria that people want. It allows > the > >sender to pass a control which says "use this identity for this > >operation". > > But who's asking to use this identity? The originating client > or the chaining server? > > >Though it doesn't say so, it seems able to be used between > >DSAs (it uses client and server terms). When used between DSAs, one > >would sasume the sending DSA has ensured that the sent identity has > >already authenticated somehow. > > > >Maybe this only meets some minimal requirements. > > I think, in order to make it clear that as who is asking what, > there needs to be good separation between what belongs to > original request and the chaining request. The chained > operation exop provides that. > > >I think the chained bind that Kurt is talking about is a little > >different. It allows the one DSA to forward some forms of a bind > >operation to a second DSA. > > Yes. I'm looking at mechanisms for distributed authentication > operations in addition to mechanisms for distributed > (non-authentication) operations. > > Kurt > > > >Jim > > > >>>> Ed Reed 6/25/04 8:37:08 AM >>> > >I'd really love to see an extended, chained operation that: > > > >1) relies on the chaining DSA to authenticate, using it's own > identity > >and crendentials, to establish a secure connection (probably over > SSL) > >over which the chaining DSA and the target DSA (the one who will > receive > >the chained request) will communicate; > >2) a chained, or perhaps alltogether new, operation that > authenticates > >a user and their bind credentials, but doens't result in a separate > >authentication connection on the target DSA, but rather results in a > >"yeah, I'd accept that, perhaps with these limitations" result on > which > >the chaining DSA (or other intermediary service speaking as though it > >were a trusted chaining DSA) could rely. > > > >This would allow a proxy, whether a web service, a firewall, or > another > >directory, to open a single connection to each target DSA, and then > >utter "is this guy okay" requests, perhaps with multiple round trips > so > >any challenge-response transactions used in the authentication > mechanism > >used by the end users could be satisfied. > > > >Such a multiplexing of the single trusted connection would reduce > >resource consumption by the intermediary as well as the target DSAs. > >Doing this for SASL, generally, would seem like a good idea. Target > DSAs > >could then be configured to allow or not allow such intermediary > >multiplexing connections, and if allow them rely on the strength and > >confidence in the authentication of the chaining server to guide its > >responses. > > > >In the most simple sense, if a simple compare of a presented password > >to a user's password attribute would satisfy the chaining DSA of the > >authentication of the user, there would be no need to lash up a whole > >connection with bind and SSL handshakes for the relying system to > know > >the user is authenticated. > > > >SASL presents a more challenging design, but this notion of chaining, > >if done correctly, would seem to fit the bill. > > > >Or am I off in la-la-land, again? > > > >Ed > > > > > >>>>"Kurt D. Zeilenga" 06/25 9:49 am >>> > >At 11:47 PM 6/24/2004, Mark Ennis wrote: > >>Kurt D. Zeilenga wrote: > >>>BTW, I'd like to add support for chaining SASL bind exchanges. > >>>This will require some fields beyond those offered by the > >>>X.518 ChainingArguments/ChainingResults structures. > >> > >>I agree that a mechanism for chaining SASL bind exchanges would be > >useful, however, current chaining mechanisms (e.g. X.518 or LDAP > >referrals) depend on name resolution of a base object. The bind > >operation, particularly when using a SASL mechanism, does not have a > >base object for the name resolution process. This would mean special > >procedures for "chaining" this operation. > >> > >>Does this also require formalising some type of trust model between > >DSAs if we are going to delegate authentication operations to another > >server? > > > >Yes. > > > >>Is it possible to translate this SASL bind exchange into a LDAP > >operation the initiating DSA invokes, e.g. a search for the SASL > >"username" with a control used to transmit the SASL credentials and > >receive the SASL auth-response? > > > >Depending on mechanism, depending on assumptions, yes. > > > >>Such an operation may then be chained by the responding DSA(s) and > >authorization decisions will be done using the initiating DSA as the > >authorization identity? > > > >Possibly. > > > >I, however, was considering an approach where the initiating server > >would pass through the original request with some additional > >information > >so that the chained server can form the proper response, and return > >that response with some additional information needed by the chaining > > >server to make use of the response. > > > >This may be an area better left to a separate document (and > >separate extended operation). If I have time in the next few > >weeks, I'll try to outline a proposal here in an I-D. > > > > > > > >Ldapext mailing list > >Ldapext@ietf.org > >https://www1.ietf.org/mailman/listinfo/ldapext > > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 30 19:24:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28719 for ; Wed, 30 Jun 2004 19:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfoM4-0000Da-1j; Wed, 30 Jun 2004 19:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfoIn-000809-Cx for ldapext@megatron.ietf.org; Wed, 30 Jun 2004 19:15:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28525 for ; Wed, 30 Jun 2004 19:15:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfoIl-0001mN-NS for ldapext@ietf.org; Wed, 30 Jun 2004 19:15:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfoHu-0001Oe-00 for ldapext@ietf.org; Wed, 30 Jun 2004 19:14:46 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BfoHC-0000m3-00 for ldapext@ietf.org; Wed, 30 Jun 2004 19:14:02 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 30 Jun 2004 17:13:27 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 30 Jun 2004 17:13:04 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ldapext] Is exclude subtree useful outside of chained operations? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit One of the features of the chained operation is the ability to tell the receiving DSA not to search a particular subtree (or subtrees). This helps cut down on the problem of duplicate suearch results (10.9 of X.518 has a good illustration of where this is useful). I'm wondering if this ability makes sense outside of the chained operation (in which case we can use a control both for the chained operation, other operations). So for example, has the ability been requested to perform a subtree search, but to exclude one or more subtrees? Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 30 20:02:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01036 for ; Wed, 30 Jun 2004 20:02:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfoxK-0000Eg-2M; Wed, 30 Jun 2004 19:57:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfoix-00047U-SS for ldapext@megatron.ietf.org; Wed, 30 Jun 2004 19:42:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29417 for ; Wed, 30 Jun 2004 19:42:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfoiw-0004Xb-99 for ldapext@ietf.org; Wed, 30 Jun 2004 19:42:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfohy-0004AI-00 for ldapext@ietf.org; Wed, 30 Jun 2004 19:41:43 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 1BfohX-0003mq-00 for ldapext@ietf.org; Wed, 30 Jun 2004 19:41:15 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i5UNf9MC063162; Wed, 30 Jun 2004 23:41:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040630163011.04983ce0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 30 Jun 2004 16:41:30 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Is exclude subtree useful outside of chained operations? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org At 04:13 PM 6/30/2004, Jim Sermersheim wrote: >One of the features of the chained operation is the ability to tell the >receiving DSA not to search a particular subtree (or subtrees). This >helps cut down on the problem of duplicate suearch results (10.9 of >X.518 has a good illustration of where this is useful). > >I'm wondering if this ability makes sense outside of the chained >operation (in which case we can use a control both for the chained >operation, other operations). So for example, has the ability been >requested to perform a subtree search, but to exclude one or more >subtrees? I think it would be good to allow superior/subordinate DN matching in search filters. Given an operational attribute which holds a copy of the entry's DN, say entryDN, many of the useful cases can be expressed using component matching. I actually having writing an I-D specifying the entryDN and its uses (including with component matching, possibly additional rule(s)) on my TO DO list. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 30 22:24:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07616 for ; Wed, 30 Jun 2004 22:24:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfrEu-0006pc-43; Wed, 30 Jun 2004 22:23:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfrA2-0006I9-PN for ldapext@megatron.ietf.org; Wed, 30 Jun 2004 22:18:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07513 for ; Wed, 30 Jun 2004 22:18:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfrA1-0003ko-1x for ldapext@ietf.org; Wed, 30 Jun 2004 22:18:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfr90-0003Nk-00 for ldapext@ietf.org; Wed, 30 Jun 2004 22:17:47 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1Bfr8g-00030X-00 for ldapext@ietf.org; Wed, 30 Jun 2004 22:17:26 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Wed, 30 Jun 2004 20:16:52 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Wed, 30 Jun 2004 20:16:14 -0600 From: "Jim Sermersheim" To: Subject: Re: [ldapext] Is exclude subtree useful outside of chained operations? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Content-Transfer-Encoding: 7bit So that's a different way of accomplishing the same results for search. For search, I like the attribute approach better. That significantly reduces the appeal of pulling 'exclusions' out of the chained operation. The cases left would be non-search operations that work on a subtree. For example, a 'deleteSubtree' operation could be augmented with exclusions which effectively cause only a part of the subtree to be deleted. On the other hand, for any new subtree-oriented operations should probably seriously consider using a search filter to specify the subtree to be affected. So maybe there's no appeal at all in creating an 'exclude subtree' control. Jim >>> "Kurt D. Zeilenga" 6/30/04 5:41:30 PM >>> At 04:13 PM 6/30/2004, Jim Sermersheim wrote: >One of the features of the chained operation is the ability to tell the >receiving DSA not to search a particular subtree (or subtrees). This >helps cut down on the problem of duplicate suearch results (10.9 of >X.518 has a good illustration of where this is useful). > >I'm wondering if this ability makes sense outside of the chained >operation (in which case we can use a control both for the chained >operation, other operations). So for example, has the ability been >requested to perform a subtree search, but to exclude one or more >subtrees? I think it would be good to allow superior/subordinate DN matching in search filters. Given an operational attribute which holds a copy of the entry's DN, say entryDN, many of the useful cases can be expressed using component matching. I actually having writing an I-D specifying the entryDN and its uses (including with component matching, possibly additional rule(s)) on my TO DO list. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext