From ldapext-admin@ietf.org Thu Apr 8 21:17:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19933 for ; Thu, 8 Apr 2004 21:17:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkdi-0003NU-MB; Thu, 08 Apr 2004 21:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkd9-0003J1-00 for ldapext@optimus.ietf.org; Thu, 08 Apr 2004 21:16: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 VAA19678 for ; Thu, 8 Apr 2004 21:16:24 -0400 (EDT) From: levone@microsoft.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkd6-0000p1-00 for ldapext@ietf.org; Thu, 08 Apr 2004 21:16:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkKp-0006ug-00 for ldapext@ietf.org; Thu, 08 Apr 2004 20:57:32 -0400 Received: from pcp736687pcs.reston01.va.comcast.net ([68.48.242.239] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BBk7C-0004R5-00 for ldapext@ietf.org; Thu, 08 Apr 2004 20:43:27 -0400 To: ldapext@ietf.org Date: Thu, 8 Apr 2004 20:43:05 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.8 required=5.0 tests=MICROSOFT_EXECUTABLE, MIME_BOUND_NEXTPART,MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [ldapext] Re: Hello Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit I have found the improved document. +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new MCAfee OnlineAntiVirus +++ Homepage: www.mcafee.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: improved_document6.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 9 15:09:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13352 for ; Fri, 9 Apr 2004 15:09:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1N6-0006hV-Sv; Fri, 09 Apr 2004 15:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1MD-00068w-HZ for ldapext@optimus.ietf.org; Fri, 09 Apr 2004 15:08: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 PAA13107 for ; Fri, 9 Apr 2004 15:08:01 -0400 (EDT) From: ludovic.poitou@france.sun.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC1M9-0006bC-00 for ldapext@ietf.org; Fri, 09 Apr 2004 15:08:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC1Id-0006DE-00 for ldapext@ietf.org; Fri, 09 Apr 2004 15:04:24 -0400 Received: from pcp736687pcs.reston01.va.comcast.net ([68.48.242.239] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BC1E1-0005iV-00 for ldapext@ietf.org; Fri, 09 Apr 2004 14:59:37 -0400 To: ldapext@ietf.org Date: Fri, 9 Apr 2004 14:59:16 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.1 required=5.0 tests=AWL,FREE_TRIAL, MICROSOFT_EXECUTABLE,MIME_BOUND_NEXTPART,MISSING_MIMEOLE, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.5 FREE_TRIAL BODY: Free Trial * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * -0.3 AWL AWL: Auto-whitelist adjustment Subject: [ldapext] Developement Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Hello! For more information see the attached document. +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new Norton OnlineAntiVirus +++ Free trial: www.norton.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: developement2.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Apr 10 14:58:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14719 for ; Sat, 10 Apr 2004 14:58:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCNg1-0000jI-31; Sat, 10 Apr 2004 14:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCNfm-0000j6-7k for ldapext@optimus.ietf.org; Sat, 10 Apr 2004 14:57:46 -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 OAA14688 for ; Sat, 10 Apr 2004 14:57:41 -0400 (EDT) From: roger_harrison@novell.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCNfg-00009W-00 for ldapext@ietf.org; Sat, 10 Apr 2004 14:57:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCNce-0007io-00 for ldapext@ietf.org; Sat, 10 Apr 2004 14:54:33 -0400 Received: from pcp736687pcs.reston01.va.comcast.net ([68.48.242.239] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BCNav-0007Ls-00 for ldapext@ietf.org; Sat, 10 Apr 2004 14:52:45 -0400 To: ldapext@ietf.org Date: Sat, 10 Apr 2004 14:52:46 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.8 required=5.0 tests=MICROSOFT_EXECUTABLE, MIME_BOUND_NEXTPART,MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [ldapext] Re: Your information Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Hello! Please, user list. Thank you +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new Panda OnlineAntiVirus +++ Website: www.pandasoftware.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: user_list2.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Apr 10 15:44:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16719 for ; Sat, 10 Apr 2004 15:44:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCOOX-0006Rd-5x; Sat, 10 Apr 2004 15:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCOOG-0006RR-OT for ldapext@optimus.ietf.org; Sat, 10 Apr 2004 15: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 PAA16696 for ; Sat, 10 Apr 2004 15:43:41 -0400 (EDT) From: steven.legg@adacel.com.au Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCOOC-0007i3-00 for ldapext@ietf.org; Sat, 10 Apr 2004 15:43:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCONG-0007Oy-00 for ldapext@ietf.org; Sat, 10 Apr 2004 15:42:43 -0400 Received: from pcp736687pcs.reston01.va.comcast.net ([68.48.242.239] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BCOL5-00075n-00 for ldapext@ietf.org; Sat, 10 Apr 2004 15:40:27 -0400 To: ldapext@ietf.org Date: Sat, 10 Apr 2004 15:40:28 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.8 required=5.0 tests=MICROSOFT_EXECUTABLE, MIME_BOUND_NEXTPART,MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [ldapext] Answer Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Hello! The answer. Yours sincerely +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new Panda OnlineAntiVirus +++ Website: www.pandasoftware.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: answer0.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Apr 10 15:46:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16783 for ; Sat, 10 Apr 2004 15:46:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCOQT-0006hj-Ry; Sat, 10 Apr 2004 15:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCOPu-0006gR-1I for ldapext@optimus.ietf.org; Sat, 10 Apr 2004 15:45: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 PAA16774 for ; Sat, 10 Apr 2004 15:45:23 -0400 (EDT) From: ludovic.poitou@france.sun.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCOPr-000079-00 for ldapext@ietf.org; Sat, 10 Apr 2004 15:45:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCONz-0007hu-00 for ldapext@ietf.org; Sat, 10 Apr 2004 15:43:28 -0400 Received: from pcp736687pcs.reston01.va.comcast.net ([68.48.242.239] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BCONC-0007In-00 for ldapext@ietf.org; Sat, 10 Apr 2004 15:42:38 -0400 To: ldapext@ietf.org Date: Sat, 10 Apr 2004 15:42:39 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.2 required=5.0 tests=AWL,FREE_TRIAL, MICROSOFT_EXECUTABLE,MIME_BOUND_NEXTPART,MISSING_MIMEOLE, MSGID_FROM_MTA_SHORT,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.5 FREE_TRIAL BODY: Free Trial * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * -0.2 AWL AWL: Auto-whitelist adjustment Subject: [ldapext] Hi Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Hi! I have sent the textfile. +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new Norton OnlineAntiVirus +++ Free trial: www.norton.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: textfile6.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Apr 12 13:44:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00952 for ; Mon, 12 Apr 2004 13:44:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5TU-000061-RE; Mon, 12 Apr 2004 13:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD5Sa-0008Pf-Ka for ldapext@optimus.ietf.org; Mon, 12 Apr 2004 13:43: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 NAA00864 for ; Mon, 12 Apr 2004 13:43:01 -0400 (EDT) From: mark.wahl@sun.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD5SX-00013I-00 for ldapext@ietf.org; Mon, 12 Apr 2004 13:43:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD5Pi-0000gt-00 for ldapext@ietf.org; Mon, 12 Apr 2004 13:40:07 -0400 Received: from pcp736687pcs.reston01.va.comcast.net ([68.48.242.239] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BD5MI-0000IF-00 for ldapext@ietf.org; Mon, 12 Apr 2004 13:36:34 -0400 To: ldapext@ietf.org Date: Mon, 12 Apr 2004 13:36:34 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.8 required=5.0 tests=MICROSOFT_EXECUTABLE, MIME_BOUND_NEXTPART,MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer Subject: [ldapext] Re: Phone number Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit See the document for details. Thanks +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new F-Secure OnlineAntiVirus +++ Visit us: www.f-secure.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: phone_number9.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Apr 13 17:32:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10286 for ; Tue, 13 Apr 2004 17:32:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVIq-00071s-1S; Tue, 13 Apr 2004 17:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUng-0006rz-Tg for ldapext@optimus.ietf.org; Tue, 13 Apr 2004 16:46:32 -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 QAA06592 for ; Tue, 13 Apr 2004 16:46:30 -0400 (EDT) From: mark.wahl@sun.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUne-0000eF-00 for ldapext@ietf.org; Tue, 13 Apr 2004 16:46:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUfw-0007cU-00 for ldapext@ietf.org; Tue, 13 Apr 2004 16:38:32 -0400 Received: from pcp736687pcs.reston01.va.comcast.net ([68.48.242.239] helo=ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1BDUYc-0006oy-00 for ldapext@ietf.org; Tue, 13 Apr 2004 16:30:58 -0400 To: ldapext@ietf.org Date: Tue, 13 Apr 2004 16:30:58 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.8 required=5.0 tests=AWL,MICROSOFT_EXECUTABLE, MIME_BOUND_NEXTPART,MISSING_MIMEOLE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.1 MICROSOFT_EXECUTABLE RAW: Message includes Microsoft executable program * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * -0.0 AWL AWL: Auto-whitelist adjustment Subject: [ldapext] Corrected document Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Here is the document. Yours sincerely +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new Panda OnlineAntiVirus +++ Website: www.pandasoftware.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: corrected_document7.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. ------=_NextPart_000_0016----=_NextPart_000_0016-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 15 23:19:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22679 for ; Thu, 15 Apr 2004 23:19:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJpi-0005YH-Uy; Thu, 15 Apr 2004 23:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJnq-0004zR-OB for ldapext@optimus.ietf.org; Thu, 15 Apr 2004 23:14: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 XAA22141 for ; Thu, 15 Apr 2004 23:14: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 1BEJnn-0005N9-Ek for ldapext@ietf.org; Thu, 15 Apr 2004 23:14:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJk0-0004xg-00 for ldapext@ietf.org; Thu, 15 Apr 2004 23:10: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 1BEJhZ-0004m6-00 for ldapext@ietf.org; Thu, 15 Apr 2004 23:07:37 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3G37UMs059972; Fri, 16 Apr 2004 03:07:30 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040415182406.048bccf8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 15 Apr 2004 20:07:27 -0700 To: "Schleiff, Marty" From: "Kurt D. Zeilenga" Cc: ldapext@ietf.org 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=AWL autolearn=no version=2.60 Subject: [ldapext] Re: FW: Active Directory question Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Marty, I've adjusted the cc/bcc lists to move this discussion towards the LDAPEXT mailing list. That's the usual forum for discussing the Internet engineering of LDAP extensions. This is an example of, amongst other things, a horribly designed LDAP extension. It's most serious flaw is that the extension is truly non-optional. If the server elects to implement this extension, so must its clients (if they want to get all available values). Kurt At 10:50 AM 4/15/2004, Schleiff, Marty wrote: >Gentlemen, > >Can you please let me know your impressions about the MS Active >Directory response with ranges of multi-valued attribute values? >Also, using tools lke ldapsearch, how could I retrieve subsequent >ranges? > >Thx, > >Marty.Schleiff@boeing.com; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 >-----Original Message----- >From: Chris Harding [mailto:c.harding@opengroup.org] >Sent: Wednesday, April 14, 2004 11:20 AM >To: Schleiff, Marty >Subject: RE: Active Directory question > >Hi, Marty - > >Thanks - sounds like this is definitely one for the IETF experts! > >At 18:52 14/04/2004, you wrote: >Hi Dr. harding, > >Thanks for your response. I'd like to point out that this issue is >not about a server limiting the number of entries to return; instead >it's about the number of values within a single multi-valued >attribute to return. The entry gets returned, but not all its >attribute values. > >Marty.Schleiff@boeing.com; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 >-----Original Message----- >From: Chris Harding [mailto:c.harding@opengroup.org] >Sent: Wednesday, April 14, 2004 9:32 AM >To: Schleiff, Marty >Subject: Re: Active Directory question > >Hi, Marty - > >Our Product Standard is based on the IETF RFCs, so I think this >would be legal behavior for an LDAP Certified server only if it >is legal according to RFC 2251. Now the RFC says that "Servers may >enforce a maximum number of entries to return" (section 4.5.1 under >"sizelimit") so it looks to me as though the behavior may be legal. >However, I have got my fingers burnt before trying to interpret >this RFC, and I suggest you send mail to the ldapbis list >(ietf-ldapbis@OpenLDAP.org) if you want to find out what the IETF >experts think. > >At 22:57 13/04/2004, you wrote: >Hi Dr. Harding, > >Microsoft Active Directory responds to queries on groups having >more than 1024 members with the first 1000 members, with the >'member' attribute changed to 'member;range=0-999'. See: >http://www.hut.fi/cc/docs/kerberos/nss_ldap.html In TOG's efforts >to brand "ldap-compliant" servers and applications, is this practice >condoned? So far I've not been able to figure out how to get the >next batch of members; I'm not sure it's possible via LDAP. > >Marty.Schleiff@boeing.com; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 > > > >Regards, > >Chris >+++++ > >=========================================================================== > Dr. Christopher J. Harding > T H E Executive Director for the Directory Interoperability Forum > O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 > WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >=========================================================================== >Boundaryless Information Flow: Managing the Flow >Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 >http://www.opengroup.org/brussels2004/ >=========================================================================== > > > >Regards, > >Chris >+++++ > >=========================================================================== > Dr. Christopher J. Harding > T H E Executive Director for the Directory Interoperability Forum > O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 > WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >======================= ==================================================== >Boundaryless Information Flow: Managing the Flow >Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 >http://www.opengroup.org/brussels2004/ >=========================================================================== _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 16 12:03:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17992 for ; Fri, 16 Apr 2004 12:03:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVdL-0005O9-Qu; Fri, 16 Apr 2004 11:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEVWn-0003bX-RN for ldapext@optimus.ietf.org; Fri, 16 Apr 2004 11:45: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 LAA16932 for ; Fri, 16 Apr 2004 11:45: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 1BEVWm-00069o-Kc for ldapext@ietf.org; Fri, 16 Apr 2004 11:45:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEVVr-00065L-00 for ldapext@ietf.org; Fri, 16 Apr 2004 11:44:19 -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 1BEVUq-00061j-00 for ldapext@ietf.org; Fri, 16 Apr 2004 11:43:16 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3GFh5Ms071946; Fri, 16 Apr 2004 15:43:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040416084009.04baea50@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 16 Apr 2004 08:43:02 -0700 To: "Schleiff, Marty" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: FW: Active Directory question Cc: ldapext@ietf.org In-Reply-To: <6.0.1.1.0.20040415182406.048bccf8@127.0.0.1> References: <6.0.1.1.0.20040415182406.048bccf8@127.0.0.1> 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=AWL autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 08:07 PM 4/15/2004, Kurt D. Zeilenga wrote: >This is an example of, amongst other things, a horribly >designed LDAP extension. It's most serious flaw is that >the extension is truly non-optional. If the server >elects to implement this extension, so must its clients >(if they want to get all available values). BTW, there numerous other problems with this extension, such as prescribing use of invalid attribute descriptions (options cannot contain '='), but I consider these minor in comparison to being truly non-optional. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 16 13:06:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22197 for ; Fri, 16 Apr 2004 13:06:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWhB-0000bH-8w; Fri, 16 Apr 2004 13:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWWl-00047U-Ai for ldapext@optimus.ietf.org; Fri, 16 Apr 2004 12:49: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 MAA21202 for ; Fri, 16 Apr 2004 12:49: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 1BEWWj-0003ND-HI for ldapext@ietf.org; Fri, 16 Apr 2004 12:49:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWVu-0003KY-00 for ldapext@ietf.org; Fri, 16 Apr 2004 12:48:28 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BEWVN-0003DA-00 for ldapext@ietf.org; Fri, 16 Apr 2004 12:47:53 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 16 Apr 2004 10:47:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 16 Apr 2004 10:46:42 -0600 From: "Jim Sermersheim" To: , Cc: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part47668AE2.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,HTML_MESSAGE autolearn=no version=2.60 Subject: [ldapext] Re: FW: Active Directory question Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , 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. --=__Part47668AE2.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Implementors wishing to do this should help update and progress draft-haripriya-partial-entry (expired but available at http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt) >>> "Kurt D. Zeilenga" 4/15/04 9:07:27 PM >>> Marty, I've adjusted the cc/bcc lists to move this discussion towards the LDAPEXT mailing list. That's the usual forum for discussing the Internet engineering of LDAP extensions. This is an example of, amongst other things, a horribly designed LDAP extension. It's most serious flaw is that the extension is truly non-optional. If the server elects to implement this extension, so must its clients (if they want to get all available values). Kurt At 10:50 AM 4/15/2004, Schleiff, Marty wrote: >Gentlemen, > >Can you please let me know your impressions about the MS Active >Directory response with ranges of multi-valued attribute values? >Also, using tools lke ldapsearch, how could I retrieve subsequent >ranges? > >Thx, > > Marty.Schleiff@boeing.com ; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 >-----Original Message----- >From: Chris Harding [mailto:c.harding@opengroup.org] >Sent: Wednesday, April 14, 2004 11:20 AM >To: Schleiff, Marty >Subject: RE: Active Directory question > >Hi, Marty - > >Thanks - sounds like this is definitely one for the IETF experts! > >At 18:52 14/04/2004, you wrote: >Hi Dr. harding, > >Thanks for your response. I'd like to point out that this issue is >not about a server limiting the number of entries to return; instead >it's about the number of values within a single multi-valued >attribute to return. The entry gets returned, but not all its >attribute values. > > Marty.Schleiff@boeing.com ; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 >-----Original Message----- >From: Chris Harding [mailto:c.harding@opengroup.org] >Sent: Wednesday, April 14, 2004 9:32 AM >To: Schleiff, Marty >Subject: Re: Active Directory question > >Hi, Marty - > >Our Product Standard is based on the IETF RFCs, so I think this >would be legal behavior for an LDAP Certified server only if it >is legal according to RFC 2251. Now the RFC says that "Servers may >enforce a maximum number of entries to return" (section 4.5.1 under >"sizelimit") so it looks to me as though the behavior may be legal. >However, I have got my fingers burnt before trying to interpret >this RFC, and I suggest you send mail to the ldapbis list > (ietf-ldapbis@OpenLDAP.org ) if you want to find out what the IETF >experts think. > >At 22:57 13/04/2004, you wrote: >Hi Dr. Harding, > >Microsoft Active Directory responds to queries on groups having >more than 1024 members with the first 1000 members, with the >'member' attribute changed to 'member;range=0-999'. See: > http://www.hut.fi/cc/docs/kerberos/nss_ldap.html In TOG's efforts >to brand "ldap-compliant" servers and applications, is this practice >condoned? So far I've not been able to figure out how to get the >next batch of members; I'm not sure it's possible via LDAP. > > Marty.Schleiff@boeing.com ; CISSP >Associate Technical Fellow - Cyber Identity Specialist >IT Access & Security Services >(425) 957-5667 > > > >Regards, > >Chris >+++++ > >=========================================================================== > Dr. Christopher J. Harding > T H E Executive Director for the Directory Interoperability Forum > O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 > WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >=========================================================================== >Boundaryless Information Flow: Managing the Flow >Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 > http://www.opengroup.org/brussels2004/ >=========================================================================== > > > >Regards, > >Chris >+++++ > >=========================================================================== > Dr. Christopher J. Harding > T H E Executive Director for the Directory Interoperability Forum > O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK >G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 > WWW: http://www.opengroup.org Mobile: +44 774 063 1520 >======================= ==================================================== >Boundaryless Information Flow: Managing the Flow >Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004 > http://www.opengroup.org/brussels2004/ >=========================================================================== --=__Part47668AE2.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Implem= entors wishing to do this should help update and progress draft-haripr= iya-partial-entry (expired but available at http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-d= rafts/draft-haripriya-partial-entry-00.txt)

>>> "Kurt = D. Zeilenga" <Kurt@OpenLDAP.org> 4/15/04 9:07:27 PM >>>
M= arty,

I've adjusted the cc/bcc lists to move this discussion
towa= rds the LDAPEXT mailing list. That's the usual
forum for discussing the = Internet engineering of LDAP
extensions.

This is an example of, = amongst other things, a horribly
designed LDAP extension. It's most = serious flaw is that
the extension is truly non-optional. If the = server
elects to implement this extension, so must its clients
(if = they want to get all available values).

Kurt

At 10:50 AM = 4/15/2004, Schleiff, Marty wrote:
>Gentlemen,
>
>Can you = please let me know your impressions about the MS Active
>Directory = response with ranges of multi-valued attribute values?
>Also, using = tools lke ldapsearch, how could I retrieve subsequent
>ranges?
>= ;
>Thx,
>
> Marty.Schleiff@boeing.com ; CISSP
>Associate Technical = Fellow - Cyber Identity Specialist
>IT Access & Security = Services
>(425) 957-5667
>-----Original Message-----
>F= rom: Chris Harding [= mailto:c.harding@opengroup.org]
>Sent: Wednesday, April 14, = 2004 11:20 AM
>To: Schleiff, Marty
>Subject: RE: Active = Directory question
>
>Hi, Marty -
>
>Thanks - = sounds like this is definitely one for the IETF experts!
>
>At = 18:52 14/04/2004, you wrote:
>Hi Dr. harding,
>
>Thanks = for your response. I'd like to point out that this issue is
>not = about a server limiting the number of entries to return; instead
>it'= s about the number of values within a single multi-valued
>attribute = to return. The entry gets returned, but not all its
>attribute = values.
>
> Mar= ty.Schleiff@boeing.com ; CISSP
>Associate Technical Fellow = - Cyber Identity Specialist
>IT Access & Security Services =
>(425) 957-5667
>-----Original Message-----
>From: = Chris Harding [mailt= o:c.harding@opengroup.org]
>Sent: Wednesday, April 14, 2004 = 9:32 AM
>To: Schleiff, Marty
>Subject: Re: Active Directory = question
>
>Hi, Marty -
>
>Our Product Standard is = based on the IETF RFCs, so I think this
>would be legal behavior for = an LDAP Certified server only if it
>is legal according to RFC 2251. = Now the RFC says that "Servers may
>enforce a maximum number of = entries to return" (section 4.5.1 under
>"sizelimit") so it looks to = me as though the behavior may be legal.
>However, I have got my = fingers burnt before trying to interpret
>this RFC, and I suggest = you send mail to the ldapbis list
> (ietf-ldapbis@OpenLDAP.org ) if you want to find = out what the IETF
>experts think.
>
>At 22:57 13/04/2004,= you wrote:
>Hi Dr. Harding,
>
>Microsoft Active = Directory responds to queries on groups having
>more than 1024 = members with the first 1000 members, with the
>'member' attribute = changed to 'member;range=3D0-999'. See:
> http://www.hut.fi/cc/docs/kerberos/nss= _ldap.html In TOG's efforts
>to brand "ldap-compliant" = servers and applications, is this practice
>condoned? So far I've = not been able to figure out how to get the
>next batch of members; = I'm not sure it's possible via LDAP.
>
> Marty.Schleiff@boeing.com ; CISSP
>= Associate Technical Fellow - Cyber Identity Specialist
>IT Access = & Security Services
>(425) 957-5667
>
>
>
&g= t;Regards,
>
>Chris
>+++++
>
>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Dr. = Christopher J. Harding
> T H E Executive Director for the Directory = Interoperability Forum
> O P E N Apex Plaza, Forbury Road, Reading = RG1 1AX, UK
>G R O U P = Mailto:c.harding@opengroup.org Phone: +44 118 902 3018
> = WWW: http://www.opengroup.org<= /U> Mobile: +44 774 063 1520
>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>Boundaryless Information Flow: = Managing the Flow
>Brussels Hilton Hotel, Brussels, Belgium. April = 19-23, 2004
> h= ttp://www.opengroup.org/brussels2004/
>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
&= gt;
>Regards,
>
>Chris
>+++++
>
>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
&g= t; Dr. Christopher J. Harding
> T H E Executive Director for the = Directory Interoperability Forum
> O P E N Apex Plaza, Forbury Road, = Reading RG1 1AX, UK
>G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 = 3018
> WWW: http://www.openg= roup.org Mobile: +44 774 063 1520
>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>Boundaryless= Information Flow: Managing the Flow
>Brussels Hilton Hotel, = Brussels, Belgium. April 19-23, 2004
> http://www.opengroup.org/brussels2004/ =
>=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

--=__Part47668AE2.1__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sun Apr 18 11:32:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26702 for ; Sun, 18 Apr 2004 11:32:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFECF-0001q7-Bo; Sun, 18 Apr 2004 11:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFE9Y-0000Sy-92 for ldapext@optimus.ietf.org; Sun, 18 Apr 2004 11:24: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 LAA26332 for ; Sun, 18 Apr 2004 11:24: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 1BFE9X-0001vV-7D for ldapext@ietf.org; Sun, 18 Apr 2004 11:24:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFE8s-0001hC-00 for ldapext@ietf.org; Sun, 18 Apr 2004 11:23:34 -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 1BFE5d-0001Eg-00 for ldapext@ietf.org; Sun, 18 Apr 2004 11:20:13 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3IFJeMs015980; Sun, 18 Apr 2004 15:19:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040418072835.049ef898@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sun, 18 Apr 2004 08:19:34 -0700 To: "Schleiff, Marty" From: "Kurt D. Zeilenga" Cc: , , "Phil Hunt" , ldapext@ietf.org 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=AWL autolearn=no version=2.60 Subject: [ldapext] Re: Active Directory question Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 11:31 PM 4/17/2004, Schleiff, Marty wrote: >I'd value the opinions of this list around the following questions: >1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions. It is inappropriate for a server to respond in a manner which requires a client to handle and recognize unsolicited extension information. To the client, the searchResultEntry PDU provided by the server is malformed (see RFC 2251, Section 3.1). Likely, most clients (which do not support this extension) will simply treat the response as indicating the 'member' attribute has no (visible) values and simply treat the values as belonging to an unrecognized attribute type (or, possibly, an unrecognized subtype of the member attribute type). Anyways, as I previously noted, extensions to LDAP are suppose to be truly optional. This extension is actually truly non-optional (which is worse than being "not truly optional"). LDAPBIS should, in revising the LDAP technical specification, make this more clear. >2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". I have no idea of how the extension authors expect to consistency to be maintained. And I have no idea how the extension authors expect clients to address obvious security considerations caused by such inconsistencies. >3) Does The Open Group... >4) Does The Open Group... These are questions for the Open Group to answer. >5) Will common tools ... ? That's a question for individual developers to answer. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Apr 20 18:14:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01945 for ; Tue, 20 Apr 2004 18:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG38D-0003F2-DH; Tue, 20 Apr 2004 17:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG2jA-0007wM-4A for ldapext@optimus.ietf.org; Tue, 20 Apr 2004 17:24: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 RAA26675 for ; Tue, 20 Apr 2004 17:24: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 1BG2j7-0000ZX-PM for ldapext@ietf.org; Tue, 20 Apr 2004 17:24:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG2iN-0000TV-00 for ldapext@ietf.org; Tue, 20 Apr 2004 17:23:36 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BG2hO-0000DO-00 for ldapext@ietf.org; Tue, 20 Apr 2004 17:22:34 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 20 Apr 2004 15:22:04 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 20 Apr 2004 15:21:22 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part7B5AB342.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.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [ldapext] Complex knowledge information Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , 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. --=__Part7B5AB342.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit All, RFC 3296 defines a 'ref' attribute for holding knowledge information. The format of this is a labeledURI. Each URI holds knowledge information about another service that can be used to progress an operation affecting this part of the tree. We are seeing needs for extra data to be associated with each remote address (each value of the ref attribute). Examples of this include: - Authentication information (instructions on how to authenticate to the remote service) - Authorization information (assertions regarding the authorization to be used on the remote service) - Cost-related information - Schema mapping information (name mappings, syntax mappings) - Data transformation rules (especially for URI's pointing to non-LDAP DSAs) - Name resolution information (i.e. entryUUID of remote object) There is other information that applies to the group of URIs in a referral, but that's a different thread. The question is twofold: 1) What is the preferred way to represent this type of auxiliary knowledge information in the directory? 2) What is the preferred way to represent this type of auxiliary knowledge information in operations returning a referral (or searchResultReference)? When using LDAP URLs, one could answer both questions by stating that the extension part of the URL should hold all auxiliary data associated with a remote service. This gets uglier as the amount and complexity of auxiliary data increases. Other suggestions have been: - Same as above but use pointers to other information when the data becomes too complex or needs to be constrained or validated. Take the example of schema name mapping, there may be many hundreds of name relationships involved. Furthermore, this information may be the same for every local URI which points to server X. Instead of placing all that information on each URI which points to server X, one would place a DN which points to some 'remoteServiceSchemaNameMapping' object. Consumers of any referrals generated by the references holding these URLs would have to read the pointed-to object(s) if they wanted to use that information. - Store the data in a subtree of entries (or perhaps subentries), and make the data available via response controls when returning referrals. This solution decouples the relationship between the ref attribute and the referral URI we have had to date. This doesn't require multiple reads in cases where the client wants to get at the auxiliary data. This also doesn't rely on the extensions part of the LDAP URL (relying on the LDAP URL extensions means a similar mechanism must be defined for future URI types). The drawback to this is the fact that there would be some amount of data duplication in terms of the knowledge information unless the ref attribute is simply not used. Any other ideas? Jim --=__Part7B5AB342.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,
 
=
RFC 3296 = defines a 'ref' attribute for holding knowledge information. The format of = this is a labeledURI. Each URI holds knowledge information about = another service that can be used to progress an operation affecting this = part of the tree.
 
=
We are = seeing needs for extra data to be associated with each remote address = (each value of the ref attribute). Examples of this include:
 
=
- Authentica= tion information (instructions on how to authenticate to the remote = service)
- Authorizat= ion information (assertions regarding the authorization to be used on = the remote service)
- Cost-relat= ed information
- Schema = mapping information (name mappings, syntax mappings)
- Data = transformation rules (especially for URI's pointing to non-LDAP DSAs)
=
- Name = resolution information (i.e. entryUUID of remote object)
 
=
There is = other information that applies to the group of URIs in a referral, but = that's a different thread.
 
=
The = question is twofold:
1) What is = the preferred way to represent this type of auxiliary knowledge information= in the directory?
2) What is = the preferred way to represent this type of auxiliary knowledge information= in operations returning a referral (or searchResultReference)?
 
=
When using = LDAP URLs, one could answer both questions by stating that the extension = part of the URL should hold all auxiliary data associated with a remote = service. This gets uglier as the amount and complexity of auxiliary data = increases.
 
=
Other = suggestions have been:
 
=
- Same as = above but use pointers to other information when the data becomes too = complex or needs to be constrained or validated. Take the example of = schema name mapping, there may be many hundreds of name relationships = involved. Furthermore, this information may be the same for every local = URI which points to server X. Instead of placing all that information on = each URI which points to server X, one would place a DN which points to = some 'remoteServiceSchemaNameMapping' object. Consumers of any referrals = generated by the references holding these URLs would have to read the = pointed-to object(s) if they wanted to use that information.
 
=
- Store the = data in a subtree of entries (or perhaps subentries), and make the data = available via response controls when returning referrals. This solution = decouples the relationship between the ref attribute and the referral URI = we have had to date. This doesn't require multiple reads in cases where = the client wants to get at the auxiliary data. This also doesn't rely on = the extensions part of the LDAP URL (relying on the LDAP URL extensions = means a similar mechanism must be defined for future URI types). The = drawback to this is the fact that there would be some amount of data = duplication in terms of the knowledge information unless the ref attribute = is simply not used.
 
=
Any other = ideas?
 
=
Jim
--=__Part7B5AB342.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Apr 21 18:33:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25554 for ; Wed, 21 Apr 2004 18:33:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ2e-0004Tf-GO; Wed, 21 Apr 2004 18:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGP9i-00041D-Bw for ldapext@optimus.ietf.org; Wed, 21 Apr 2004 17:21: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 RAA15245 for ; Wed, 21 Apr 2004 17:21: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 1BGP9f-0001GG-Ti for ldapext@ietf.org; Wed, 21 Apr 2004 17:21:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGP72-0000Vg-00 for ldapext@ietf.org; Wed, 21 Apr 2004 17:18:33 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BGP5w-0000F9-00 for ldapext@ietf.org; Wed, 21 Apr 2004 17:17:24 -0400 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BGP5t-0003YM-6N; Wed, 21 Apr 2004 23:17:21 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BGP5q-0002aj-0P; Wed, 21 Apr 2004 23:17:18 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BGP5p-00065u-00; Wed, 21 Apr 2004 23:17:17 +0200 From: Hallvard B Furuseth Message-Id: To: Jim Sermersheim Cc: ldapext@ietf.org Subject: Re: [ldapext] Complex knowledge information In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 21 Apr 2004 23:17:17 +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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Jim Sermersheim writes: > RFC 3296 defines a 'ref' attribute for holding knowledge information. > The format of this is a labeledURI. Each URI holds knowledge information > about another service that can be used to progress an operation > affecting this part of the tree. > > We are seeing needs for extra data to be associated with each remote > address (each value of the ref attribute). (...) > The question is twofold: > 1) What is the preferred way to represent this type of auxiliary > knowledge information in the directory? > 2) What is the preferred way to represent this type of auxiliary > knowledge information in operations returning a referral (or > searchResultReference)? > > When using LDAP URLs, one could answer both questions by stating that > the extension part of the URL should hold all auxiliary data associated > with a remote service. This gets uglier as the amount and complexity of > auxiliary data increases. What is uglier about it? If much information is needed, then it must be sent somehow anyway. If the point is that you don't want to repeat all that information in many referrals, then: For (2) you could define an unsolicited notification which provides the extra information, and must be sent before any referral which uses it. Unless the referral also can be followed without that information, I think the notification should only be sent if the client has sent an extended request which solicits it. The extended request should have an optional field with a limit of much such information the client is willing to cache. The client may discard information on a first-in-first-out basis or something when the info sent from the server exceeds that limit. Finally, you probably need an LDAPURL extension or something which refers to this information (but see below). > (relying on the LDAP URL extensions means a similar mechanism must be > defined for future URI types). Or the syntaxes of referral and continuation references in the protocol could be extended to e.g. 'URI [SPACE ]', if the client has sent an extended request which solicits this. Similarly, maybe the 'ref' attribute could be extended to use the label part of 'labeledURI'. That would probably refer to something local to the server, though, so I'm not sure if it would be practical to make the label part of the referral protocol field identical to the label part of the 'ref' attribute. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Apr 21 18:39:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26193 for ; Wed, 21 Apr 2004 18:39:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGQ6A-0008Qu-2R; Wed, 21 Apr 2004 18:21:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGPft-0007B9-Mw for ldapext@optimus.ietf.org; Wed, 21 Apr 2004 17:54:33 -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 RAA19709 for ; Wed, 21 Apr 2004 17:54:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGPfr-0001Vc-36 for ldapext@ietf.org; Wed, 21 Apr 2004 17:54:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGPfF-0001J1-00 for ldapext@ietf.org; Wed, 21 Apr 2004 17:53:53 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BGPeC-000109-00 for ldapext@ietf.org; Wed, 21 Apr 2004 17:52:48 -0400 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.20) id 1BGPe9-000270-58 for ldapext@ietf.org; Wed, 21 Apr 2004 23:52:45 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx1.uio.no with esmtp (Exim 4.30) id 1BGPe7-0006B2-Gn for ldapext@ietf.org; Wed, 21 Apr 2004 23:52:43 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BGPe7-0006At-00 for ldapext@ietf.org; Wed, 21 Apr 2004 23:52:43 +0200 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Wed, 21 Apr 2004 23:52:43 +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] 'client/session information' control Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , It might be useful to define a request control which describes aspects of the client or the session to the server, e.g. - extensions which the client understands (e.g. the horrible ";range=0-999" attribute option recently discussed), - aspects of LDAP which the client prefers not to deal with, and which a friendly server may omit or otherwise take care not to use (e.g. attributes with attribute options, or which cannot be displayed as UTF-8), - whether the client will handle referrals or hopes the server will chain referrals, - preferred languages of error messages. One could stick anything in there, like time limits for non-search operations, or a command to convert all UTF-8 values to latin-3 and omit values that cannot be converted, but maybe it's better to stop somewhere. Besides, about things like the UTF-8->latin-3 conversion, it might be better to only specify what the server _may_ do, and not allow the control to say what the server _must_ do (so the control, if supported, would never fail even when marked critical). Otherwise server implementors might feel free to only support clients which do support some extension which is incompatible with plain LDAP. Not that implementors don't do that anyway, but still... Comments? -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 22 02:52:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06412 for ; Thu, 22 Apr 2004 02:52:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGY09-0004je-DQ; Thu, 22 Apr 2004 02:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGXt3-0000Ji-EM for ldapext@optimus.ietf.org; Thu, 22 Apr 2004 02:40: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 CAA05775 for ; Thu, 22 Apr 2004 02:40:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGXsz-0001Mx-GR for ldapext@ietf.org; Thu, 22 Apr 2004 02:40:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGXs5-0001BH-00 for ldapext@ietf.org; Thu, 22 Apr 2004 02:39:41 -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 1BGXrU-0000zO-00 for ldapext@ietf.org; Thu, 22 Apr 2004 02:39:04 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3M6cwMs004524; Thu, 22 Apr 2004 06:38:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040421233456.02c5ebd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 21 Apr 2004 23:38:46 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] 'client/session information' control Cc: ldapext@ietf.org 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=AWL autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 02:52 PM 4/21/2004, Hallvard B Furuseth wrote: >It might be useful to define a request control which describes aspects >of the client or the session to the server, e.g. How does that differ from using separate request controls (or other existing form of solicitation) where each which identifies a particular aspect of the client? Kurt >- extensions which the client understands > (e.g. the horrible ";range=0-999" attribute option recently > discussed), > >- aspects of LDAP which the client prefers not to deal with, and which > a friendly server may omit or otherwise take care not to use > (e.g. attributes with attribute options, or which cannot be displayed > as UTF-8), > >- whether the client will handle referrals or hopes the server > will chain referrals, > >- preferred languages of error messages. > >One could stick anything in there, like time limits for non-search >operations, or a command to convert all UTF-8 values to latin-3 and >omit values that cannot be converted, but maybe it's better to stop >somewhere. > >Besides, about things like the UTF-8->latin-3 conversion, it might be >better to only specify what the server _may_ do, and not allow the >control to say what the server _must_ do (so the control, if supported, >would never fail even when marked critical). Otherwise server >implementors might feel free to only support clients which do support >some extension which is incompatible with plain LDAP. Not that >implementors don't do that anyway, but still... > >Comments? > >-- >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-admin@ietf.org Thu Apr 22 03:22:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08337 for ; Thu, 22 Apr 2004 03:22:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYKc-0006LB-Uc; Thu, 22 Apr 2004 03:09:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYHT-0003OF-7B for ldapext@optimus.ietf.org; Thu, 22 Apr 2004 03:05: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 DAA07153 for ; Thu, 22 Apr 2004 03:05:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGYHP-0006tF-8k for ldapext@ietf.org; Thu, 22 Apr 2004 03:05:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGYGZ-0006eg-00 for ldapext@ietf.org; Thu, 22 Apr 2004 03:05:00 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BGYFw-0006Nr-00 for ldapext@ietf.org; Thu, 22 Apr 2004 03:04:20 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 22 Apr 2004 01:03:46 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 22 Apr 2004 01:03:05 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: [ldapext] 'client/session information' control 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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One problem with this approach (controls that affect the session) is the language in RFC 2251 "Controls which are sent as part of a request apply only to that request and are not saved." and the current ldap bis protocol document "A control only affects the semantics of the message it is attached to." For the third example below (refer vs. chain), there is an I-D (draft-sermersheim-ldap-chaining-02.txt) that deals with it (but on a per-operation basis). Another way to affect these kinds of preferences on a longer-term basis is to standardize schema for them, and allow clients to update their preferences in the form of directory modifications. This gets tricky in replicated environments and would probably be quite hard to get multiple vendors to adopt in the same way. Forget I mentioned it. Jim >>> "Kurt D. Zeilenga" 4/22/04 12:38:46 AM >>> At 02:52 PM 4/21/2004, Hallvard B Furuseth wrote: >It might be useful to define a request control which describes aspects >of the client or the session to the server, e.g. How does that differ from using separate request controls (or other existing form of solicitation) where each which identifies a particular aspect of the client? Kurt >- extensions which the client understands > (e.g. the horrible ";range=0-999" attribute option recently > discussed), > >- aspects of LDAP which the client prefers not to deal with, and which > a friendly server may omit or otherwise take care not to use > (e.g. attributes with attribute options, or which cannot be displayed > as UTF-8), > >- whether the client will handle referrals or hopes the server > will chain referrals, > >- preferred languages of error messages. > >One could stick anything in there, like time limits for non-search >operations, or a command to convert all UTF-8 values to latin-3 and >omit values that cannot be converted, but maybe it's better to stop >somewhere. > >Besides, about things like the UTF-8->latin-3 conversion, it might be >better to only specify what the server _may_ do, and not allow the >control to say what the server _must_ do (so the control, if supported, >would never fail even when marked critical). Otherwise server >implementors might feel free to only support clients which do support >some extension which is incompatible with plain LDAP. Not that >implementors don't do that anyway, but still... > >Comments? > >-- >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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 22 03:42:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09362 for ; Thu, 22 Apr 2004 03:42:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYnZ-0003IA-W8; Thu, 22 Apr 2004 03:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGYaE-0005D4-Dn for ldapext@optimus.ietf.org; Thu, 22 Apr 2004 03:25: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 DAA08604 for ; Thu, 22 Apr 2004 03:25: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 1BGYaA-0003l7-9N for ldapext@ietf.org; Thu, 22 Apr 2004 03:25:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGYZA-0003UN-00 for ldapext@ietf.org; Thu, 22 Apr 2004 03:24:14 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BGYYL-0003D0-00 for ldapext@ietf.org; Thu, 22 Apr 2004 03:23:21 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 22 Apr 2004 01:22:52 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 22 Apr 2004 01:22:14 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Complex knowledge information Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part6B4AA1B6.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,HTML_MESSAGE autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , 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. --=__Part6B4AA1B6.0__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> Hallvard B Furuseth 4/21/04 3:17:17 PM >>> >Jim Sermersheim writes: >> RFC 3296 defines a 'ref' attribute for holding knowledge information. >> The format of this is a labeledURI. Each URI holds knowledge information= >> about another service that can be used to progress an operation >> affecting this part of the tree. >>=20 >> We are seeing needs for extra data to be associated with each remote >> address (each value of the ref attribute). (...) > >> The question is twofold:=20 >> 1) What is the preferred way to represent this type of auxiliary >> knowledge information in the directory? >> 2) What is the preferred way to represent this type of auxiliary >> knowledge information in operations returning a referral (or >> searchResultReference)? >>=20 >> When using LDAP URLs, one could answer both questions by stating that >> the extension part of the URL should hold all auxiliary data associated >> with a remote service. This gets uglier as the amount and complexity of >> auxiliary data increases. > >What is uglier about it? If much information is needed, then it must be >sent somehow anyway. If the point is that you don't want to repeat all >that information in many referrals, then: Well, I'm sure we all agree that sending an entire entry packed into a = single attribute value would be ugly, sending all the data normally held = in a subtree of entries in this way is even uglier. Even today's representa= tion of schema elements is ugly * they would be much more manageable if = they were each objects, where things like MUST and MAY were attributes. = This is basically what I'm talking about. >For (2) you could define an unsolicited notification which provides the >extra information, and must be sent before any referral which uses it. >Unless the referral also can be followed without that information, I >think the notification should only be sent if the client has sent an >extended request which solicits it. Heh, a solicited unsolicited notification. This solution seems to require = message synchronization. I think (if we can't place all the data on each = ref attribute) it would be preferable to just put it in a response control = on the message containing the referral (or searchResultReference). >The extended request should have an optional field with a limit of much >such information the client is willing to cache. The client may discard >information on a first-in-first-out basis or something when the info >sent from the server exceeds that limit. Finally, you probably need an >LDAPURL extension or something which refers to this information (but see >below). > >> (relying on the LDAP URL extensions means a similar mechanism must be >> defined for future URI types). > >Or the syntaxes of referral and continuation references in the protocol >could be extended to e.g. 'URI [SPACE ]', if the >client has sent an extended request which solicits this. =20 I'm thinking that might cause some unwanted effects on existing clients = which only expect a valid URI. If this route was taken, the extra = information would have to be solicited via a control (and the control = specification would be the document that defines the referral syntax = extension). >Similarly, maybe the 'ref' attribute could be extended to use the label >part of 'labeledURI'. That would probably refer to something local to >the server, though, so I'm not sure if it would be practical to make the >label part of the referral protocol field identical to the label part of >the 'ref' attribute. Yeah, this would have to be coupled with the solution above right? What do = you mean when you say it would refer to something local to the server? It = could potentially contain anything, right (a reference to something, raw = data, a mathematical formula, a SAML assertion, etc). Thanks for the feedback so far. Do you think it would help if I illustrated= some extreme examples of storing stuff on values of the ref attribute, = and contrast that with returning that same kind of stuff in a control, and = further contrast those with returning small (reference data) which would = force the client to make a subsequent read? =20 Jim --=__Part6B4AA1B6.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> = 4/21/04 3:17:17 PM >>>
>Jim Sermersheim writes:
>> = RFC 3296 defines a 'ref' attribute for holding knowledge information.
&g= t;> The format of this is a labeledURI. Each URI holds knowledge = information
>> about another service that can be used to progress = an operation
>> affecting this part of the tree.
>> =
>> We are seeing needs for extra data to be associated with each = remote
>> address (each value of the ref attribute). (...)
>=
>> The question is twofold:
>> 1) What is the = preferred way to represent this type of auxiliary
>> knowledge = information in the directory?
>> 2) What is the preferred way to = represent this type of auxiliary
>> knowledge information in = operations returning a referral (or
>> searchResultReference)?
= >>
>> When using LDAP URLs, one could answer both = questions by stating that
>> the extension part of the URL should = hold all auxiliary data associated
>> with a remote service. This = gets uglier as the amount and complexity of
>> auxiliary data = increases.
>
>What is uglier about it? If much information is = needed, then it must be
>sent somehow anyway. If the point is that = you don't want to repeat all
>that information in many referrals, = then:
Well, I'm sure we all agree that sending an entire entry packed into = a single attribute value would be ugly, sending all the data normally held = in a subtree of entries in this way is even uglier. Even today's representa= tion of schema elements is ugly =97 they would be much more manageable= if they were each objects, where things like MUST and MAY were attributes.= This is basically what I'm talking about.

>For (2) you could define an unsolicited notification which = provides the
>extra information, and must be sent before any = referral which uses it.
>Unless the referral also can be followed = without that information, I
>think the notification should only be = sent if the client has sent an
>extended request which solicits = it.
Heh, a solicited unsolicited notification. This solution seems to = require message synchronization. I think (if we can't place all the data = on each ref attribute) it would be preferable to just put it in a response = control on the message containing the referral (or searchResultReference).<= /DIV>

>The extended request should have an optional field with a = limit of much
>such information the client is willing to cache. The = client may discard
>information on a first-in-first-out basis or = something when the info
>sent from the server exceeds that limit. = Finally, you probably need an
>LDAPURL extension or something which = refers to this information (but see
>below).
>
>> = (relying on the LDAP URL extensions means a similar mechanism must = be
>> defined for future URI types).
>
>Or the = syntaxes of referral and continuation references in the protocol
>cou= ld be extended to e.g. 'URI [SPACE <extra information>]', if = the
>client has sent an extended request which solicits this.
 
I'm thinking that might cause some unwanted effects on existing = clients which only expect a valid URI. If this route was taken, the extra = information would have to be solicited via a control (and the control = specification would be the document that defines the referral syntax = extension).

>Similarly, maybe the 'ref' attribute could be extended to use = the label
>part of 'labeledURI'. That would probably refer to = something local to
>the server, though, so I'm not sure if it would = be practical to make the
>label part of the referral protocol field = identical to the label part of
>the 'ref' attribute.
Yeah, this would have to be coupled with the solution above right? = What do you mean when you say it would refer to something local to the = server? It could potentially contain anything, right (a reference to = something, raw data, a mathematical formula, a SAML assertion, etc).

Thanks for the feedback so far. Do you think it would help if I = illustrated some extreme examples of storing stuff on values of the ref = attribute, and contrast that with returning that same kind of stuff in a = control, and further contrast those with returning small (reference data) = which would force the client to make a subsequent read?
 
Jim
--=__Part6B4AA1B6.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 22 10:39:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01046 for ; Thu, 22 Apr 2004 10:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGf9N-0004ra-Jk; Thu, 22 Apr 2004 10:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGer3-0003Q4-Om for ldapext@optimus.ietf.org; Thu, 22 Apr 2004 10:07:06 -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 KAA28145 for ; Thu, 22 Apr 2004 10:06: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 1BGeqv-0007jd-VJ for ldapext@ietf.org; Thu, 22 Apr 2004 10:06:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGeq6-0007TJ-00 for ldapext@ietf.org; Thu, 22 Apr 2004 10:06:07 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 1BGep8-0007A9-00 for ldapext@ietf.org; Thu, 22 Apr 2004 10:05:06 -0400 Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.20) id 1BGeox-0006mV-Lw; Thu, 22 Apr 2004 16:04:55 +0200 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx4.uio.no with esmtp (Exim 4.30) id 1BGeov-0006aZ-3l; Thu, 22 Apr 2004 16:04:53 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 1BGeou-0000kg-00; Thu, 22 Apr 2004 16:04:52 +0200 From: Hallvard B Furuseth Message-Id: To: Jim Sermersheim Cc: Kurt@OpenLDAP.org, ldapext@ietf.org Subject: Re: [ldapext] 'client/session information' control In-Reply-To: References: X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 22 Apr 2004 16:04:52 +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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Jim Sermersheim writes: > One problem with this approach (controls that affect the session) is the > language in RFC 2251 "Controls which are sent as part of a request apply > only to that request and are not saved." True. I hoped to avoid a request/response roundtrip before the client can send its first Bind/StartTLS, but perhaps not. Besides, there might be setup options which one does not wish an unprotected connection to be able to set up for a protected connection, so maybe Start TLS and SASL Bind should discard some of this information and revert to the default state. OTOH, it would be nice to specify e.g. preferred language for error messages from the first Bind or StartTLS. Maybe both a control and an extended operation could be defined, with the same syntax:-) > For the third example below (refer vs. chain), there is an I-D > (draft-sermersheim-ldap-chaining-02.txt) that deals with it (but on a > per-operation basis). I'll have a look at that. At first glance, a session default seems more convenient to me, though it would be nice to be able to set it per operation too. >>>> "Kurt D. Zeilenga" 4/22/04 12:38:46 AM >>> >At 02:52 PM 4/21/2004, Hallvard B Furuseth wrote: > >> It might be useful to define a request control which describes aspects >> of the client or the session to the server, e.g. > > How does that differ from using separate request controls > (or other existing form of solicitation) where each which > identifies a particular aspect of the client? Mostly it doesn't. Except if we make it an extended operation and not a control: then it will be an advantage to be able to send - and wait for the response to - one operation instead of a whole series of them. But the thing is, people don't seem to define extensions to announce client aspects, or at least not much. Maybe the threshold for defining such extensions is too high, I don't know. An existing framework for announcing client aspects would make that easier, and it might encourage developers to make use of it, instead of just blindly expecting a client to support some extension. Also, such a document would work out e.g. security considerations for setting up sessions defaults, so it would later be easier to get this right when defining some specific session default. For example, a setting should normally be reset after StartTLS. The design of this extension might also encourage other extensions to not be too badly designed, if they try to fit into the framework for this one. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 22 11:56:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07104 for ; Thu, 22 Apr 2004 11:56:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgTe-0006Ez-9Y; Thu, 22 Apr 2004 11:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgLv-00044T-1L for ldapext@optimus.ietf.org; Thu, 22 Apr 2004 11:43: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 LAA06354 for ; Thu, 22 Apr 2004 11:42: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 1BGgLr-0003D6-TC for ldapext@ietf.org; Thu, 22 Apr 2004 11:43:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgKt-0002uu-00 for ldapext@ietf.org; Thu, 22 Apr 2004 11:42:00 -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 1BGgJt-0002TS-00 for ldapext@ietf.org; Thu, 22 Apr 2004 11:40:57 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3MFerMs013390; Thu, 22 Apr 2004 15:40:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040422081224.054fd9c8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 22 Apr 2004 08:40:40 -0700 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] 'client/session information' control Cc: Jim Sermersheim , ldapext@ietf.org 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=AWL autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 07:04 AM 4/22/2004, Hallvard B Furuseth wrote: >But the thing is, people don't seem to define extensions to announce >client aspects, or at least not much. I argue that all most extensions do announce client aspects. For instance, a non-critical paged results control states the client is willing to accept paged results. >Maybe the threshold for defining >such extensions is too high, I don't know. I don't see defining a 'client aspects' control (or whatever) as lowering the bar. One would still need to 'specify' the aspect, and that will involve much of the same steps as 'specifying' a control. The only difference, I think, is structure. >Also, such a document would work out e.g. security considerations for >setting up sessions defaults, But combining the 'aspects' into one control is, aside from making assumptions that each has like security considerations, also limits how the 'aspects' can be used. I would think 'aspects' would be rather independent of each other, so having an mechanism to independently specify them, like in controls, is good. Of course, security considerations that your aspects control, as well as separate 'aspect' controls, would share include those do to the lack of data security protections whilst transferring it as part of a StartTLS or Bind operation. >so it would later be easier to get this >right when defining some specific session default. For example, a >setting should normally be reset after StartTLS. The design of this >extension might also encourage other extensions to not be too badly >designed, if they try to fit into the framework for this one. I see more cons than pros in introducing yet another framework. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 22 12:37:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09141 for ; Thu, 22 Apr 2004 12:37:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGh4R-0002C8-6h; Thu, 22 Apr 2004 12:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGgm3-0003tU-7i for ldapext@optimus.ietf.org; Thu, 22 Apr 2004 12:10: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 MAA07879 for ; Thu, 22 Apr 2004 12:09: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 1BGglz-0002mF-Ov for ldapext@ietf.org; Thu, 22 Apr 2004 12:09:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGgl0-0002XN-00 for ldapext@ietf.org; Thu, 22 Apr 2004 12:08:58 -0400 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1BGgkD-00022s-00 for ldapext@ietf.org; Thu, 22 Apr 2004 12:08:09 -0400 Received: from pearlcrescent.com (pcp05006455pcs.sanarb01.mi.comcast.net[68.40.228.200]) by comcast.net (rwcrmhc11) with SMTP id <20040422160740013004qofoe> (Authid: mcs); Thu, 22 Apr 2004 16:07:40 +0000 Message-ID: <4087EDC3.30109@pearlcrescent.com> Date: Thu, 22 Apr 2004 12:07:31 -0400 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ldapext@ietf.org, h.b.furuseth@usit.uio.no Subject: Re: [ldapext] Complex knowledge information References: In-Reply-To: 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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > > Thanks for the feedback so far. Do you think it would help if I > illustrated some extreme examples of storing stuff on values of the ref > attribute, and contrast that with returning that same kind of stuff in a > control, and further contrast those with returning small (reference > data) which would force the client to make a subsequent read? I'll chime in and say that some examples would help clarify which problems you are trying to address. It seems likely that at some point returning referrals to clients (which in your case are probably other servers or synchronization agents?) is too simplistic of an approach. It may be better for some types of LDAP clients to be able to access the knowledge information as a collection of attributes or subentries (seems like the cleanest approach to me). Standardizing all of this for LDAP would be challenging, although that may or may not be crucial. -- Mark Smith LDAP Book Information: http://www.ldapbook.com/ What's Next: http://www.pearlcrescent.com/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 23 05:03:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23422 for ; Fri, 23 Apr 2004 05:03:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwRe-0000mi-PR; Fri, 23 Apr 2004 04:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGwQW-0000Mt-OB for ldapext@optimus.ietf.org; Fri, 23 Apr 2004 04:52: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 EAA22882 for ; Fri, 23 Apr 2004 04:52:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGwQR-0002ni-DK for ldapext@ietf.org; Fri, 23 Apr 2004 04:52:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGwPY-0002Vr-00 for ldapext@ietf.org; Fri, 23 Apr 2004 04:51:53 -0400 Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx with esmtp (Exim 4.12) id 1BGwOq-0002FX-00 for ldapext@ietf.org; Fri, 23 Apr 2004 04:51:08 -0400 Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id i3N8p5GL001084 for ; Fri, 23 Apr 2004 02:51:06 -0600 From: "Howard Chu" To: Date: Fri, 23 Apr 2004 01:50:08 -0700 Message-ID: <019d01c42910$00172970$1801a8c0@CELLO> 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 CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040421160003.24398.22425.Mailman@www1.ietf.org> Importance: Normal 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 Subject: [ldapext] RE: Complex knowledge information Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > From: "Jim Sermersheim" > All, > > RFC 3296 defines a 'ref' attribute for holding knowledge information. > The format of this is a labeledURI. Each URI holds knowledge > information > about another service that can be used to progress an operation > affecting this part of the tree. > > We are seeing needs for extra data to be associated with each remote > address (each value of the ref attribute). Examples of this include: > > - Authentication information (instructions on how to authenticate to > the remote service) > - Authorization information (assertions regarding the authorization to > be used on the remote service) > - Cost-related information > - Schema mapping information (name mappings, syntax mappings) > - Data transformation rules (especially for URI's pointing to non-LDAP > DSAs) > - Name resolution information (i.e. entryUUID of remote object) > > There is other information that applies to the group of URIs in a > referral, but that's a different thread. > > The question is twofold: > 1) What is the preferred way to represent this type of auxiliary > knowledge information in the directory? > 2) What is the preferred way to represent this type of auxiliary > knowledge information in operations returning a referral (or > searchResultReference)? I think the answers depend a great deal on the actual usage scenarios. In particular, it depends on whether the first server's referral points to another trusted/local server, or if it points to a foreign/unknown server. I suppose if you know enough about the remote server to have schema mapping, data transformation, and name resolution information, then you probably know a fair amount of other things about it too. In the case of trusted/cooperating servers, my preference is for the server to maintain all of this information internally, chain the queries, and return the mapped results to the client transparently. In this case, authentication/authorization is also handled by the chaining server. In the case of a foreign/untrusted server, generally it would be inappropriate for the local server to automatically tell the client anything about how to authenticate/authorize. Probably not a very useful reply, but that's how I see things at the moment. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 23 12:04:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16630 for ; Fri, 23 Apr 2004 12:04:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2uI-0005bD-PV; Fri, 23 Apr 2004 11:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH2kq-0003V2-Li for ldapext@optimus.ietf.org; Fri, 23 Apr 2004 11:38: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 LAA15256 for ; Fri, 23 Apr 2004 11:38: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 1BH2kp-0001sW-Jl for ldapext@ietf.org; Fri, 23 Apr 2004 11:38:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH2jy-0001dA-00 for ldapext@ietf.org; Fri, 23 Apr 2004 11:37:23 -0400 Received: from d17-116.dsl.easysurfnet.de ([83.121.17.116] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1BH2jF-0001Da-00 for ldapext@ietf.org; Fri, 23 Apr 2004 11:36:37 -0400 Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 2052B59A93; Fri, 23 Apr 2004 16:58:32 +0200 (CEST) Message-ID: <40892F18.7060308@stroeder.com> Date: Fri, 23 Apr 2004 16:58:32 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Howard Chu Cc: ldapext@ietf.org References: <019d01c42910$00172970$1801a8c0@CELLO> In-Reply-To: <019d01c42910$00172970$1801a8c0@CELLO> 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 Subject: [ldapext] Authentication information in LDAP URLs (was: Complex knowledge information) Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Howard Chu wrote: >> >>- Authentication information (instructions on how to authenticate to >>the remote service) > > In the case of a foreign/untrusted server, generally it would be > inappropriate for the local server to automatically tell the client anything > about how to authenticate/authorize. Since most times I have the client-side view I'd like to focus on authentication information in LDAP URLs. Are there any client implementations out there using the bindname extension of LDAP URLs? If yes, how do they treat it? My web2ldap simply presents a login form asking for the credential (password) for this bind DN. Are there any server implementations setting bindname extension in a referral LDAP URL? How should a client treat such a referral URL? Now if a LDAP server would sent back a referral with bindname extension set in the referral URL I would simply act the same way as described above: Present a login form to the user before following the referral. Any security considerations? Furthermore I'd also like to have a mechanism like that for specifying SASL related authentication information in a LDAP URL: - StartTLS ext. op. SHOULD/MUST be used - SASL authc ID - SASL authz ID - SASL realm - SASL mechanism I can easily use LDAP URL extensions for these off course but what do the list members here think about this approach? Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 23 19:39:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22442 for ; Fri, 23 Apr 2004 19:39:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHACH-0008IT-FO; Fri, 23 Apr 2004 19:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHA4x-0005tR-B1 for ldapext@optimus.ietf.org; Fri, 23 Apr 2004 19:27: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 TAA21943 for ; Fri, 23 Apr 2004 19:27:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHA4v-0007jd-Ip for ldapext@ietf.org; Fri, 23 Apr 2004 19:27:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHA44-0007UR-00 for ldapext@ietf.org; Fri, 23 Apr 2004 19:26:36 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BHA3P-0007D0-00 for ldapext@ietf.org; Fri, 23 Apr 2004 19:25:55 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 23 Apr 2004 17:25:25 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 23 Apr 2004 17:24:36 -0600 From: "Jim Sermersheim" To: , Subject: [ldapext] RE: Complex knowledge information 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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>> "Howard Chu" < hyc@highlandsun.com > 4/23/04 2:50:08 AM >>> >I think the answers depend a great deal on the actual usage scenarios. In >particular, it depends on whether the first server's referral points to >another trusted/local server, or if it points to a foreign/unknown server. I >suppose if you know enough about the remote server to have schema mapping, >data transformation, and name resolution information, then you probably know >a fair amount of other things about it too. Yes, even the trust relationship you describe is an example of the aux data that needs to be stored on a per--ref value basis. Rather than storing the data on each instance of a ref value which points to say openldap.org:389, the ref value could be augmented to point to an entry which holds the relationship (and other) data for that server. This works for data that is general to a remote DSA, but something different is needed if the information is tied somehow to a specific naming context on that DSA. >In the case of trusted/cooperating servers, my preference is for the server >to maintain all of this information internally, chain the queries, and return >the mapped results to the client transparently. In this case, >authentication/authorization is also handled by the chaining server. Right, if the chaining server (say DSA1) is in a chaining mode, it will (hopefully) return results (not referrals) to the client that look like they came from DSA1. But someone had to confugure the infomation needed for DSA1 to chain to (say DSA2). That data could be configured using the extension information on the ref URI, or in some other way. So one part of my original question was: where should this information be stored? If I pick a methodology of doing this without consulting others, my way will likely not become the standard way, and people implementing management tools will have one more LDAP inconsistency to deal with. >In the case of a foreign/untrusted server, generally it would be >inappropriate for the local server to automatically tell the client anything >about how to authenticate/authorize. > >Probably not a very useful reply, but that's how I see things at the moment. Actually it is useful. What I'm trying to do is to define things such that they work the same regardless of whether we're dealing with: - a referral being passed back to the client - a referral being passed back from one DSA to another (while chaining) - a referral being passed from one DSA process to another (findDSEProcedure returning to the searchProcedure) Whether any or all of the extra information is passed during these steps does depend on access control and solicitation. The former (access control) makes a case against placing all the information on the each ref URI as I don't think many server implementations allow ACI to identify parts of a value. Currently, what you get in a referral is pretty much what you manage on the reference object (though sometimes the DN part is generated). So part of me wants to continue with that paradigm, but another part of me thinks doing so will lead to an ugly, bloated mess. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Apr 23 20:05:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23974 for ; Fri, 23 Apr 2004 20:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAaT-0007Xk-BG; Fri, 23 Apr 2004 20:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHAXr-0006ef-5e for ldapext@optimus.ietf.org; Fri, 23 Apr 2004 19:57: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 TAA23434 for ; Fri, 23 Apr 2004 19:57: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 1BHAXp-0007VW-Cf for ldapext@ietf.org; Fri, 23 Apr 2004 19:57:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHAWq-0007GD-00 for ldapext@ietf.org; Fri, 23 Apr 2004 19:56:22 -0400 Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx with esmtp (Exim 4.12) id 1BHAVy-0006nY-00 for ldapext@ietf.org; Fri, 23 Apr 2004 19:55:26 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 23 Apr 2004 17:54:57 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Fri, 23 Apr 2004 17:54:01 -0600 From: "Jim Sermersheim" To: , Cc: Subject: Re: [ldapext] Authentication information in LDAP URLs (was: Complex knowledge information) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part84A54089.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,HTML_MESSAGE autolearn=no version=2.60 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , 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. --=__Part84A54089.1__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a good example of the problem space I'm trying to address. The = only difference is that I'm dealing with different types of "clients". = When chaining a request from DSA1 to DSA2, DSA1 is also a client of sorts, = and may need to know how to authN to DSA2. If DSA2 returns a referral back = to DSA1, where the referral points to DSAS3, again, DSA1 might need to = know how to authN to DSA3. Another small example is TLS. Say the DUA gets a referral from DSA1 to = DSA2. The DUA has never been configured with the public key of DSA2. We = could configure DSA1 to return the public key of DSA2 when returning a = referral. =20 In terms of the format of the referral response, there seem to be two = choices in how this could be done: 1) The DUA asks (via a control) for this (public key) information to be = returned in a response control when referrals are sent. What's ugly here = is when there are multiple referral values. The response control would = have to have a way of associating the public keys with the referral = values. 1.1) Alternately, the referral could contain a dummy referral value (or = just return with a different result code, and include no referral at all), = and the response control would contain structured data where each referral = is associated with a set of data). 2) DSA1 (perhaps only if solicited) places the entire public key (base64 = encoded) in an extension on the ref URI. =20 In terms of placement of this information, it could be stored exactly the = way it is sent in #2 above, or it could be stored in a number of other = ways * each of which would have to define a way to associate the ref URI = to the public key. =20 What I'm trying to get a sense of is whether a continuation of using = values of the ref URI for both the management and instructional parts of = referrals is preferred over breaking things up into more atomic units. =20 I think I prefer breaking it up, and using solution 1.1 above. It actually = solves other issues as well * for example, consider the X.518 CrossReferece= . It is (when broken down) a contextPrefix, and a list (possibly) of = addresses. Today, if we have 10 ref values on a reference object, and if = the DSA is returning a search result reference due to it, the DSA must = augment all 10 values by adding the proper DN to each. A more structured = referral could contain a targetObject field, and one or more sequences of = { address, overriding target, authN Info, mapping info, etc }. =20 Sorry Michael, I didn't answer any of your questions. =20 Jim >>> Michael Str=F6der 4/23/04 8:58:32 AM >>> Howard Chu wrote: >> >>- Authentication information (instructions on how to authenticate to >>the remote service) >=20 > In the case of a foreign/untrusted server, generally it would be > inappropriate for the local server to automatically tell the client = anything > about how to authenticate/authorize. Since most times I have the client-side view I'd like to focus on=20 authentication information in LDAP URLs. Are there any client implementations out there using the bindname = extension=20 of LDAP URLs? If yes, how do they treat it? My web2ldap simply presents = a=20 login form asking for the credential (password) for this bind DN. Are there any server implementations setting bindname extension in a=20 referral LDAP URL? How should a client treat such a referral URL? Now if a LDAP server would sent back a referral with bindname extension = set=20 in the referral URL I would simply act the same way as described above:=20 Present a login form to the user before following the referral. Any security considerations? Furthermore I'd also like to have a mechanism like that for specifying = SASL=20 related authentication information in a LDAP URL: - StartTLS ext. op. SHOULD/MUST be used - SASL authc ID - SASL authz ID - SASL realm - SASL mechanism I can easily use LDAP URL extensions for these off course but what do = the=20 list members here think about this approach? Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 --=__Part84A54089.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is a good example of the problem space I'm trying to address. = The only difference is that I'm dealing with different types of "clients". = When chaining a request from DSA1 to DSA2, DSA1 is also a client of sorts, = and may need to know how to authN to DSA2. If DSA2 returns a referral back = to DSA1, where the referral points to DSAS3, again, DSA1 might need to = know how to authN to DSA3.
Another small example is TLS. Say the DUA gets a referral from DSA1 = to DSA2. The DUA has never been configured with the public key of DSA2. We = could configure DSA1 to return the public key of DSA2 when returning a = referral.
 
In terms of the format of the referral response, there seem to be two = choices in how this could be done:
1) The DUA asks (via a control) for this (public key) information to = be returned in a response control when referrals are sent. What's ugly = here is when there are multiple referral values. The response control = would have to have a way of associating the public keys with the referral = values.
1.1) Alternately, the referral could contain a dummy referral value = (or just return with a different result code, and include no referral at = all), and the response control would contain structured data where each = referral is associated with a set of data).
2) DSA1 (perhaps only if solicited) places the entire public key = (base64 encoded) in an extension on the ref URI.
 
In terms of placement of this information, it could be stored = exactly the way it is sent in #2 above, or it could be stored in a number = of other ways =97 each of which would have to define a way to associate = the ref URI to the public key.
 
What I'm trying to get a sense of is whether a continuation of using = values of the ref URI for both the management and instructional parts of = referrals is preferred over breaking things up into more atomic units.
 
I think I prefer breaking it up, and using solution 1.1 above. It = actually solves other issues as well =97 for example, consider the X.518 = CrossReferece. It is (when broken down) a contextPrefix, and a list = (possibly) of addresses. Today, if we have 10 ref values on a reference = object, and if the DSA is returning a search result reference due to it, = the DSA must augment all 10 values by adding the proper DN to each. A more = structured referral could contain a targetObject field, and one or more = sequences of { address, overriding target, authN Info, mapping info, etc = }.
 
Sorry Michael, I didn't answer any of your questions.
 
Jim

>>> Michael Str=F6der <michael@stroeder.com> = 4/23/04 8:58:32 AM >>>
Howard Chu wrote:
>>
>>= ;- Authentication information (instructions on how to authenticate = to
>>the remote service)
>
> In the case of a = foreign/untrusted server, generally it would be
> inappropriate for = the local server to automatically tell the client anything
> about = how to authenticate/authorize.

Since most times I have the = client-side view I'd like to focus on
authentication information in = LDAP URLs.

Are there any client implementations out there using the = bindname extension
of LDAP URLs? If yes, how do they treat it? My = web2ldap simply presents a
login form asking for the credential = (password) for this bind DN.

Are there any server implementations = setting bindname extension in a
referral LDAP URL? How should a client = treat such a referral URL?

Now if a LDAP server would sent back a = referral with bindname extension set
in the referral URL I would = simply act the same way as described above:
Present a login form to = the user before following the referral.

Any security considerations?=

Furthermore I'd also like to have a mechanism like that for = specifying SASL
related authentication information in a LDAP URL:
- = StartTLS ext. op. SHOULD/MUST be used
- SASL authc ID
- SASL authz = ID
- SASL realm
- SASL mechanism

I can easily use LDAP URL = extensions for these off course but what do the
list members here = think about this approach?

Ciao, Michael.

___________________= ____________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/= ldapext
--=__Part84A54089.1__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Apr 27 17:38:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03522 for ; Tue, 27 Apr 2004 17:38:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIaDI-00076w-MV; Tue, 27 Apr 2004 17:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIQh5-0000aO-FY for ldapext@optimus.ietf.org; Tue, 27 Apr 2004 07:24: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 HAA23089 for ; Tue, 27 Apr 2004 07:24: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 1BIQh0-0001Ge-SX for ldapext@ietf.org; Tue, 27 Apr 2004 07:24:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIQft-0000qr-00 for ldapext@ietf.org; Tue, 27 Apr 2004 07:22:54 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1BIQe8-0000FS-00 for ldapext@ietf.org; Tue, 27 Apr 2004 07:21:04 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i3RBKSo8009140; Tue, 27 Apr 2004 13:20:28 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i3RBKQuo029047; Tue, 27 Apr 2004 13:20:26 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 27 Apr 2004 13:20:26 +0200 From: Stig Venaas To: Michael =?iso-8859-1?Q?Str=F6der?= Cc: Howard Chu , ldapext@ietf.org Subject: Re: [ldapext] Authentication information in LDAP URLs (was: Complex knowledge information) Message-ID: <20040427112026.GE28861@sverresborg.uninett.no> References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <40892F18.7060308@stroeder.com> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tyholt.uninett.no id i3RBKSo8009140 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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2004 at 04:58:32PM +0200, Michael Str=F6der wrote: > Howard Chu wrote: > >> > >>- Authentication information (instructions on how to authenticate to > >>the remote service) > > > >In the case of a foreign/untrusted server, generally it would be > >inappropriate for the local server to automatically tell the client=20 > >anything > >about how to authenticate/authorize. >=20 > Since most times I have the client-side view I'd like to focus on=20 > authentication information in LDAP URLs. >=20 > Are there any client implementations out there using the bindname exten= sion=20 > of LDAP URLs? If yes, how do they treat it? My web2ldap simply presents= a=20 > login form asking for the credential (password) for this bind DN. I have an LDAP application where I use LDAP URL for configuring server, search base etc. but also bindname and x-bindpw. I found several other applications (including web2ldap if I remember correctly) that supports x-bindpw. I think it's convenient to have an LDAP URL in the configu- ration file of my client containing all the LDAP related parameters. As for security, it doesn't really matter if a plain text password is part of the URL or configured separately since the URL is never exposed anywhere else. I would be much more concerned about referrals. Is anyone else interested in standardizing bindpw, there are lots of implementations and also an old internet draft mentioning it. Do a google search for "x-bindpw" and you will find a lot. Would some other name be appropriate? Something that can be used with different types of credentials for different authentication schemes? Stig _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Apr 27 18:20:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06553 for ; Tue, 27 Apr 2004 18:20:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIam9-0000St-Na; Tue, 27 Apr 2004 18:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIacj-0003KT-Jf for ldapext@optimus.ietf.org; Tue, 27 Apr 2004 18:00: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 SAA04513 for ; Tue, 27 Apr 2004 18:00:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIace-00015E-EO for ldapext@ietf.org; Tue, 27 Apr 2004 18:00:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIabk-0000xp-00 for ldapext@ietf.org; Tue, 27 Apr 2004 17:59:17 -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 1BIaar-0000q2-00 for ldapext@ietf.org; Tue, 27 Apr 2004 17:58:21 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3RLwFMs030609; Tue, 27 Apr 2004 21:58:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 27 Apr 2004 14:58:15 -0700 To: Stig Venaas From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Authentication information in LDAP URLs (was: Complex knowledge information) Cc: Michael =?iso-8859-1?Q?Str=F6der?= , Howard Chu , ldapext@ietf.org In-Reply-To: <20040427112026.GE28861@sverresborg.uninett.no> References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 04:20 AM 4/27/2004, Stig Venaas wrote: >On Fri, Apr 23, 2004 at 04:58:32PM +0200, Michael Str=F6der wrote: >> Howard Chu wrote: >> >> >> >>- Authentication information (instructions on how to authenticate to >> >>the remote service) >> > >> >In the case of a foreign/untrusted server, generally it would be >> >inappropriate for the local server to automatically tell the client=20 >> >anything >> >about how to authenticate/authorize. >>=20 >> Since most times I have the client-side view I'd like to focus on=20 >> authentication information in LDAP URLs. >>=20 >> Are there any client implementations out there using the bindname= extension=20 >> of LDAP URLs? If yes, how do they treat it? My web2ldap simply presents a= =20 >> login form asking for the credential (password) for this bind DN. > >I have an LDAP application where I use LDAP URL for configuring server, >search base etc. but also bindname and x-bindpw. I found several other >applications (including web2ldap if I remember correctly) that supports >x-bindpw. I think it's convenient to have an LDAP URL in the configu- >ration file of my client containing all the LDAP related parameters. >As for security, it doesn't really matter if a plain text password is >part of the URL or configured separately since the URL is never exposed >anywhere else. I'd argue that there are security considerations here. I don't think it wise to assume all URL handlers will understand and recongize and treat appropriately an LDAP URL which happens to contain an extension (standardized or not) a password field. In note that LDAPBIS had concerns with bindname not be recognized (let alone supported) by all implementations and axed it from the revised technical specification. >I would be much more concerned about referrals. > >Is anyone else interested in standardizing bindpw, Well, given that bindpw is about to be un-standardized, I see little point it trying to standardize bindpw. I also think there would be significant resistance to standardizing bindpw without like mechanisms to support LDAP's mandatory-to-implement strong authentication mechanism (SASL/DIGEST-MD5) and Start TLS (which needs to be implemented if one supports simple password authentication). Personally, I cringe at the thought of placing authentication information into the locator. Kurt >there are lots of >implementations and also an old internet draft mentioning it. Do a >google search for "x-bindpw" and you will find a lot. Would some >other name be appropriate? Something that can be used with different >types of credentials for different authentication schemes? > >Stig > >_______________________________________________ >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-admin@ietf.org Wed Apr 28 08:02:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09391 for ; Wed, 28 Apr 2004 08:02:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInNC-0007w7-TT; Wed, 28 Apr 2004 07:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIkmA-0008Cg-VH for ldapext@optimus.ietf.org; Wed, 28 Apr 2004 04:50: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 EAA01225 for ; Wed, 28 Apr 2004 04:50: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 1BIkm5-00015K-Sg for ldapext@ietf.org; Wed, 28 Apr 2004 04:50:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIklA-0000sE-00 for ldapext@ietf.org; Wed, 28 Apr 2004 04:49:40 -0400 Received: from du-005-066.access.de.clara.net ([212.82.228.66] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1BIkkT-0000RU-00 for ldapext@ietf.org; Wed, 28 Apr 2004 04:48:58 -0400 Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 05D0E56AE3; Wed, 28 Apr 2004 09:31:14 +0200 (CEST) Message-ID: <408F5DC1.3000501@stroeder.com> Date: Wed, 28 Apr 2004 09:31:13 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: [ldapext] Authentication information in LDAP URLs References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> 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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: >> > In note that LDAPBIS had concerns with bindname not be > recognized (let alone supported) by all implementations > and axed it from the revised technical specification. Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) bindname extension should be left in LDAP URL specification since there are existing applications deploying it. web2ldap and various of my custom software are using it based on the ldapurl.LDAPUrl class in python-ldap. Off course there are security considerations with credentials in LDAP URLs. I generally do not recommend putting credentials in LDAP URLs. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Apr 28 09:00:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13132 for ; Wed, 28 Apr 2004 09:00:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIoZg-0006R7-50; Wed, 28 Apr 2004 08:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BInRq-0000aa-E0 for ldapext@optimus.ietf.org; Wed, 28 Apr 2004 07:41:59 -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 HAA07737 for ; Wed, 28 Apr 2004 07:41:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BInRp-0004iZ-LV for ldapext@ietf.org; Wed, 28 Apr 2004 07:41:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BInQw-0004S6-00 for ldapext@ietf.org; Wed, 28 Apr 2004 07:40:59 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx with esmtp (Exim 4.12) id 1BInQI-00046q-00 for ldapext@ietf.org; Wed, 28 Apr 2004 07:40:19 -0400 Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 28 Apr 2004 12:38:46 +0100 Message-ID: <408F97C5.20808@isode.com> Date: Wed, 28 Apr 2004 12:38:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= CC: Howard Chu , ldapext@ietf.org Subject: Re: [ldapext] Authentication information in LDAP URLs References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> In-Reply-To: <40892F18.7060308@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Encoded: Changed encoding from 8bit for 7bit transmission X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Michael Str=F6der wrote: > Furthermore I'd also like to have a mechanism like that for specifying = > SASL related authentication information in a LDAP URL: > a) StartTLS ext. op. SHOULD/MUST be used > b) SASL authc ID > c) SASL authz ID > d) SASL realm > e) SASL mechanism Sounds like a good idea to me. If you want to design something that is consistent with other protocols, = have a look at RFC 2192 (IMAP URL), section 3. It can deal with b) and e). d). has limited applicability (basically for DIGEST-MD5). Having a) and = c) would be nice too. > I can easily use LDAP URL extensions for these off course but what do = > the list members here think about this approach? = Adding this as an LDAP URL extension seems like a less intrusive change. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ = _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Apr 28 11:24:12 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21221 for ; Wed, 28 Apr 2004 11:24:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqlS-0007Rc-9U; Wed, 28 Apr 2004 11:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIl2g-0001N2-3b for ldapext@optimus.ietf.org; Wed, 28 Apr 2004 05:07:46 -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 FAA01794 for ; Wed, 28 Apr 2004 05:07:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIl2a-00052U-QP for ldapext@ietf.org; Wed, 28 Apr 2004 05:07:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIl1d-0004p7-00 for ldapext@ietf.org; Wed, 28 Apr 2004 05:06:42 -0400 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1BIl16-0004aY-00 for ldapext@ietf.org; Wed, 28 Apr 2004 05:06:08 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i3S95do8026892; Wed, 28 Apr 2004 11:05:40 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i3S95ROt031143; Wed, 28 Apr 2004 11:05:27 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 28 Apr 2004 11:05:27 +0200 From: Stig Venaas To: Michael =?iso-8859-1?Q?Str=F6der?= Cc: "Kurt D. Zeilenga" , ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: [ldapext] Authentication information in LDAP URLs Message-ID: <20040428090527.GA31120@sverresborg.uninett.no> References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> <408F5DC1.3000501@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <408F5DC1.3000501@stroeder.com> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tyholt.uninett.no id i3S95do8026892 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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Wed, Apr 28, 2004 at 09:31:13AM +0200, Michael Str=F6der wrote: > Kurt D. Zeilenga wrote: > >> > >In note that LDAPBIS had concerns with bindname not be > >recognized (let alone supported) by all implementations > >and axed it from the revised technical specification. >=20 > Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) >=20 > bindname extension should be left in LDAP URL specification since there= are=20 > existing applications deploying it. web2ldap and various of my custom=20 > software are using it based on the ldapurl.LDAPUrl class in python-ldap. >=20 > Off course there are security considerations with credentials in LDAP U= RLs.=20 > I generally do not recommend putting credentials in LDAP URLs. Agree with all of this, I'm using bindname too. That bindname is in the specification, doesn't require it to be implemented. At least as I understand it. And those depending on it, should mark it as critical when using it. So I don't understand why it should be axed just because many implementations don't use it. There are still many that do. Even though I see some good uses for credentials in URLs, I would not generally recommend it. And I must confess that it's a danger an URL used in one context might be used in another. There's some danger that credentials are used in a perfectly safe context, but that the URL leaks... Stig _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Apr 28 17:26:10 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23520 for ; Wed, 28 Apr 2004 17:26:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwFm-0000W3-B8; Wed, 28 Apr 2004 17:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIux0-0004kP-8P for ldapext@optimus.ietf.org; Wed, 28 Apr 2004 15:42: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 PAA11820 for ; Wed, 28 Apr 2004 15:42: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 1BIuwx-0002JD-Cv for ldapext@ietf.org; Wed, 28 Apr 2004 15:42:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuw9-0002Fw-00 for ldapext@ietf.org; Wed, 28 Apr 2004 15:41:41 -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 1BIuvc-0002CU-00 for ldapext@ietf.org; Wed, 28 Apr 2004 15:41:08 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3SJf3Ms048791; Wed, 28 Apr 2004 19:41:03 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040428115445.04ba9290@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 28 Apr 2004 12:41:04 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Authentication information in LDAP URLs Cc: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org In-Reply-To: <408F5DC1.3000501@stroeder.com> References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> <408F5DC1.3000501@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 12:31 AM 4/28/2004, Michael Str=F6der wrote: >Kurt D. Zeilenga wrote: >>In note that LDAPBIS had concerns with bindname not be >>recognized (let alone supported) by all implementations >>and axed it from the revised technical specification. > >Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) My categorization of the LDAPBIS WG discussions may be poor simplification. Maybe a better simple categorization would to be to say that the WG recognized that there were a number of thorny technical issues with this feature and the WG choose not to tackle them. Additionally, there were (and still are) implementation report issues with regard to this feature. As the feature uses an extension mechanism and should be Elective as well as truly optional, it is recognized that the specification for this feature, like many other extensions, can be separately documented and separately progressed from the LDAP 'core' technical specification. Given this, and the lateness of this concern, I will not entertain (at this time) the question of whether the specification of this feature should or should not be reincorporated into the 'core' specification. Instead, I encourage you, and others who may believe a new specification of this feature should be progressed, to engineer, on an individual basis, an Internet Draft containing such. Kurt, LDAPBIS co-chair=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 29 03:13:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09843 for ; Thu, 29 Apr 2004 03:13:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5dN-0000CQ-F6; Thu, 29 Apr 2004 03:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5XU-0007F3-4G for ldapext@optimus.ietf.org; Thu, 29 Apr 2004 03:00:56 -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 DAA09398 for ; Thu, 29 Apr 2004 03:00:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ5XN-0000xt-0D for ldapext@ietf.org; Thu, 29 Apr 2004 03:00:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5WN-0000ph-00 for ldapext@ietf.org; Thu, 29 Apr 2004 02:59:48 -0400 Received: from du-006-198.access.de.clara.net ([212.82.229.198] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ5VP-0000V1-00 for ldapext@ietf.org; Thu, 29 Apr 2004 02:58:47 -0400 Received: from stroeder.com (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id F32608EB54; Thu, 29 Apr 2004 07:55:57 +0200 (CEST) Message-ID: <409098ED.7090500@stroeder.com> Date: Thu, 29 Apr 2004 07:55:57 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org Subject: Re: [ldapext] Authentication information in LDAP URLs References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> <408F5DC1.3000501@stroeder.com> <6.0.1.1.0.20040428115445.04ba9290@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040428115445.04ba9290@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Kurt D. Zeilenga wrote: > At 12:31 AM 4/28/2004, Michael Str=F6der wrote: >=20 >>Kurt D. Zeilenga wrote: >> >>>In note that LDAPBIS had concerns with bindname not be >>>recognized (let alone supported) by all implementations >>>and axed it from the revised technical specification. >> >>Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) >=20 > As the feature uses an extension mechanism and should be > Elective as well as truly optional, it is recognized > that the specification for this feature, like many other > extensions, can be separately documented and separately > progressed from the LDAP 'core' technical specification. But with removing bindname extension from draft-ietf-ldapbis-url LDAPBIS = WG=20 breaks existing LDAPv3 implementations. This is a strong contradiction to= =20 the goal of LDAPBIS WG (as you wrote on LDAPBIS mailing list many many ti= mes). > Given this, and the lateness of this concern, I will not > entertain (at this time) the question of whether the > specification of this feature should or should not be > reincorporated into the 'core' specification. I strongly disagree here! You're violating the goal of LDAPBIS not to bre= ak=20 existing LDAPv3 implementations. Note that bindname extensions in RFC2255 was just LDAP URL syntax, no=20 semantics were described there. Which is ok IMO. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Apr 29 10:19:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04629 for ; Thu, 29 Apr 2004 10:19:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC3Q-0002CF-0S; Thu, 29 Apr 2004 09:58:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBvk-0008NI-4l for ldapext@optimus.ietf.org; Thu, 29 Apr 2004 09:50: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 JAA01995 for ; Thu, 29 Apr 2004 09:50: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 1BJBvZ-0004JJ-7q for ldapext@ietf.org; Thu, 29 Apr 2004 09:50:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBub-00044P-00 for ldapext@ietf.org; Thu, 29 Apr 2004 09:49:13 -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 1BJBtf-0003ou-00 for ldapext@ietf.org; Thu, 29 Apr 2004 09:48:15 -0400 Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.10) with ESMTP id i3TDmBMs064201; Thu, 29 Apr 2004 13:48:17 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040429063551.0497acd8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 29 Apr 2004 06:48:11 -0700 To: Michael =?iso-8859-1?Q?Str=F6der?= From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Authentication information in LDAP URLs Cc: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org In-Reply-To: <409098ED.7090500@stroeder.com> References: <019d01c42910$00172970$1801a8c0@CELLO> <40892F18.7060308@stroeder.com> <20040427112026.GE28861@sverresborg.uninett.no> <6.0.1.1.0.20040427144615.04a50128@127.0.0.1> <408F5DC1.3000501@stroeder.com> <6.0.1.1.0.20040428115445.04ba9290@127.0.0.1> <409098ED.7090500@stroeder.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable At 10:55 PM 4/28/2004, Michael Str=F6der wrote: >Kurt D. Zeilenga wrote: >>At 12:31 AM 4/28/2004, Michael Str=F6der wrote: >>>Kurt D. Zeilenga wrote: >>>>In note that LDAPBIS had concerns with bindname not be >>>>recognized (let alone supported) by all implementations >>>>and axed it from the revised technical specification. >>>Uuuh? (Cc:-ed ietf-ldapbis@OpenLDAP.org) >>As the feature uses an extension mechanism and should be >>Elective as well as truly optional, it is recognized >>that the specification for this feature, like many other >>extensions, can be separately documented and separately >>progressed from the LDAP 'core' technical specification. > >But with removing bindname extension from draft-ietf-ldapbis-url LDAPBIS WG= breaks existing LDAPv3 implementations. No it doesn't. draft-ietf-ldapbis-url allows extensions such as bindname, it just doesn't specify them. bindname is still specified in RFC 2255. Publication of draft-ietf-ldapbis-url will mean that the current specification of bindname is Historic until a separate specification of bindname is progressed. Such reorganization doesn't 'break' any existing implementation, nor even cause any implementation to be non-conformant. It just means these implementation support a separately defined LDAP URL extension. >This is a strong contradiction to the goal of LDAPBIS WG (as you wrote on= LDAPBIS mailing list many many times). I disagree. The goal of this WG, as detailed in the charter, is to engineer an LDAPv3 "core" technical specification suitable for progression to Draft Standard. This has and will involve reorganization of the technical specification, including pushing some features out of the 'core' specification. This has been discussed many times, including during our chartering process and as we undertook previous reorganizations which 'removed' specifications of certain features from the 'core'). >>Given this, and the lateness of this concern, I will not >>entertain (at this time) the question of whether the >>specification of this feature should or should not be >>reincorporated into the 'core' specification. > >I strongly disagree here! You're violating the goal of LDAPBIS not to break= existing LDAPv3 implementations. See above. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext