From mailman-owner@ietf.org Thu Aug 1 06:28:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19824 for ; Thu, 1 Aug 2002 06:28:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16666 for ; Thu, 1 Aug 2002 06:29:33 -0400 (EDT) Date: Thu, 1 Aug 2002 06:29:33 -0400 (EDT) Message-Id: <200208011029.GAA16666@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ldapext-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ldapext-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ldapext-archive@lists.ietf.org: List Password // URL ---- -------- ldapext@ietf.org LxAC https://www1.ietf.org/mailman/options/ldapext/ldapext-archive@lists.ietf.org From ldapext-admin@ietf.org Mon Aug 5 06:07:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06536 for ; Mon, 5 Aug 2002 06:07:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22403; Mon, 5 Aug 2002 06:03:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22365 for ; Mon, 5 Aug 2002 06:03:16 -0400 (EDT) Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06421 for ; Mon, 5 Aug 2002 06:02:04 -0400 (EDT) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 17behm-0001sL-00 for ldapext@ietf.org; Mon, 5 Aug 2002 12:03:14 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 17behm-0001zy-00 for ldapext@ietf.org; Mon, 5 Aug 2002 12:03:14 +0200 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org Date: Mon, 5 Aug 2002 12:03:14 +0200 Subject: [ldapext] ACL model draft? Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org What happened to draft-ietf-ldapext-acl-model-*.txt? -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 6 07:17:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04324 for ; Tue, 6 Aug 2002 07:17:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21393; Tue, 6 Aug 2002 07:15:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21360 for ; Tue, 6 Aug 2002 07:15:09 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03921; Tue, 6 Aug 2002 07:13:51 -0400 (EDT) Message-Id: <200208061113.HAA03921@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 06 Aug 2002 07:13:51 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-features-04.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Feature Discovery in LDAP Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-features-04.txt Pages : 5 Date : 05-Aug-02 The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-features-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-features-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-features-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-features-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-features-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132519.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 6 07:17:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04380 for ; Tue, 6 Aug 2002 07:17:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21851; Tue, 6 Aug 2002 07:15:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21816 for ; Tue, 6 Aug 2002 07:15:50 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04078; Tue, 6 Aug 2002 07:14:30 -0400 (EDT) Message-Id: <200208061114.HAA04078@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 06 Aug 2002 07:14:30 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-subentry-06.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Subentries in LDAP Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-subentry-06.txt Pages : 12 Date : 05-Aug-02 In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with Lightweight Directory Access Protocol (LDAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-subentry-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-subentry-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-subentry-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-subentry-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132703.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 6 07:20:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04561 for ; Tue, 6 Aug 2002 07:20:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21423; Tue, 6 Aug 2002 07:15:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21394 for ; Tue, 6 Aug 2002 07:15:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03937; Tue, 6 Aug 2002 07:13:56 -0400 (EDT) Message-Id: <200208061113.HAA03937@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 06 Aug 2002 07:13:55 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-authzid-07.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP 'Who am I?' Operation Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-authzid-07.txt Pages : 7 Date : 05-Aug-02 This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity which the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP 'Who am I?' operation A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-authzid-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-authzid-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-authzid-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-authzid-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-authzid-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132545.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 6 07:20:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04581 for ; Tue, 6 Aug 2002 07:20:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21509; Tue, 6 Aug 2002 07:15:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21475 for ; Tue, 6 Aug 2002 07:15:21 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03970; Tue, 6 Aug 2002 07:14:05 -0400 (EDT) Message-Id: <200208061114.HAA03970@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 06 Aug 2002 07:14:05 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-t-f-03.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP True/False Filters Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-t-f-03.txt Pages : 5 Date : 05-Aug-02 This document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-t-f-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-t-f-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-t-f-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-t-f-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-t-f-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132610.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 6 07:21:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04624 for ; Tue, 6 Aug 2002 07:21:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21631; Tue, 6 Aug 2002 07:15:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21598 for ; Tue, 6 Aug 2002 07:15:33 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04007; Tue, 6 Aug 2002 07:14:15 -0400 (EDT) Message-Id: <200208061114.HAA04007@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 06 Aug 2002 07:14:15 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-adlist-02.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3: Requesting Attributes by Object Class Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-adlist-02.txt Pages : 5 Date : 05-Aug-02 The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, or attributes selected by their description. This document extends LDAP to provide a mechanism for LDAP clients to request the return of all attributes of an object class. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-adlist-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-adlist-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-adlist-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-adlist-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-adlist-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132630.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 6 07:22:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04737 for ; Tue, 6 Aug 2002 07:22:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21556; Tue, 6 Aug 2002 07:15:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21525 for ; Tue, 6 Aug 2002 07:15:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03987; Tue, 6 Aug 2002 07:14:10 -0400 (EDT) Message-Id: <200208061114.HAA03987@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 06 Aug 2002 07:14:10 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-opattrs-04.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3: All Operational Attributes Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-opattrs-04.txt Pages : 5 Date : 05-Aug-02 The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but does not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-opattrs-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-opattrs-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-opattrs-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-opattrs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-opattrs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132620.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 6 07:23:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04861 for ; Tue, 6 Aug 2002 07:23:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21467; Tue, 6 Aug 2002 07:15:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21432 for ; Tue, 6 Aug 2002 07:15:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03954; Tue, 6 Aug 2002 07:14:01 -0400 (EDT) Message-Id: <200208061114.HAA03954@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 06 Aug 2002 07:14:00 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-cancel-06.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Cancel Extended Operation Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-cancel-06.txt Pages : 7 Date : 05-Aug-02 This specification describes an LDAP (Lightweight Directory Access Protocol) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation but like the X.511 DAP Abandon operation, this operation has a response which provides an indication of its outcome. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-cancel-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-cancel-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-cancel-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-cancel-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-cancel-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132556.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 6 11:41:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15507 for ; Tue, 6 Aug 2002 11:41:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11173; Tue, 6 Aug 2002 11:34:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11140 for ; Tue, 6 Aug 2002 11:34:52 -0400 (EDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15208 for ; Tue, 6 Aug 2002 11:33:36 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g76FYnL61278 for ; Tue, 6 Aug 2002 15:34:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020806082837.03c64e58@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Aug 2002 08:34:31 -0700 To: ldapext@ietf.org From: "Kurt D. Zeilenga" In-Reply-To: <200208061114.HAA03970@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ldapext] IANA Considerations (Was: I-D ACTION:draft-zeilenga-ldap-*) Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org The I-Ds announced today all have updated "IANA Considerations" sections. If you have an LDAP I-D in the works, you should make sure it contains an adequate IANA Consideration section. Follow the practices details in draft-ietf-ldapbis-iana. You are welcomed to use draft-zeilenga-ldap-* as examples. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Aug 7 07:26:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13067 for ; Wed, 7 Aug 2002 07:26:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04030; Wed, 7 Aug 2002 07:22:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03975 for ; Wed, 7 Aug 2002 07:22:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12835; Wed, 7 Aug 2002 07:21:24 -0400 (EDT) Message-Id: <200208071121.HAA12835@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 07 Aug 2002 07:21:24 -0400 Subject: [ldapext] I-D ACTION:draft-ietf-ldapext-ldapv3-vlv-08.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : LDAP Extensions for Scrolling View Browsing of Search Result Author(s) : D. Boreham, J. Sermersheim, A. Kashi Filename : draft-ietf-ldapext-ldapv3-vlv-08.txt Pages : 12 Date : 06-Aug-02 This document describes a Virtual List View control extension for the Lightweight Directory Access Protocol (LDAP) Search operation. This control is designed to allow the 'virtual list box' feature, common in existing commercial e-mail address book applications, to be supported efficiently by LDAP servers. LDAP servers' inability to support this client feature is a significant impediment to LDAP replacing proprietary protocols in commercial e-mail systems. The control allows a client to specify that the server return, for a given LDAP search with associated sort keys, a contiguous subset of the search result set. This subset is specified in terms of offsets into the ordered list, or in terms of a greater than or equal comparison value. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapext-ldapv3-vlv-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapext-ldapv3-vlv-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020806114840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldapv3-vlv-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldapv3-vlv-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020806114840.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Aug 7 12:32:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27125 for ; Wed, 7 Aug 2002 12:32:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21635; Wed, 7 Aug 2002 12:24:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21603 for ; Wed, 7 Aug 2002 12:24:30 -0400 (EDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26650 for ; Wed, 7 Aug 2002 12:23:15 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g77GOSL67790 for ; Wed, 7 Aug 2002 16:24:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020807091641.03d48250@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 07 Aug 2002 09:24:07 -0700 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ldapext] LDAP TS approved Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Now that the LDAP Technical Specification document draft-ietf-ldapbis-ldapv3-ts has been approved as a Proposed Standard, I believe it important that all specifications detailing LDAP extensions normatively reference this document as the definitive LDAP technical specification. Where the extension specification needs to incorporate particular portions of the LDAPv3 technical specification, such as a protocol mechanism [RFC 2251] or schema element [RFC 2252,2256], additional references should be added. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 13 16:17:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17187 for ; Tue, 13 Aug 2002 16:17:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02812; Tue, 13 Aug 2002 16:11:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29913 for ; Tue, 13 Aug 2002 15:30:43 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14947 for ; Tue, 13 Aug 2002 15:29:23 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7DJTF8S007508; Tue, 13 Aug 2002 21:29:16 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 13 Aug 2002 20:30:10 +0100 Received: from [192.168.0.246] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 13 Aug 2002 21:30:08 +0200 Date: Tue, 13 Aug 2002 05:53:55 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: micharm@microsoft.com, paulle@microsoft.com, levone@microsoft.com, rlmorgan@washington.edu cc: ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se Message-ID: <24876124.1029218035@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 13 Aug 2002 19:30:09.0468 (UTC) FILETIME=[D6071FC0:01C242FF] Content-Transfer-Encoding: 7bit Subject: [ldapext] draft-ietf-ldapext-locate Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7bit Comments from the IESG: ------- The document says: If there are no matching SRV records available for the converted DN the client SHOULD NOT attempt to 'walk the tree' by removing the least significant portion of the constructed fully qualified domain name. The meaning of "SHOULD NOT" is "don't do this unless you understand the implications". Well, I don't know where to look to understand the implications. Thus I think it would be useful to either make it a MUST NOT, or explain something about the implications of using shorter labels. Alternatively specify SHOULD NOT do this in general, but MUST NOT ever use this with just one label (i.e. MUST NOT look for _ldap._tcp.) or something similar. ------- The document is unclear (see next note) on: (a) When this is to be used (only when not having the foggiest clue where a record with a specific DN is, or every time a record is to be accessed?) (b) How to handle the case when one have a DN which have both dc and non-dc components. Example of this is when two records stored on two different servers share the same dc components. IF those records per definition (of this document) have to be stored on the same server, or referrals have to be stored on them to point to the other, then this document has a scope which is larger than at first glance. I.e. part from stating how to locate a record using DNS, it also has an implicit result that DC is _the_ naming convention for the Internet. Please explain. ------- This document define a conversion that is over-restrictive. The output domain name is initially empty. The DN is processed in right-to-left order (i.e., beginning with the first RDN in the sequence of RDNs). An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue; (2) the attribute type is "DC"; and (3) the attribute value is non-null. If it can be converted, the attribute value is used as a domain name component (label). The first such value becomes the rightmost (i.e., most significant) domain name component, and successive converted RDN values extend to the left. If an RDN cannot be converted, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ processing stops. If the output domain name is empty when ^^^^^^^^^^^^^^^^^ processing stops, the DN cannot be converted into a domain name. The underscored text should be removed and replaced with text that states the non-DC RDN's are skipped over. So for example the DN: cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, dc=edu Can be unambiguously translated into: lees.mit.edu Yet the underscored words make this translation invalid. With the Underscored rule in place this DN would convert to just 'mit.edu' which is not the desired result. The additional flexibility offered will permit us to convert existing PKI systems to make use of this feature without requiring all certificates to be re-issued. It will also permit us to create DIT's that can be delegated at more points rather then requiring all structure to be at the very top where the DC components are, prior to any non-DC component. For example if MIT had a DIT with a top level name of: o=MIT,c=US and a subordinate lab wanted to use this document, they could have a delegated subtree like: ou=Lab for X,o=MIT,c=US and then add a DC component below this as: dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US Under my more flexible approach this would work. Without the flexibility they would be SOL until MIT redid its entire DIT to be: o=MIT,c=US,dc=mit,dc=edu and then they would have to be jointed in as: o=MIT,c=US,dc=labx,dc=mit,dc=edu Ned: I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. ------- References should be split in normative and non-normative. ------- I wonder about the reference to RFC1700, which has been obsoleted by RFC3232, and that RFC actuallt talks about a DB that contains the info. So How should this doc refer to that? ------- Needs better abstract; doesn't even use the word "SRV". (and the rfc editor will surely complain when they get it...) Might be good to use SRV in the title as well, as opposed to just "DNS". But this I'm less concerned about, as there are two steps, and only the second step is SRV records. E.g., maybe change: Discovering LDAP Services with DNS To something like: Discovering LDAP Services with DNS SRV Resource Records However, the rfc editor probably won't like the abbreviation "SRV". Unfortunately, I don't think the acronym expands into anything useful. ------- I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 13 17:19:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20974 for ; Tue, 13 Aug 2002 17:19:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12823; Tue, 13 Aug 2002 17:17:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12783 for ; Tue, 13 Aug 2002 17:16:58 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20742 for ; Tue, 13 Aug 2002 17:15:37 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 13 Aug 2002 14:16:25 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 Aug 2002 14:16:25 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 13 Aug 2002 14:16:25 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 13 Aug 2002 14:16:24 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 13 Aug 2002 14:16:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 13 Aug 2002 14:16:24 -0700 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD4ECB87@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: draft-ietf-ldapext-locate thread-index: AcJC/+uYM/5LontiQziVzIVy2jW8GAADiArw From: "Paul Leach" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Michael Armijo" , "Levon Esibov" , Cc: , "Ned Freed" , X-OriginalArrivalTime: 13 Aug 2002 21:16:24.0703 (UTC) FILETIME=[ADF6C8F0:01C2430E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA12788 Subject: [ldapext] RE: draft-ietf-ldapext-locate Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit Are all the IESG members who had comments on the TO: or CC: list? Or are all responses to their questions/suggestions supposed to be routed through you? > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Tuesday, August 13, 2002 2:54 AM > To: Michael Armijo; Paul Leach; Levon Esibov; rlmorgan@washington.edu > Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > Subject: draft-ietf-ldapext-locate > > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 13 17:46:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22303 for ; Tue, 13 Aug 2002 17:46:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16156; Tue, 13 Aug 2002 17:36:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16126 for ; Tue, 13 Aug 2002 17:36:46 -0400 (EDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21829 for ; Tue, 13 Aug 2002 17:35:25 -0400 (EDT) Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.2) with ESMTP id g7DLaiA02405; Tue, 13 Aug 2002 17:36:44 -0400 (EDT) Received: from ehudwt02.exchange.ml.com (ehudwt02.exchange.ml.com [199.201.37.23]) by telutil13a.ml.com (8.11.3/8.11.3/telutil13a-1.1) with SMTP id g7DLWcf28705; Tue, 13 Aug 2002 17:32:38 -0400 (EDT) Received: from 169.242.226.175 by ehudwt02.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 13 Aug 2002 17:29:57 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope08.hew.us.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Tue, 13 Aug 2002 17:32:17 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BD26@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "=?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?=" cc: ldapext@ietf.org Subject: RE: [ldapext] draft-ietf-ldapext-locate Date: Tue, 13 Aug 2002 17:32:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 1147A5DF305077-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA16127 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit In general, divining any meaning from a distinguished name is not good practice (my $.02). The implications are that your app will likely break. The SHOULD NOT allows you impart meaning to your distinguished name if you so choose. A MUST NOT would be an absolute prohibition. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, August 13, 2002 5:54 AM To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; rlmorgan@washington.edu Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se Subject: [ldapext] draft-ietf-ldapext-locate Comments from the IESG: ------- The document says: If there are no matching SRV records available for the converted DN the client SHOULD NOT attempt to 'walk the tree' by removing the least significant portion of the constructed fully qualified domain name. The meaning of "SHOULD NOT" is "don't do this unless you understand the implications". Well, I don't know where to look to understand the implications. Thus I think it would be useful to either make it a MUST NOT, or explain something about the implications of using shorter labels. Alternatively specify SHOULD NOT do this in general, but MUST NOT ever use this with just one label (i.e. MUST NOT look for _ldap._tcp.) or something similar. ------- The document is unclear (see next note) on: (a) When this is to be used (only when not having the foggiest clue where a record with a specific DN is, or every time a record is to be accessed?) (b) How to handle the case when one have a DN which have both dc and non-dc components. Example of this is when two records stored on two different servers share the same dc components. IF those records per definition (of this document) have to be stored on the same server, or referrals have to be stored on them to point to the other, then this document has a scope which is larger than at first glance. I.e. part from stating how to locate a record using DNS, it also has an implicit result that DC is _the_ naming convention for the Internet. Please explain. ------- This document define a conversion that is over-restrictive. The output domain name is initially empty. The DN is processed in right-to-left order (i.e., beginning with the first RDN in the sequence of RDNs). An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue; (2) the attribute type is "DC"; and (3) the attribute value is non-null. If it can be converted, the attribute value is used as a domain name component (label). The first such value becomes the rightmost (i.e., most significant) domain name component, and successive converted RDN values extend to the left. If an RDN cannot be converted, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ processing stops. If the output domain name is empty when ^^^^^^^^^^^^^^^^^ processing stops, the DN cannot be converted into a domain name. The underscored text should be removed and replaced with text that states the non-DC RDN's are skipped over. So for example the DN: cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, dc=edu Can be unambiguously translated into: lees.mit.edu Yet the underscored words make this translation invalid. With the Underscored rule in place this DN would convert to just 'mit.edu' which is not the desired result. The additional flexibility offered will permit us to convert existing PKI systems to make use of this feature without requiring all certificates to be re-issued. It will also permit us to create DIT's that can be delegated at more points rather then requiring all structure to be at the very top where the DC components are, prior to any non-DC component. For example if MIT had a DIT with a top level name of: o=MIT,c=US and a subordinate lab wanted to use this document, they could have a delegated subtree like: ou=Lab for X,o=MIT,c=US and then add a DC component below this as: dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US Under my more flexible approach this would work. Without the flexibility they would be SOL until MIT redid its entire DIT to be: o=MIT,c=US,dc=mit,dc=edu and then they would have to be jointed in as: o=MIT,c=US,dc=labx,dc=mit,dc=edu Ned: I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. ------- References should be split in normative and non-normative. ------- I wonder about the reference to RFC1700, which has been obsoleted by RFC3232, and that RFC actuallt talks about a DB that contains the info. So How should this doc refer to that? ------- Needs better abstract; doesn't even use the word "SRV". (and the rfc editor will surely complain when they get it...) Might be good to use SRV in the title as well, as opposed to just "DNS". But this I'm less concerned about, as there are two steps, and only the second step is SRV records. E.g., maybe change: Discovering LDAP Services with DNS To something like: Discovering LDAP Services with DNS SRV Resource Records However, the rfc editor probably won't like the abbreviation "SRV". Unfortunately, I don't think the acronym expands into anything useful. ------- I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. _______________________________________________ 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 Tue Aug 13 17:54:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22640 for ; Tue, 13 Aug 2002 17:54:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17521; Tue, 13 Aug 2002 17:51:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17487 for ; Tue, 13 Aug 2002 17:51:30 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22450 for ; Tue, 13 Aug 2002 17:50:09 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 13 Aug 2002 14:50:58 -0700 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 Aug 2002 14:50:58 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 13 Aug 2002 14:50:57 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 13 Aug 2002 14:50:57 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 13 Aug 2002 14:50:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 13 Aug 2002 14:50:56 -0700 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD4ECB88@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: draft-ietf-ldapext-locate thread-index: AcJC/+uYM/5LontiQziVzIVy2jW8GAADvyXQ From: "Paul Leach" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Michael Armijo" , "Levon Esibov" , Cc: , "Ned Freed" , X-OriginalArrivalTime: 13 Aug 2002 21:50:57.0293 (UTC) FILETIME=[8152EBD0:01C24313] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA17488 Subject: [ldapext] RE: draft-ietf-ldapext-locate Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit I'm goin to respond to small numbers of sections at a time... Comments inline. > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Tuesday, August 13, 2002 2:54 AM > To: Michael Armijo; Paul Leach; Levon Esibov; rlmorgan@washington.edu > Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > Subject: draft-ietf-ldapext-locate > > > Comments from the IESG: > ------- > The document says: > If there are no > matching SRV records available for the converted DN the > client SHOULD > NOT attempt to 'walk the tree' by removing the least significant > portion of the constructed fully qualified domain name. > > The meaning of "SHOULD NOT" is "don't do this unless you > understand the > implications". Well, I don't know where to look to understand the > implications. > Thus I think it would be useful to either make it a MUST NOT, > or explain > something about the implications of using shorter labels. > > Alternatively specify SHOULD NOT do this in general, but MUST NOT ever > use this with just one label (i.e. MUST NOT look for _ldap._tcp.) > or something similar. I don't feel like I really know the considerations. That seems like it's a pretty good reason to make it a SHOULD NOT, I would think. But we couldn't think a good reason to disallow it, either. One I can think of is to avoid demands on the DNS service close to the top of the DNS naming hierarchy. That would suggest not looking up SRV records for "_ldap._tcp.com" or "_ldap._tcp.co.uk" -- so the depth may vary. Within an organization, DNS lookup traffic may or may not be a major factor. > > ------- > The document is unclear (see next note) on: > > (a) When this is to be used (only when not having the > foggiest clue where a > record with a specific DN is, or every time a record is to be > accessed?) I would say that this is currently the only standardized way to find the authoritative LDAP server for a DN that contains DC components. And that it is not meant to disallow non-authoritative servers, proxies, or caching at the client or at non-authoritative servers. However, in the absence of any other proposals for how to find an LDAP server (authoritative or not) given a DN that contains DC components, I find it rather difficult to say when this should be used as opposed to some alternative. > > (b) How to handle the case when one have a DN which have both > dc and non-dc > components. Example of this is when two records stored on two > different > servers share the same dc components. IF those records per > definition (of > this document) have to be stored on the same server, or > referrals have to > be stored on them to point to the other, then this document > has a scope > which is larger than at first glance. I.e. part from stating > how to locate > a record using DNS, it also has an implicit result that DC is > _the_ naming > convention for the Internet. Please explain. It isn't _the_ naming convention for the Internet. It isn't even _the_ naming convention for LDAP. If you want to think of it this way, I guess one could say that it is _the_ convention for LDAP DNs that contain DC components, but not for ones that don't. Thus, for example, we deliberately say nothing at all about DNs such as "CN=John Smith, OU=Marketng, O=ExampleCorp, C=US" or (say) "CN=John Smith, E=smith@example.com, O=ExampleCorp,C=US" or "CN=John Smith, S=ldap.example.com, O=ExampleCorp, C=US" -- the latter two being examples intended to suggest other ways of deducing the DNS name of an LDAP server from the DN. We deliberately tried to restrict the set of DNs that the convention applied to so as to not preclude other conventions from being developed. Paul _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Aug 13 18:37:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24074 for ; Tue, 13 Aug 2002 18:37:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20970; Tue, 13 Aug 2002 18:26:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20938 for ; Tue, 13 Aug 2002 18:26:25 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23634 for ; Tue, 13 Aug 2002 18:25:02 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7DMNPLk022644; Wed, 14 Aug 2002 00:24:55 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 13 Aug 2002 23:24:34 +0100 Received: from [192.168.0.246] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 14 Aug 2002 00:24:33 +0200 Date: Tue, 13 Aug 2002 17:49:30 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Paul Leach , Michael Armijo , Levon Esibov , rlmorgan@washington.edu cc: ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se Message-ID: <25789003.1029260970@localhost> In-Reply-To: <4AEE3169443CDD4796CA8A00B02191CD4ECB87@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <4AEE3169443CDD4796CA8A00B02191CD4ECB87@win-msg-01.wingroup.wind eploy.ntdev.microsoft.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 13 Aug 2002 22:24:33.0673 (UTC) FILETIME=[332E1790:01C24318] Content-Transfer-Encoding: 7bit Subject: [ldapext] RE: draft-ietf-ldapext-locate Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7bit --On 2002-08-13 14.16 -0700 Paul Leach wrote: > Are all the IESG members who had comments on the TO: or CC: list? Or are > all responses to their questions/suggestions supposed to be routed > through you? Everything is routed through me. That is how IESG work. I collect comments, and then I collect your responses. I, as responsible AD, have discussions with other AD's, and then with you. Later, I might bring in AD in question if really needed, but that is not the case now. I.e. they have other documents to handle which I have commented on ;-) paf _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Aug 14 00:43:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03437 for ; Wed, 14 Aug 2002 00:43:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08781; Wed, 14 Aug 2002 00:36:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08712 for ; Wed, 14 Aug 2002 00:36:37 -0400 (EDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03294 for ; Wed, 14 Aug 2002 00:35:15 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g7E4aMkC013363; Wed, 14 Aug 2002 04:36:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020813201324.0674c688@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 Aug 2002 21:36:05 -0700 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-ietf-ldapext-locate Cc: micharm@microsoft.com, paulle@microsoft.com, levone@microsoft.com, rlmorgan@washington.edu, ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se In-Reply-To: <24876124.1029218035@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA08713 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit At 02:53 AM 2002-08-13, Patrik Fältström wrote: >This document define a conversion that is over-restrictive. I disagree. I also note that this issue has been discussed repeatedly on the list and, IMO, consensus has been that the current specification is appropriately restrictive. > The output domain name is initially empty. The DN is processed in > right-to-left order (i.e., beginning with the first RDN in the > sequence of RDNs). An RDN is able to be converted if it (1) > consists of a single AttributeTypeAndValue; (2) the attribute type > is "DC"; and (3) the attribute value is non-null. If it can be > converted, the attribute value is used as a domain name component > (label). The first such value becomes the rightmost (i.e., most > significant) domain name component, and successive converted RDN > values extend to the left. If an RDN cannot be converted, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > processing stops. If the output domain name is empty when > ^^^^^^^^^^^^^^^^^ > processing stops, the DN cannot be converted into a domain name. > >The underscored text should be removed and replaced with text that >states the non-DC RDN's are skipped over. So for example the DN: > > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, > dc=edu > >Can be unambiguously translated into: > > lees.mit.edu so would: DC=less,DC=MIT,DC=MIT,OU=domains,O=example,c=DE but one should not reasonably expect servers listed at _ldap._tcp.less.mit.edu to have knowledge of this DN. A user attempting to access DC=less,DC=MIT,DC=MIT,OU=domains,O=example,c=DE would be astonished if their client connected to servers listed _ldap._tcp.less.mit.edu. >Yet the underscored words make this translation invalid. With the >Underscored rule in place this DN would convert to just 'mit.edu' >which is not the desired result. This IS the desired result. Domain components have two common uses are used together (or separately). 1) naming prefixes, 2) naming of objects associated with domain. For example, consider the DN. dc=example,dc=com,ou=domains,dc=example,dc=net This is, the organization owning example.net has an entry holding information about the domain example.com. The mapping suggested by Jeff would require the owner of example.net maintain DNS SRV records associated with com.example.net and example.com.example.net. This is not desirable. Consider the DN, dc=example,dc=com,ou=domains,o=ISP,c=UK where the entry represents services (not necessarily DNS services) which the ISP provides domain name example.com. It would be reasonable to presume _ldap._tcp.example.com referred to the LDAP server holding "dc=example,dc=com,ou=domains,o=ISP,c=UK". This is not desirable. Or, more to the point, it is only reasonable to assume that that _ldap._tcp.example.com refers to server with knowledge of dc=example,dc=com. >The additional flexibility offered will permit us to convert existing >PKI systems to make use of this feature without requiring all >certificates to be re-issued. Converting from existing naming to DC naming doesn't require this flexibility. Switching from one naming practice to another should be done directly. That is, switching from cn=Jeffrey Schiller,ou=LEES Laboratory,o=MIT (or whatever) to cn=Jeffrey Schiller,dc=lees,dc=mit,dc=edu should be done without creating intermediate naming practices, such as: cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit,dc=edu Intermediate naming practices are evil and should be avoided. >It will also permit us to create DIT's >that can be delegated at more points rather then requiring all >structure to be at the very top where the DC components are, prior to >any non-DC component. > >For example if MIT had a DIT with a top level name of: > > o=MIT,c=US > >and a subordinate lab wanted to use this document, they could have a >delegated subtree like: > > ou=Lab for X,o=MIT,c=US > >and then add a DC component below this as: > > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US No. They would establish a server with knowledge of "dc=labx,dc=mit,dc=edu". They could treat "ou=Lab for X,o=MIT,c=US" and "ou=Lab for X,o=MIT,c=US" as independent subtrees or relate these subtrees using aliases or referrals. >Under my more flexible approach this would work. Without the >flexibility they would be SOL until MIT redid its entire DIT to >be: No. See above. > o=MIT,c=US,dc=mit,dc=edu > >and then they would have to be jointed in as: > > o=MIT,c=US,dc=labx,dc=mit,dc=edu > >Ned: I have three concerns here: > >(0) It isn't clear when this approach is supposed to be used. DNs are an >integral part of *every* LDAP operation. Is it the intent that an >LDAP client check every DN it sees for DC fields and if it finds them use >this approach. Or is it only appropriate in specific situations? It is intended to be a general mechanism for locating LDAP servers having knowledge of directory objects associated with a DN in absence of location information. This DN may have been provided to the application via LDAP or other means. If the DN was provided with location information, such as a LDAP URL with host part, that information should be used. Howeer, where the DN is provided without any location information, this mechanism provides a means, for a subset of DNs (those using RFC 2247 naming), for the application to locate servers with knowledge of the DN. This application may be an LDAP client or server. OpenLDAP's server, for example, can use this mechanism to generate referrals to clients requesting DN which it otherwise has no knowledge of. >(1) This document specifies two things: How to translate a DN to a DNS >name and how to use a DNS name to locate a corresponding LDAP >server. I argue that the document specifies one process, to locate LDAP servers with knowledge of a particular DN, which has two steps. >The document seems to imply that the latter is only used when a DNS >name is produced by the former. I wonder if this restriction is a >good idea: Isn't the ability to use SRV records to locate more generally >useful than this limited context? I don't believe this document restricts how DNS SRV records can be used. It also doesn't restrict construction of additional processes for locating LDAP servers with knowledge of a particular DN. In fact, draft-zeilenga-ldap-x500-locate suggests a process for DNs using geo-political naming. Additionally, DNS SRVs could be used to answer questions such as "Are there LDAP servers associated with this domain?". Of course, this would be followed by, "What DN is used by the owner of this domain for their objects?". If a listed server provides 100s of namingContext, which one is the right one? Luckily, we have RFC 2247 which says how the owner of the domain should name objects. >The answer to this may be no, but if so, the rationale for that >answer should be part of the specification. > >(2) I don't see any provision for fallback to A records if SRV records > don't exist. I can easily see this being a Bad Idea, if so, there > should be an explicit prohibition of it in the document along with > some explanation of why it is a bad idea. It is a bad idea. A short explanation would be appropriate. >------- >References should be split in normative and non-normative. >------- >I wonder about the reference to RFC1700, which has been obsoleted >by RFC3232, and that RFC actuallt talks about a DB that contains >the info. So How should this doc refer to that? >------- >Needs better abstract; doesn't even use the word "SRV". (and the rfc >editor will surely complain when they get it...) > >Might be good to use SRV in the title as well, as opposed to just >"DNS". But this I'm less concerned about, as there are two steps, and >only the second step is SRV records. > >E.g., maybe change: > > Discovering LDAP Services with DNS > >To something like: > > Discovering LDAP Services with DNS SRV Resource Records > >However, the rfc editor probably won't like the abbreviation >"SRV". Unfortunately, I don't think the acronym expands into anything >useful. SRV is not an abbreviation, but IANA-registered DNS RR Type. http://www.iana.org/assignments/dns-parameters >------- >I have three concerns here: see above. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Aug 14 16:02:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23307 for ; Wed, 14 Aug 2002 16:02:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21415; Wed, 14 Aug 2002 16:00:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21391 for ; Wed, 14 Aug 2002 16:00:53 -0400 (EDT) Received: from mxsmta02.inithost.com (104-209.235.30.interliant.com [209.235.30.104] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23236 for ; Wed, 14 Aug 2002 15:59:32 -0400 (EDT) Received: from alexis98 ([168.205.9.246]) by mxsmta02.inithost.com (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20020814200000.PVMT5866.mxsmta02.inithost.com@alexis98>; Wed, 14 Aug 2002 16:00:00 -0400 From: "Alexis Bor" To: "'Liben, Michael \(GTS\)'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" Cc: Subject: RE: [ldapext] draft-ietf-ldapext-locate Date: Wed, 14 Aug 2002 16:00:50 -0400 Message-ID: <004401c243cd$4a94fd30$f609cda8@directoryworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <9B5CBD4986A9D511BE2100065B045DDF0238BD26@ehope21.hew.us.ml.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA21392 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit I proved to myself and others (while I was at Boeing doing R&D work in Directory) back in 1992 that putting any meaning into a DN is not a good practice. We took the example of a company of 100,000 and looked at the different approaches for DN's - Geographic, Political, Hybrid and others. It became clear that it would be a maintenance headache and cause lots of stress on the overall infrastructure. It was very hard to convince most people for a long time until some work that Jeff Hodges did at Stanford got a lot of attention in the late 90's. A real hard piece of work to put forward is a best practices document. The number of opinions will typically exceed the number of people working on the document. What we learned in the mid 90's was that such a document evolves faster than the review cycle (part of an EMA effort to write a white paper on directory best practices), making it out of date before you even finish the review of it. However, with all of the experience that everyone is getting, it may be worth resurrecting the idea again. Perhaps an industry group can step up to the challenge - any takers? -- Alexis Alexis Bor Directory Works, Inc. www.directoryworks.com -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf Of Liben, Michael (GTS) Sent: Tuesday, August 13, 2002 5:32 PM To: 'Patrik Fältström' Cc: ldapext@ietf.org Subject: RE: [ldapext] draft-ietf-ldapext-locate In general, divining any meaning from a distinguished name is not good practice (my $.02). The implications are that your app will likely break. The SHOULD NOT allows you impart meaning to your distinguished name if you so choose. A MUST NOT would be an absolute prohibition. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, August 13, 2002 5:54 AM To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; rlmorgan@washington.edu Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se Subject: [ldapext] draft-ietf-ldapext-locate Comments from the IESG: ------- The document says: If there are no matching SRV records available for the converted DN the client SHOULD NOT attempt to 'walk the tree' by removing the least significant portion of the constructed fully qualified domain name. The meaning of "SHOULD NOT" is "don't do this unless you understand the implications". Well, I don't know where to look to understand the implications. Thus I think it would be useful to either make it a MUST NOT, or explain something about the implications of using shorter labels. Alternatively specify SHOULD NOT do this in general, but MUST NOT ever use this with just one label (i.e. MUST NOT look for _ldap._tcp.) or something similar. ------- The document is unclear (see next note) on: (a) When this is to be used (only when not having the foggiest clue where a record with a specific DN is, or every time a record is to be accessed?) (b) How to handle the case when one have a DN which have both dc and non-dc components. Example of this is when two records stored on two different servers share the same dc components. IF those records per definition (of this document) have to be stored on the same server, or referrals have to be stored on them to point to the other, then this document has a scope which is larger than at first glance. I.e. part from stating how to locate a record using DNS, it also has an implicit result that DC is _the_ naming convention for the Internet. Please explain. ------- This document define a conversion that is over-restrictive. The output domain name is initially empty. The DN is processed in right-to-left order (i.e., beginning with the first RDN in the sequence of RDNs). An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue; (2) the attribute type is "DC"; and (3) the attribute value is non-null. If it can be converted, the attribute value is used as a domain name component (label). The first such value becomes the rightmost (i.e., most significant) domain name component, and successive converted RDN values extend to the left. If an RDN cannot be converted, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ processing stops. If the output domain name is empty when ^^^^^^^^^^^^^^^^^ processing stops, the DN cannot be converted into a domain name. The underscored text should be removed and replaced with text that states the non-DC RDN's are skipped over. So for example the DN: cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, dc=edu Can be unambiguously translated into: lees.mit.edu Yet the underscored words make this translation invalid. With the Underscored rule in place this DN would convert to just 'mit.edu' which is not the desired result. The additional flexibility offered will permit us to convert existing PKI systems to make use of this feature without requiring all certificates to be re-issued. It will also permit us to create DIT's that can be delegated at more points rather then requiring all structure to be at the very top where the DC components are, prior to any non-DC component. For example if MIT had a DIT with a top level name of: o=MIT,c=US and a subordinate lab wanted to use this document, they could have a delegated subtree like: ou=Lab for X,o=MIT,c=US and then add a DC component below this as: dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US Under my more flexible approach this would work. Without the flexibility they would be SOL until MIT redid its entire DIT to be: o=MIT,c=US,dc=mit,dc=edu and then they would have to be jointed in as: o=MIT,c=US,dc=labx,dc=mit,dc=edu Ned: I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. ------- References should be split in normative and non-normative. ------- I wonder about the reference to RFC1700, which has been obsoleted by RFC3232, and that RFC actuallt talks about a DB that contains the info. So How should this doc refer to that? ------- Needs better abstract; doesn't even use the word "SRV". (and the rfc editor will surely complain when they get it...) Might be good to use SRV in the title as well, as opposed to just "DNS". But this I'm less concerned about, as there are two steps, and only the second step is SRV records. E.g., maybe change: Discovering LDAP Services with DNS To something like: Discovering LDAP Services with DNS SRV Resource Records However, the rfc editor probably won't like the abbreviation "SRV". Unfortunately, I don't think the acronym expands into anything useful. ------- I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. _______________________________________________ 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 Wed Aug 14 17:16:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25341 for ; Wed, 14 Aug 2002 17:16:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25819; Wed, 14 Aug 2002 17:15:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25788 for ; Wed, 14 Aug 2002 17:15:28 -0400 (EDT) Received: from uxtpaprx1.nam.pwcinternal.com (uxtpaprx1.pwcglobal.com [155.201.16.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25260 for ; Wed, 14 Aug 2002 17:14:07 -0400 (EDT) From: christine.yoon@us.pwcglobal.com Received: from us-amsmta005.nam.pwcinternal.com (us-amsmta005.nam.pwcinternal.com [10.26.104.89]) by uxtpaprx1.nam.pwcinternal.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7ELEtn07656; Wed, 14 Aug 2002 17:14:55 -0400 (EDT) Subject: RE: [ldapext] draft-ietf-ldapext-locate To: alexis.bor@directoryworks.com, "'Liben, Michael \(GTS\)'" , "'Patrik =?iso-8859-1?Q?F=E4ltstr=F6m'?=" Cc: X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 14 Aug 2002 17:14:44 -0400 X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.9 |November 16, 2001) at 08/14/2002 05:14:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA25789 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit Is this (Directory best practices) something that one of the IETF ldap working groups can do? If so, I would like to contribute. I represent PricewaterhouseCoopers (PwC) and am working on Security Integration practices. We (PwC) have implemented many directory services for various clients. What is the process to initiate such work? Please advise. -Christine Yoon PricewaterhouseCoopers (201)981-1172 (cell) (732)706-3559 (office) "Alexis Bor" , "'Patrik Fältström'" yworks.com> Sent by: cc: ldapext-admin@ietf.o Subject: RE: [ldapext] draft-ietf-ldapext-locate rg 08/14/2002 04:00 PM I proved to myself and others (while I was at Boeing doing R&D work in Directory) back in 1992 that putting any meaning into a DN is not a good practice. We took the example of a company of 100,000 and looked at the different approaches for DN's - Geographic, Political, Hybrid and others. It became clear that it would be a maintenance headache and cause lots of stress on the overall infrastructure. It was very hard to convince most people for a long time until some work that Jeff Hodges did at Stanford got a lot of attention in the late 90's. A real hard piece of work to put forward is a best practices document. The number of opinions will typically exceed the number of people working on the document. What we learned in the mid 90's was that such a document evolves faster than the review cycle (part of an EMA effort to write a white paper on directory best practices), making it out of date before you even finish the review of it. However, with all of the experience that everyone is getting, it may be worth resurrecting the idea again. Perhaps an industry group can step up to the challenge - any takers? -- Alexis Alexis Bor Directory Works, Inc. www.directoryworks.com -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf Of Liben, Michael (GTS) Sent: Tuesday, August 13, 2002 5:32 PM To: 'Patrik Fältström' Cc: ldapext@ietf.org Subject: RE: [ldapext] draft-ietf-ldapext-locate In general, divining any meaning from a distinguished name is not good practice (my $.02). The implications are that your app will likely break. The SHOULD NOT allows you impart meaning to your distinguished name if you so choose. A MUST NOT would be an absolute prohibition. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, August 13, 2002 5:54 AM To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; rlmorgan@washington.edu Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se Subject: [ldapext] draft-ietf-ldapext-locate Comments from the IESG: ------- The document says: If there are no matching SRV records available for the converted DN the client SHOULD NOT attempt to 'walk the tree' by removing the least significant portion of the constructed fully qualified domain name. The meaning of "SHOULD NOT" is "don't do this unless you understand the implications". Well, I don't know where to look to understand the implications. Thus I think it would be useful to either make it a MUST NOT, or explain something about the implications of using shorter labels. Alternatively specify SHOULD NOT do this in general, but MUST NOT ever use this with just one label (i.e. MUST NOT look for _ldap._tcp.) or something similar. ------- The document is unclear (see next note) on: (a) When this is to be used (only when not having the foggiest clue where a record with a specific DN is, or every time a record is to be accessed?) (b) How to handle the case when one have a DN which have both dc and non-dc components. Example of this is when two records stored on two different servers share the same dc components. IF those records per definition (of this document) have to be stored on the same server, or referrals have to be stored on them to point to the other, then this document has a scope which is larger than at first glance. I.e. part from stating how to locate a record using DNS, it also has an implicit result that DC is _the_ naming convention for the Internet. Please explain. ------- This document define a conversion that is over-restrictive. The output domain name is initially empty. The DN is processed in right-to-left order (i.e., beginning with the first RDN in the sequence of RDNs). An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue; (2) the attribute type is "DC"; and (3) the attribute value is non-null. If it can be converted, the attribute value is used as a domain name component (label). The first such value becomes the rightmost (i.e., most significant) domain name component, and successive converted RDN values extend to the left. If an RDN cannot be converted, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ processing stops. If the output domain name is empty when ^^^^^^^^^^^^^^^^^ processing stops, the DN cannot be converted into a domain name. The underscored text should be removed and replaced with text that states the non-DC RDN's are skipped over. So for example the DN: cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, dc=edu Can be unambiguously translated into: lees.mit.edu Yet the underscored words make this translation invalid. With the Underscored rule in place this DN would convert to just 'mit.edu' which is not the desired result. The additional flexibility offered will permit us to convert existing PKI systems to make use of this feature without requiring all certificates to be re-issued. It will also permit us to create DIT's that can be delegated at more points rather then requiring all structure to be at the very top where the DC components are, prior to any non-DC component. For example if MIT had a DIT with a top level name of: o=MIT,c=US and a subordinate lab wanted to use this document, they could have a delegated subtree like: ou=Lab for X,o=MIT,c=US and then add a DC component below this as: dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US Under my more flexible approach this would work. Without the flexibility they would be SOL until MIT redid its entire DIT to be: o=MIT,c=US,dc=mit,dc=edu and then they would have to be jointed in as: o=MIT,c=US,dc=labx,dc=mit,dc=edu Ned: I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. ------- References should be split in normative and non-normative. ------- I wonder about the reference to RFC1700, which has been obsoleted by RFC3232, and that RFC actuallt talks about a DB that contains the info. So How should this doc refer to that? ------- Needs better abstract; doesn't even use the word "SRV". (and the rfc editor will surely complain when they get it...) Might be good to use SRV in the title as well, as opposed to just "DNS". But this I'm less concerned about, as there are two steps, and only the second step is SRV records. E.g., maybe change: Discovering LDAP Services with DNS To something like: Discovering LDAP Services with DNS SRV Resource Records However, the rfc editor probably won't like the abbreviation "SRV". Unfortunately, I don't think the acronym expands into anything useful. ------- I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. _______________________________________________ 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 _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Aug 14 19:05:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27153 for ; Wed, 14 Aug 2002 19:05:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00414; Wed, 14 Aug 2002 18:53:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00349 for ; Wed, 14 Aug 2002 18:53:42 -0400 (EDT) Received: from uxtpaprx1.nam.pwcinternal.com (uxtpaprx1.pwcglobal.com [155.201.16.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26834 for ; Wed, 14 Aug 2002 18:52:19 -0400 (EDT) From: christine.yoon@us.pwcglobal.com Received: from us-amsmta005.nam.pwcinternal.com (us-amsmta005.nam.pwcinternal.com [10.26.104.89]) by uxtpaprx1.nam.pwcinternal.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7EMr9n27511; Wed, 14 Aug 2002 18:53:09 -0400 (EDT) Subject: RE: [ldapext] draft-ietf-ldapext-locate To: ereed@novell.com, , , , Cc: X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 14 Aug 2002 18:52:56 -0400 X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.9 |November 16, 2001) at 08/14/2002 06:53:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA00350 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit I don't disagree with your saying As for naming - there is no right answer - it's a matter for local politics and engineering to work out. In fact, use of the hierarchical names in DNs for a private company having global presence may be necessary. Because the company may have different ways to operate/administer the directory depending on different regions/countries. However, I think that it is better to avoid the hierarchical names (if can) so that directory users (applications, end users) do not use the semantics at all. My thought on the directory naming best pratice is not to make a set of specific naming recomendations , but to address a set of alternative approaches with issues/risks. -Christine Yoon PricewaterhouseCoopers . "Ed Reed" To: , , , 08/14/2002 05:29 Christine Yoon/US/ABAS/PwC@Americas-US PM cc: Subject: RE: [ldapext] draft-ietf-ldapext-locate Sorry, this conversation takes me back to wondering why 48 bit mac addresses aren't sufficient as names... What is the purpose of prohibiting the use the hierarchical name, whether DN or DNS, to gather information about the support and policies of an organization? Has that practice, of searching for authoritative MX records for a host name, proven so broken that we don't want to use it as a way to find LDAP servers for a DN, either? I don't think I'm mixing metaphores, here...I see a convergence in DNs and DNS names over the long run. I must not recall the problem we're trying to avoid, here. As for naming - there is no right answer - it's a matter for local politics and engineering to work out. "What this directory needs is a good secondary index". And thus was born a never ending stream of catalogues and centroids. Ed =============== Edwards E Reed Novell, Inc. +1 585 624 2402 >>> 08/14/02 05:14PM >>> Is this (Directory best practices) something that one of the IETF ldap working groups can do? If so, I would like to contribute. I represent PricewaterhouseCoopers (PwC) and am working on Security Integration practices. We (PwC) have implemented many directory services for various clients. What is the process to initiate such work? Please advise. -Christine Yoon PricewaterhouseCoopers (201)981-1172 (cell) (732)706-3559 (office) "Alexis Bor" , "'Patrik Fältström'" yworks.com> Sent by: cc: ldapext-admin@ietf.o Subject: RE: [ldapext] draft-ietf-ldapext-locate rg 08/14/2002 04:00 PM I proved to myself and others (while I was at Boeing doing R&D work in Directory) back in 1992 that putting any meaning into a DN is not a good practice. We took the example of a company of 100,000 and looked at the different approaches for DN's - Geographic, Political, Hybrid and others. It became clear that it would be a maintenance headache and cause lots of stress on the overall infrastructure. It was very hard to convince most people for a long time until some work that Jeff Hodges did at Stanford got a lot of attention in the late 90's. A real hard piece of work to put forward is a best practices document. The number of opinions will typically exceed the number of people working on the document. What we learned in the mid 90's was that such a document evolves faster than the review cycle (part of an EMA effort to write a white paper on directory best practices), making it out of date before you even finish the review of it. However, with all of the experience that everyone is getting, it may be worth resurrecting the idea again. Perhaps an industry group can step up to the challenge - any takers? -- Alexis Alexis Bor Directory Works, Inc. www.directoryworks.com -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf Of Liben, Michael (GTS) Sent: Tuesday, August 13, 2002 5:32 PM To: 'Patrik Fältström' Cc: ldapext@ietf.org Subject: RE: [ldapext] draft-ietf-ldapext-locate In general, divining any meaning from a distinguished name is not good practice (my $.02). The implications are that your app will likely break. The SHOULD NOT allows you impart meaning to your distinguished name if you so choose. A MUST NOT would be an absolute prohibition. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, August 13, 2002 5:54 AM To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; rlmorgan@washington.edu Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se Subject: [ldapext] draft-ietf-ldapext-locate Comments from the IESG: ------- The document says: If there are no matching SRV records available for the converted DN the client SHOULD NOT attempt to 'walk the tree' by removing the least significant portion of the constructed fully qualified domain name. The meaning of "SHOULD NOT" is "don't do this unless you understand the implications". Well, I don't know where to look to understand the implications. Thus I think it would be useful to either make it a MUST NOT, or explain something about the implications of using shorter labels. Alternatively specify SHOULD NOT do this in general, but MUST NOT ever use this with just one label (i.e. MUST NOT look for _ldap._tcp.) or something similar. ------- The document is unclear (see next note) on: (a) When this is to be used (only when not having the foggiest clue where a record with a specific DN is, or every time a record is to be accessed?) (b) How to handle the case when one have a DN which have both dc and non-dc components. Example of this is when two records stored on two different servers share the same dc components. IF those records per definition (of this document) have to be stored on the same server, or referrals have to be stored on them to point to the other, then this document has a scope which is larger than at first glance. I.e. part from stating how to locate a record using DNS, it also has an implicit result that DC is _the_ naming convention for the Internet. Please explain. ------- This document define a conversion that is over-restrictive. The output domain name is initially empty. The DN is processed in right-to-left order (i.e., beginning with the first RDN in the sequence of RDNs). An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue; (2) the attribute type is "DC"; and (3) the attribute value is non-null. If it can be converted, the attribute value is used as a domain name component (label). The first such value becomes the rightmost (i.e., most significant) domain name component, and successive converted RDN values extend to the left. If an RDN cannot be converted, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ processing stops. If the output domain name is empty when ^^^^^^^^^^^^^^^^^ processing stops, the DN cannot be converted into a domain name. The underscored text should be removed and replaced with text that states the non-DC RDN's are skipped over. So for example the DN: cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, dc=edu Can be unambiguously translated into: lees.mit.edu Yet the underscored words make this translation invalid. With the Underscored rule in place this DN would convert to just 'mit.edu' which is not the desired result. The additional flexibility offered will permit us to convert existing PKI systems to make use of this feature without requiring all certificates to be re-issued. It will also permit us to create DIT's that can be delegated at more points rather then requiring all structure to be at the very top where the DC components are, prior to any non-DC component. For example if MIT had a DIT with a top level name of: o=MIT,c=US and a subordinate lab wanted to use this document, they could have a delegated subtree like: ou=Lab for X,o=MIT,c=US and then add a DC component below this as: dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US Under my more flexible approach this would work. Without the flexibility they would be SOL until MIT redid its entire DIT to be: o=MIT,c=US,dc=mit,dc=edu and then they would have to be jointed in as: o=MIT,c=US,dc=labx,dc=mit,dc=edu Ned: I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. ------- References should be split in normative and non-normative. ------- I wonder about the reference to RFC1700, which has been obsoleted by RFC3232, and that RFC actuallt talks about a DB that contains the info. So How should this doc refer to that? ------- Needs better abstract; doesn't even use the word "SRV". (and the rfc editor will surely complain when they get it...) Might be good to use SRV in the title as well, as opposed to just "DNS". But this I'm less concerned about, as there are two steps, and only the second step is SRV records. E.g., maybe change: Discovering LDAP Services with DNS To something like: Discovering LDAP Services with DNS SRV Resource Records However, the rfc editor probably won't like the abbreviation "SRV". Unfortunately, I don't think the acronym expands into anything useful. ------- I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. _______________________________________________ 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 _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Aug 14 19:13:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27352 for ; Wed, 14 Aug 2002 19:13:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02098; Wed, 14 Aug 2002 19:10:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02070 for ; Wed, 14 Aug 2002 19:10:53 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27249 for ; Wed, 14 Aug 2002 19:09:30 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 14 Aug 2002 16:10:19 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 14 Aug 2002 16:10:19 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 14 Aug 2002 16:10:19 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 14 Aug 2002 16:10:19 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 14 Aug 2002 16:10:18 -0700 Content-Class: urn:content-classes:message Subject: RE: [ldapext] draft-ietf-ldapext-locate MIME-Version: 1.0 Date: Wed, 14 Aug 2002 16:10:18 -0700 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0054_01C243AD.1563F230" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD0492980F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: [ldapext] draft-ietf-ldapext-locate thread-index: AcJDTC6DWRwDSQJYSAG8djb/EHEDaAAmC17A From: "Paul Leach" To: "Kurt D. Zeilenga" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "Michael Armijo" , "Levon Esibov" , , , "Ned Freed" , X-OriginalArrivalTime: 14 Aug 2002 23:10:18.0891 (UTC) FILETIME=[C1DEDDB0:01C243E7] Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0054_01C243AD.1563F230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]=20 > Sent: Tuesday, August 13, 2002 21:36 > To: Patrik F=E4ltstr=F6m > Cc: Michael Armijo; Paul Leach; Levon Esibov;=20 > rlmorgan@washington.edu; ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > Subject: Re: [ldapext] draft-ietf-ldapext-locate >=20 >=20 > At 02:53 AM 2002-08-13, Patrik F=E4ltstr=F6m wrote: > >This document define a conversion that is over-restrictive. >=20 > I disagree. I also note that this issue has been discussed > repeatedly on the list and, IMO, consensus has been that the=20 > current specification is appropriately restrictive. I summarize Kurt's comments for myself as follows: while what Jeff proposes might make sense in a PKI certificate scenario, perhaps because the way certs have been issued means that order of components in SubjectName DNs has been defined to be of no significance, it isn't desirable in general. In addition, I at least don't know that I understand the PK scenario very well. If I have a certificate for user with DN "X" in my hands, why do I need to locate an LDAP server for DN X? Certainly not to get the cert for that user, which seems like the most obvious reason. If I don't have such a cert, how did I get the user's DN? Isn't it more likely that I know the user's email address and want to get their cert so as to send them S/MIME protected email? Also, I know that cert chains contain NameContstraints that say what names subordinate CAs can put in their certs -- if I issued a subordinate CA cert for "OU=3DCompSci, dc=3Dmit, dc=3Dedu, O=3DMIT, C=3DUS", expecting that all the certs they issue will = be stored in the LDAP server for "mit.edu", is it really OK that the new CA issues a cert ending with "dc=3Dcs, OU=3DCompSci, dc=3Dmit, dc=3Dedu, = O=3DMIT, C=3DUS" and that the lookups go to the "cs.mit.edu" server? Are there other security considerations? Since I didn't know the answers to the above, I at least did not feel comfortable specifying behavior whose ramifications I didn't understand. Instead, what we did was make sure that what we wrote did not preclude anyone else from extending this standard. When this issue came up in the WG, I said that what I thought should happen is that someone who understands the PK issues should write an I-D that says how, in certain PK scenarios, one should use the DN in a SubjectName to locate an LDAP server for whatever the PK purpose for doing so is. They can certainly leverage our proposal -- for example, the spec could simply say to rewrite the DN so that all the DC components are on the right hand side in the same order, and then apply our proposal, and then describe what the security considerations are. I still think that's the right way to handle this issue. Paul ------=_NextPart_000_0054_01C243AD.1563F230 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIipTCCA0Aw ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIFdzCCBTagAwIBAgIKbR8tRgADAAAB kjAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X DTAyMDEyOTAwMTYwMVoXDTAyMDkyMDIxMzMyOFowYjETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcG CgmSJomT8ixkARkWCW1pY3Jvc29mdDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRkwFwYDVQQDExBO VERFViBJc3N1ZTY0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCe7uH1+lUYtdzFSBiM LOSsVfDwSUU8V13PLZU4qYeC91SoFyZ2FLFxbMiqUpX0dmt5/WrJ4jerwBQlmheVkZ5i5E1zHyWh Im3xaScMBCJ4dj9Ax4sHIPCKiYPDfneDJbKbriZKqTwTvuoV+4H9AfcE88HQ+l52ecpW3I5A0DFk gQIDAQABo4IDjTCCA4kwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQULLYra2BeKCVgmpPpUKrc bxP2E8AwCwYDVR0PBAQDAgGGMBIGCSsGAQQBgjcVAQQFAgMFAAYwIwYJKwYBBAGCNxUCBBYEFFn6 2/e2PIGLWb3JaMwy6YMDvfPQMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaA FM/Fuhf/LccQgPW5DplKb/ScK/sZMIIBXAYDVR0fBIIBUzCCAU8wggFLoIIBR6CCAUOGgd9sZGFw Oi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoMSksQ049 d2hpY2EyLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hl9odHRwOi8v d2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMEludGVybWVkaWF0 ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDEpLmNybDCCAXMGCCsGAQUFBwEBBIIBZTCCAWEwgdUG CCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRl JTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0 ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgYYGCCsGAQUFBzAChnpo dHRwOi8vd2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYTIubnRkZXYu bWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2Ey KDMpLmNydDAJBgcqhkjOOAQDAzAAMC0CFQCTJcIxIcR6X/F39s4eRbklukPqkAIUdbQr5+2UZc7a 841oHuICRpJxdbswggY/MIIF/6ADAgECAgp1n/n0AAIAAAFWMAkGByqGSM44BAMwYTELMAkGA1UE BhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVW IEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcNMDEwOTE0MDMxNjUwWhcNMDIwOTIw MjEzMzI4WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRl djEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6 kcw3SUnD1p7YhzbJkEgIKp4/YfpF7gHVGeT4oRO0XRLXmOrt5rmf/7PjcNr0KqO6c0lotPutfij0 0dQ3t4/loqVntpE/4ShPTAHnU4+yNkq4Vam1t0vs8RUcC45Ss46PJnQhNHjfa+pwn8vcCi5PK4K4 3v/WTD20wxGXl6vORQIDAQABo4IEbTCCBGkwEAYJKwYBBAGCNxUBBAMCAQEwIwYJKwYBBAGCNxUC BBYEFF0wmXse4uyanN+uhOOORXrSKJ9VMB0GA1UdDgQWBBTJRFZKkBN8qfMzBmve0Jm758jO6TAZ BgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAf BgNVHSMEGDAWgBTPxboX/y3HEID1uQ6ZSm/0nCv7GTCCAj4GA1UdHwSCAjUwggIxMIICLaCCAimg ggIlhoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hp Y2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIZfaHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJ bnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKS5jcmyGgd9sZGFwOi8vL0NOPU5U REVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoMSksQ049d2hpY2EyLENO PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBcwYIKwYBBQUHAQEEggFl MIIBYTCB1QYIKwYBBQUHMAKGgchsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhgYIKwYB BQUHMAKGemh0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNh Mi5udGRldi5taWNyb3NvZnQuY29tX05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUl MjBXaGljYTIoMikuY3J0MAkGByqGSM44BAMDLwAwLAIUUx77g13BMwHgk+1QbyieLyToMN4CFHnb gTPU/Y/C05rO+kV3uJVgyD1oMIIGYjCCBcugAwIBAgIKKB26agABABleeTANBgkqhkiG9w0BAQUF ADBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYG A1UEAxMPTlRERVYgSVNTVUUzIENBMB4XDTAyMDcwODA4MjMwMloXDTAyMDkwNjA4MjMwMlowgccx EzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJ k/IsZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQx ETAPBgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxw YXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDc Ifu483kq/hLla0LcvAFNw84N4YiXBNCSTmx3/RB1oOsXsH776cr43a0fP7LgQVMliao0OXU97xwZ 4NR+fUtqTk/FGNhx/gvlz+5D6BerfBMES7p5nnC/djXHDCKOdfbf9gPtWxY1DjBDVEtw3C8aSGAc TnQY6yril8FzBnWaNQIDAQABo4IDzjCCA8owCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+Bgkr BgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXEC AQIwEwYDVR0lBAwwCgYIKwYBBQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNV HREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxs ZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYDVR0OBBYEFHL72L3FksyRMphJsUK0PoYmyIQ9MB8G A1UdIwQYMBaAFMlEVkqQE3yp8zMGa97QmbvnyM7pMIIBJgYDVR0fBIIBHTCCARkwggEVoIIBEaCC AQ2GgcRsZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049V0hJQ0EzLENOPUNEUCxDTj1Q dWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50 ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29i amVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hkRodHRwOi8vd2hpY2EzLm50ZGV2Lm1pY3Jv c29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElTU1VFMyUyMENBLmNybDCCAUIGCCsGAQUFBwEB BIIBNDCCATAwgb0GCCsGAQUFBzAChoGwbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENO PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVj dENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwbgYIKwYBBQUHMAKGYmh0dHA6Ly93aGljYTMu bnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL1dISUNBMy5udGRldi5taWNyb3NvZnQuY29t X05UREVWJTIwSVNTVUUzJTIwQ0EoMSkuY3J0MA0GCSqGSIb3DQEBBQUAA4GBAFf+QZur5gxtJiK7 QC75LGeLcLys77vN3Tr3ailS0rD+oXAY9oXYGFcAHaFUygfOAiQxDNinhuABsdyKfCCwHUUMkr7p jt/O9cEgnhGsM2okZGi6u9nrHDaN7d+EPM9hzreYIZz5lxOJ2aUFl3HuiszOUmV22rh1ClAnkKyn 1ZptMIIGjjCCBfegAwIBAgIKQPyrngAGABV2OjANBgkqhkiG9w0BAQUFADBiMRMwEQYKCZImiZPy LGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0MRUwEwYKCZImiZPyLGQBGRYFbnRk ZXYxGTAXBgNVBAMTEE5UREVWIElzc3VlNjQgQ0EwHhcNMDIwNzMxMDAwMjQyWhcNMDIwOTIwMjEz MzI4WjCBmjETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEV MBMGCgmSJomT8ixkARkWBW50ZGV2MRAwDgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5 TWFuYWdlZDERMA8GA1UECxMITG93VENPLUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAOU71leNXD/9bfcgs+tzFM6I8heI5sujO299Z/q++lwwFY0gR0ju C/72sc8MZ9TYQhxReqRTrwaDAQxl+7rjLP244jXFnzo+obpSDiIY9APSbJOMgJinbdBWRkGMBqy8 4qH3YOg9pTkkpITSFazLwXvr/IGqZLoW3IFq/HHR7OGdAgMBAAGjggQQMIIEDDALBgNVHQ8EBAMC B4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe 5oBUAgFxAgEDMBMGA1UdJQQMMAoGCCsGAQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDR iU6E15zDB4amhvscj9O/phUBgxEwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREE TDBKoCoGCisGAQQBgjcUAgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3 aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYDVR0OBBYEFCE8CMC/VepkzftXBD06OeKJdxp2MB8GA1Ud IwQYMBaAFCy2K2tgXiglYJqT6VCq3G8T9hPAMIIBewYDVR0fBIIBcjCCAW4wggFqoIIBZqCCAWKG gclsZGFwOi8vL0NOPU5UREVWJTIwSXNzdWU2NCUyMENBKDUpLENOPXdoaWNhNjQsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGSWh0dHA6Ly93aGljYTY0Lm50ZGV2Lm1p Y3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElzc3VlNjQlMjBDQSg1KS5jcmyGSWh0dHA6 Ly93aGljYTY0Lm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElzc3VlNjQl MjBDQSg1KS5jcmwwggFGBggrBgEFBQcBAQSCATgwggE0MIG+BggrBgEFBQcwAoaBsWxkYXA6Ly8v Q049TlRERVYlMjBJc3N1ZTY0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBx BggrBgEFBQcwAoZlaHR0cDovL3doaWNhNjQubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L3doaWNhNjQubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMElzc3VlNjQlMjBDQSg2KS5jcnQw DQYJKoZIhvcNAQEFBQADgYEAmxk1iyBSfJYeDZzKZYvd0fUJtCgb3XHlXXk5FSYIF9MhQIiNEqXr RCKqbZ04NAQ9GWNLd18TTKlCtyX58ExkQem0gopXqVz2vosiduGg3ClcNxft1VCuAsAeO3Ut+kCy roKF2c2Z1DXV2Xef0XTUopvr/GxnvETceAcFjhRr5xswgganMIIGEKADAgECAgoUXpdDAAAAAAAo MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNV BAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAxMTEwMTIwNTcxMVoXDTAy MDkyMDIxMzMyOFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwggG2 MIIBKwYHKoZIzjgEATCCAR4CgYEA+C8tsWT9/wRFSSpuX/EWDdw9JXBNItcNpQijM8iHGhCAvOLM MtYKSmNGeEfEQM4o/IUZMPHIl0+mreZoAx6O5Sd2j5hDrMcJ8ZDfIYWbOdITwbRhlbOgdYo1RGYh nU85Uy53iBXOjJOxxDL97D+0tSr1iQ5bPa60SWBZckwd+QECFQC6SuANG+2mus3kNWZDzwvYkXAo 3wKBgGe4TMedVC32vpClPeBaNRx93A3a0punW+cPKKsTiZI/fqmtt6fZJd3D3YqBrIQ0IxeCzvEf r0kTzP1BuYq+y5JBOror681wxhxdeguP2aDAHWR1O1BrbqB4SPdhpom5s15G4jFjcrw92IjNeD6v wWPURzVQvFdrblDXvmyde5ULA4GEAAKBgAZWBKiqZbwqp6gdR1nskDn0UOVCS7UkzRipC+jzwHG8 XVrDdSYg2piw8b5k12JvJFkrkZM0qqxj4rKTSAyzgJl0WO/bV+CFg/SKbFYRj/FOgu8nDc2aTTOm xLgUIAFVX30gWvfULKu4Eqz5JBQPBHopE6JcSjOXTjNNWdgRnaX5o4IDYTCCA10wEgYJKwYBBAGC NxUBBAUCAwEAAzAjBgkrBgEEAYI3FQIEFgQUGMUaNFgsr5GgGsVlgyKT+sb/FRUwHQYDVR0OBBYE FM/Fuhf/LccQgPW5DplKb/ScK/sZMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQE AwIBxjAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFHfJdGksOf44ZfSHBVgIzr26l9oQMIIB OgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgc5sZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290 JTIwQ0EsQ049d2hpY2FzYXJvb3RjYSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29t P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZOaHR0cDovL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5y b2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMIIBUwYIKwYBBQUHAQEEggFFMIIBQTCBwAYI KwYBBQUHMAKGgbNsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1 YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRk ZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2Vy dGlmaWNhdGlvbkF1dGhvcml0eTB8BggrBgEFBQcwAoZwaHR0cDovL3doaWNhc2Fyb290Y2EubnRk ZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0 LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBLmNydDAUBgNVHSABAf8ECjAIMAYGBFUdIAAwDQYJ KoZIhvcNAQEFBQADgYEAMWIlFJq094wxahPtYNIApwcYHwt5jJCEbVQN7EvgGQgeUHVcBzCJ+VW3 M/lB86vhikv30TNhE3dfcueigGjRSOTUiz7rr2SGLs8NEArFY29aNCQ0/GetHm66Cww7ZVzgZ5mr FY5nOTw8lSq5RrU8gi4livaGZDTVFeDif8a7op8xggK2MIICsgIBATBwMGIxEzARBgoJkiaJk/Is ZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJk/IsZAEZFgVudGRl djEZMBcGA1UEAxMQTlRERVYgSXNzdWU2NCBDQQIKQPyrngAGABV2OjAJBgUrDgMCGgUAoIIBnDAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA4MTQyMzEwMThaMCMG CSqGSIb3DQEJBDEWBBSr05epoKdfAKImoRMfs6rf+SOKlzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgkrBgEEAYI3EAQxWzBZMEsxCzAJBgNVBAYTAlVT MRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NV RTMgQ0ECCigdumoAAQAZXnkwagYLKoZIhvcNAQkQAgsxW6BZMEsxCzAJBgNVBAYTAlVTMRIwEAYD VQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EC CigdumoAAQAZXnkwDQYJKoZIhvcNAQEBBQAEgYDJ40S2zlE4Fg8DR0RPDYnTWfSvNLQLvSfQdNlt DOJ5u+1topp9PwGk9QuCV32yf94H75Xs9+pt+mFSEn1Jr2jgBu80HbpkXWmi7+MzqAwTiC4ueZGt ElsRi5bdpVNL1nEMQs0xHpl+g2nNhC4OUpDgb/AwHCOPTR8fKUHMxVBDJQAAAAAAAA== ------=_NextPart_000_0054_01C243AD.1563F230-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Aug 14 20:01:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28492 for ; Wed, 14 Aug 2002 20:01:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05105; Wed, 14 Aug 2002 20:00:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05039 for ; Wed, 14 Aug 2002 20:00:22 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28408 for ; Wed, 14 Aug 2002 19:59:01 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 14 Aug 2002 16:59:47 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 14 Aug 2002 16:59:47 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 14 Aug 2002 16:59:47 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 14 Aug 2002 16:59:47 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 14 Aug 2002 16:59:46 -0700 Content-Class: urn:content-classes:message Subject: RE: [ldapext] draft-ietf-ldapext-locate MIME-Version: 1.0 Date: Wed, 14 Aug 2002 16:59:45 -0700 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0058_01C243B3.FDDE0C70" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD04929810@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: [ldapext] draft-ietf-ldapext-locate thread-index: AcJDTC6DWRwDSQJYSAG8djb/EHEDaAAn4Enw From: "Paul Leach" To: "Kurt D. Zeilenga" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "Michael Armijo" , "Levon Esibov" , , , "Ned Freed" , X-OriginalArrivalTime: 14 Aug 2002 23:59:46.0916 (UTC) FILETIME=[AAF38A40:01C243EE] Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C243B3.FDDE0C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]=20 > Sent: Tuesday, August 13, 2002 21:36 > To: Patrik F=E4ltstr=F6m > Cc: Michael Armijo; Paul Leach; Levon Esibov;=20 > rlmorgan@washington.edu; ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > Subject: Re: [ldapext] draft-ietf-ldapext-locate >=20 > >(1) This document specifies two things: How to translate a=20 > DN to a DNS=20 > >name and how to use a DNS name to locate a corresponding LDAP server. >=20 > I argue that the document specifies one process, to locate=20 > LDAP servers with knowledge of a particular DN, which has two steps. >=20 > >The document seems to imply that the latter is only used when a DNS=20 > >name is produced by the former. I wonder if this restriction=20 > is a good=20 > >idea: Isn't the ability to use SRV records to locate more generally=20 > >useful than this limited context? >=20 > I don't believe this document restricts how DNS SRV records > can be used.=20 I think the real question being asked was "Isn't the ability to use SRV records to locate _LDAP servers_ more generally useful than this limited context?". If so, then I agree that it is more generally useful. Independently of DC laden DNs, ff one has the name of a domain, name, say "mit.edu", and wants to find LDAP servers associated with that domain, then it is logical that one should look up SRV RRs for "_ldap._tcp.mit.edu". However, I think that this capability is already adequately specified in RFC 2782 (DNS SRV RR RFC), where it says: "The format of the SRV RR Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target (There is an example near the end of this document.) Service The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. ..." In the case of LDAP, the symbolic name is "LDAP". If the question was really intended to NOT be LDAP specific, then it is clear that RFC 2782 is the place where the ability to use SRV records in general is specified. Paul =20 It also doesn't restrict construction of=20 > additional processes for locating LDAP servers with knowledge=20 > of a particular DN. In fact, draft-zeilenga-ldap-x500-locate=20 > suggests a process for DNs using geo-political naming. >=20 > Additionally, DNS SRVs could be used to answer questions such=20 > as "Are there LDAP servers associated with this domain?". Of=20 > course, this would be followed by, "What DN is used by the=20 > owner of this domain for their objects?". If a listed server=20 > provides 100s of namingContext, which one is the right one?=20 > Luckily, we have RFC 2247 which says how the owner of the=20 > domain should name objects. >=20 > >The answer to this may be no, but if so, the rationale for=20 > that answer=20 > >should be part of the specification. > > > >(2) I don't see any provision for fallback to A records if=20 > SRV records > > don't exist. I can easily see this being a Bad Idea,=20 > if so, there > > should be an explicit prohibition of it in the=20 > document along with > > some explanation of why it is a bad idea. >=20 > It is a bad idea. A short explanation would be appropriate. >=20 >=20 >=20 >=20 > >------- > >References should be split in normative and non-normative. > >------- > >I wonder about the reference to RFC1700, which has been obsoleted by=20 > >RFC3232, and that RFC actuallt talks about a DB that=20 > contains the info.=20 > >So How should this doc refer to that? > >------- > >Needs better abstract; doesn't even use the word "SRV". (and the rfc=20 > >editor will surely complain when they get it...) > > > >Might be good to use SRV in the title as well, as opposed to just=20 > >"DNS". But this I'm less concerned about, as there are two=20 > steps, and=20 > >only the second step is SRV records. > > > >E.g., maybe change: > > > > Discovering LDAP Services with DNS > > > >To something like: > > > > Discovering LDAP Services with DNS SRV Resource Records > > > >However, the rfc editor probably won't like the abbreviation "SRV".=20 > >Unfortunately, I don't think the acronym expands into=20 > anything useful. >=20 > SRV is not an abbreviation, but IANA-registered DNS RR Type.=20 > http://www.iana.org/assignments/dns-parameters >=20 >=20 > >------- > >I=20 > have three concerns here: >=20 > see above. >=20 > Kurt >=20 >=20 ------=_NextPart_000_0058_01C243B3.FDDE0C70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIipTCCA0Aw ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIFdzCCBTagAwIBAgIKbR8tRgADAAAB kjAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X DTAyMDEyOTAwMTYwMVoXDTAyMDkyMDIxMzMyOFowYjETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcG CgmSJomT8ixkARkWCW1pY3Jvc29mdDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRkwFwYDVQQDExBO VERFViBJc3N1ZTY0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCe7uH1+lUYtdzFSBiM LOSsVfDwSUU8V13PLZU4qYeC91SoFyZ2FLFxbMiqUpX0dmt5/WrJ4jerwBQlmheVkZ5i5E1zHyWh Im3xaScMBCJ4dj9Ax4sHIPCKiYPDfneDJbKbriZKqTwTvuoV+4H9AfcE88HQ+l52ecpW3I5A0DFk gQIDAQABo4IDjTCCA4kwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQULLYra2BeKCVgmpPpUKrc bxP2E8AwCwYDVR0PBAQDAgGGMBIGCSsGAQQBgjcVAQQFAgMFAAYwIwYJKwYBBAGCNxUCBBYEFFn6 2/e2PIGLWb3JaMwy6YMDvfPQMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaA FM/Fuhf/LccQgPW5DplKb/ScK/sZMIIBXAYDVR0fBIIBUzCCAU8wggFLoIIBR6CCAUOGgd9sZGFw Oi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoMSksQ049 d2hpY2EyLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hl9odHRwOi8v d2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMEludGVybWVkaWF0 ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDEpLmNybDCCAXMGCCsGAQUFBwEBBIIBZTCCAWEwgdUG CCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRl JTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0 ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgYYGCCsGAQUFBzAChnpo dHRwOi8vd2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYTIubnRkZXYu bWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2Ey KDMpLmNydDAJBgcqhkjOOAQDAzAAMC0CFQCTJcIxIcR6X/F39s4eRbklukPqkAIUdbQr5+2UZc7a 841oHuICRpJxdbswggY/MIIF/6ADAgECAgp1n/n0AAIAAAFWMAkGByqGSM44BAMwYTELMAkGA1UE BhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVW IEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcNMDEwOTE0MDMxNjUwWhcNMDIwOTIw MjEzMzI4WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRl djEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6 kcw3SUnD1p7YhzbJkEgIKp4/YfpF7gHVGeT4oRO0XRLXmOrt5rmf/7PjcNr0KqO6c0lotPutfij0 0dQ3t4/loqVntpE/4ShPTAHnU4+yNkq4Vam1t0vs8RUcC45Ss46PJnQhNHjfa+pwn8vcCi5PK4K4 3v/WTD20wxGXl6vORQIDAQABo4IEbTCCBGkwEAYJKwYBBAGCNxUBBAMCAQEwIwYJKwYBBAGCNxUC BBYEFF0wmXse4uyanN+uhOOORXrSKJ9VMB0GA1UdDgQWBBTJRFZKkBN8qfMzBmve0Jm758jO6TAZ BgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAf BgNVHSMEGDAWgBTPxboX/y3HEID1uQ6ZSm/0nCv7GTCCAj4GA1UdHwSCAjUwggIxMIICLaCCAimg ggIlhoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hp Y2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIZfaHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJ bnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKS5jcmyGgd9sZGFwOi8vL0NOPU5U REVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoMSksQ049d2hpY2EyLENO PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBcwYIKwYBBQUHAQEEggFl MIIBYTCB1QYIKwYBBQUHMAKGgchsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhgYIKwYB BQUHMAKGemh0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNh Mi5udGRldi5taWNyb3NvZnQuY29tX05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUl MjBXaGljYTIoMikuY3J0MAkGByqGSM44BAMDLwAwLAIUUx77g13BMwHgk+1QbyieLyToMN4CFHnb gTPU/Y/C05rO+kV3uJVgyD1oMIIGYjCCBcugAwIBAgIKKB26agABABleeTANBgkqhkiG9w0BAQUF ADBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYG A1UEAxMPTlRERVYgSVNTVUUzIENBMB4XDTAyMDcwODA4MjMwMloXDTAyMDkwNjA4MjMwMlowgccx EzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJ k/IsZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQx ETAPBgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxw YXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDc Ifu483kq/hLla0LcvAFNw84N4YiXBNCSTmx3/RB1oOsXsH776cr43a0fP7LgQVMliao0OXU97xwZ 4NR+fUtqTk/FGNhx/gvlz+5D6BerfBMES7p5nnC/djXHDCKOdfbf9gPtWxY1DjBDVEtw3C8aSGAc TnQY6yril8FzBnWaNQIDAQABo4IDzjCCA8owCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+Bgkr BgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXEC AQIwEwYDVR0lBAwwCgYIKwYBBQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNV HREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxs ZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYDVR0OBBYEFHL72L3FksyRMphJsUK0PoYmyIQ9MB8G A1UdIwQYMBaAFMlEVkqQE3yp8zMGa97QmbvnyM7pMIIBJgYDVR0fBIIBHTCCARkwggEVoIIBEaCC AQ2GgcRsZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049V0hJQ0EzLENOPUNEUCxDTj1Q dWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50 ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29i amVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hkRodHRwOi8vd2hpY2EzLm50ZGV2Lm1pY3Jv c29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElTU1VFMyUyMENBLmNybDCCAUIGCCsGAQUFBwEB BIIBNDCCATAwgb0GCCsGAQUFBzAChoGwbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENO PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVj dENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwbgYIKwYBBQUHMAKGYmh0dHA6Ly93aGljYTMu bnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL1dISUNBMy5udGRldi5taWNyb3NvZnQuY29t X05UREVWJTIwSVNTVUUzJTIwQ0EoMSkuY3J0MA0GCSqGSIb3DQEBBQUAA4GBAFf+QZur5gxtJiK7 QC75LGeLcLys77vN3Tr3ailS0rD+oXAY9oXYGFcAHaFUygfOAiQxDNinhuABsdyKfCCwHUUMkr7p jt/O9cEgnhGsM2okZGi6u9nrHDaN7d+EPM9hzreYIZz5lxOJ2aUFl3HuiszOUmV22rh1ClAnkKyn 1ZptMIIGjjCCBfegAwIBAgIKQPyrngAGABV2OjANBgkqhkiG9w0BAQUFADBiMRMwEQYKCZImiZPy LGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0MRUwEwYKCZImiZPyLGQBGRYFbnRk ZXYxGTAXBgNVBAMTEE5UREVWIElzc3VlNjQgQ0EwHhcNMDIwNzMxMDAwMjQyWhcNMDIwOTIwMjEz MzI4WjCBmjETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEV MBMGCgmSJomT8ixkARkWBW50ZGV2MRAwDgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5 TWFuYWdlZDERMA8GA1UECxMITG93VENPLUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAOU71leNXD/9bfcgs+tzFM6I8heI5sujO299Z/q++lwwFY0gR0ju C/72sc8MZ9TYQhxReqRTrwaDAQxl+7rjLP244jXFnzo+obpSDiIY9APSbJOMgJinbdBWRkGMBqy8 4qH3YOg9pTkkpITSFazLwXvr/IGqZLoW3IFq/HHR7OGdAgMBAAGjggQQMIIEDDALBgNVHQ8EBAMC B4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe 5oBUAgFxAgEDMBMGA1UdJQQMMAoGCCsGAQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDR iU6E15zDB4amhvscj9O/phUBgxEwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREE TDBKoCoGCisGAQQBgjcUAgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3 aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYDVR0OBBYEFCE8CMC/VepkzftXBD06OeKJdxp2MB8GA1Ud IwQYMBaAFCy2K2tgXiglYJqT6VCq3G8T9hPAMIIBewYDVR0fBIIBcjCCAW4wggFqoIIBZqCCAWKG gclsZGFwOi8vL0NOPU5UREVWJTIwSXNzdWU2NCUyMENBKDUpLENOPXdoaWNhNjQsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGSWh0dHA6Ly93aGljYTY0Lm50ZGV2Lm1p Y3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElzc3VlNjQlMjBDQSg1KS5jcmyGSWh0dHA6 Ly93aGljYTY0Lm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElzc3VlNjQl MjBDQSg1KS5jcmwwggFGBggrBgEFBQcBAQSCATgwggE0MIG+BggrBgEFBQcwAoaBsWxkYXA6Ly8v Q049TlRERVYlMjBJc3N1ZTY0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBx BggrBgEFBQcwAoZlaHR0cDovL3doaWNhNjQubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L3doaWNhNjQubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMElzc3VlNjQlMjBDQSg2KS5jcnQw DQYJKoZIhvcNAQEFBQADgYEAmxk1iyBSfJYeDZzKZYvd0fUJtCgb3XHlXXk5FSYIF9MhQIiNEqXr RCKqbZ04NAQ9GWNLd18TTKlCtyX58ExkQem0gopXqVz2vosiduGg3ClcNxft1VCuAsAeO3Ut+kCy roKF2c2Z1DXV2Xef0XTUopvr/GxnvETceAcFjhRr5xswgganMIIGEKADAgECAgoUXpdDAAAAAAAo MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNV BAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAxMTEwMTIwNTcxMVoXDTAy MDkyMDIxMzMyOFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwggG2 MIIBKwYHKoZIzjgEATCCAR4CgYEA+C8tsWT9/wRFSSpuX/EWDdw9JXBNItcNpQijM8iHGhCAvOLM MtYKSmNGeEfEQM4o/IUZMPHIl0+mreZoAx6O5Sd2j5hDrMcJ8ZDfIYWbOdITwbRhlbOgdYo1RGYh nU85Uy53iBXOjJOxxDL97D+0tSr1iQ5bPa60SWBZckwd+QECFQC6SuANG+2mus3kNWZDzwvYkXAo 3wKBgGe4TMedVC32vpClPeBaNRx93A3a0punW+cPKKsTiZI/fqmtt6fZJd3D3YqBrIQ0IxeCzvEf r0kTzP1BuYq+y5JBOror681wxhxdeguP2aDAHWR1O1BrbqB4SPdhpom5s15G4jFjcrw92IjNeD6v wWPURzVQvFdrblDXvmyde5ULA4GEAAKBgAZWBKiqZbwqp6gdR1nskDn0UOVCS7UkzRipC+jzwHG8 XVrDdSYg2piw8b5k12JvJFkrkZM0qqxj4rKTSAyzgJl0WO/bV+CFg/SKbFYRj/FOgu8nDc2aTTOm xLgUIAFVX30gWvfULKu4Eqz5JBQPBHopE6JcSjOXTjNNWdgRnaX5o4IDYTCCA10wEgYJKwYBBAGC NxUBBAUCAwEAAzAjBgkrBgEEAYI3FQIEFgQUGMUaNFgsr5GgGsVlgyKT+sb/FRUwHQYDVR0OBBYE FM/Fuhf/LccQgPW5DplKb/ScK/sZMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQE AwIBxjAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFHfJdGksOf44ZfSHBVgIzr26l9oQMIIB OgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgc5sZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290 JTIwQ0EsQ049d2hpY2FzYXJvb3RjYSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29t P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZOaHR0cDovL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5y b2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMIIBUwYIKwYBBQUHAQEEggFFMIIBQTCBwAYI KwYBBQUHMAKGgbNsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1 YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRk ZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2Vy dGlmaWNhdGlvbkF1dGhvcml0eTB8BggrBgEFBQcwAoZwaHR0cDovL3doaWNhc2Fyb290Y2EubnRk ZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0 LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBLmNydDAUBgNVHSABAf8ECjAIMAYGBFUdIAAwDQYJ KoZIhvcNAQEFBQADgYEAMWIlFJq094wxahPtYNIApwcYHwt5jJCEbVQN7EvgGQgeUHVcBzCJ+VW3 M/lB86vhikv30TNhE3dfcueigGjRSOTUiz7rr2SGLs8NEArFY29aNCQ0/GetHm66Cww7ZVzgZ5mr FY5nOTw8lSq5RrU8gi4livaGZDTVFeDif8a7op8xggK2MIICsgIBATBwMGIxEzARBgoJkiaJk/Is ZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJk/IsZAEZFgVudGRl djEZMBcGA1UEAxMQTlRERVYgSXNzdWU2NCBDQQIKQPyrngAGABV2OjAJBgUrDgMCGgUAoIIBnDAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA4MTQyMzU5NDVaMCMG CSqGSIb3DQEJBDEWBBRl7pgtz3SoX4ckYuO5O6+L/v3SWDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgkrBgEEAYI3EAQxWzBZMEsxCzAJBgNVBAYTAlVT MRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NV RTMgQ0ECCigdumoAAQAZXnkwagYLKoZIhvcNAQkQAgsxW6BZMEsxCzAJBgNVBAYTAlVTMRIwEAYD VQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EC CigdumoAAQAZXnkwDQYJKoZIhvcNAQEBBQAEgYB+Db6HGJbUoe6QLsfSZCcKzRc9cSehkENh3csf TCmwNM8fxMSMMyG8hI25FJ+tW5O/bOxP9hrvy4rVu5tklzuHb0Rw6EWAzIA00TJbtIYu4ub7UENd weDWhAtuBWTH0XBlGE8DNDBtuS5vTSKxdhNUjQZ/GP4poaUIl2IvymnE9gAAAAAAAA== ------=_NextPart_000_0058_01C243B3.FDDE0C70-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Aug 14 22:54:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02130 for ; Wed, 14 Aug 2002 22:54:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13712; Wed, 14 Aug 2002 22:51:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13680 for ; Wed, 14 Aug 2002 22:51:46 -0400 (EDT) Received: from wstutil12a.ml.com (wstutil12a-v.ml.com [209.65.19.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02076 for ; Wed, 14 Aug 2002 22:50:26 -0400 (EDT) Received: from wstutil13a.ml.com (wstutil13a [146.125.185.11]) by wstutil12a.ml.com (8.11.3/8.11.3/wstutil12a-1.2) with ESMTP id g7F2pkd07594; Wed, 14 Aug 2002 22:51:46 -0400 (EDT) Received: from ewstwt01.exchange.ml.com (ewstwt01.exchange.ml.com [146.125.249.151]) by wstutil13a.ml.com (8.11.3/8.11.3/wstutil13a-1.1) with SMTP id g7F2pj110837; Wed, 14 Aug 2002 22:51:45 -0400 (EDT) Received: from 169.242.226.175 by ewstwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Wed, 14 Aug 2002 22:51:44 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ehope08.hew.us.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Wed, 14 Aug 2002 22:51:45 -0400 Message-ID: <9B5CBD4986A9D511BE2100065B045DDF0238BD41@ehope21.hew.us.ml.com> From: "Liben, Michael (GTS)" To: "'christine.yoon@us.pwcglobal.com'" , ereed@novell.com, paf@cisco.com, alexis.bor@directoryworks.com, "Liben, Michael (GTS)" cc: ldapext@ietf.org Subject: RE: [ldapext] draft-ietf-ldapext-locate Date: Wed, 14 Aug 2002 22:51:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 1145C8CA41170-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7bit I agree. It has been my experience that well-designed client applications will query directory objects based on one or more attributes and value(s). The organization of the DIT is reserved for administrative purposes. It should not be up to the client application to divine any relevant information from the distinguished name of an object. -----Original Message----- From: christine.yoon@us.pwcglobal.com [mailto:christine.yoon@us.pwcglobal.com] Sent: Wednesday, August 14, 2002 6:53 PM To: ereed@novell.com; paf@cisco.com; alexis.bor@directoryworks.com; mliben@exchange.ml.com; christine.yoon@us.pwcglobal.com Cc: ldapext@ietf.org Subject: RE: [ldapext] draft-ietf-ldapext-locate I don't disagree with your saying As for naming - there is no right answer - it's a matter for local politics and engineering to work out. In fact, use of the hierarchical names in DNs for a private company having global presence may be necessary. Because the company may have different ways to operate/administer the directory depending on different regions/countries. However, I think that it is better to avoid the hierarchical names (if can) so that directory users (applications, end users) do not use the semantics at all. My thought on the directory naming best pratice is not to make a set of specific naming recomendations , but to address a set of alternative approaches with issues/risks. -Christine Yoon PricewaterhouseCoopers . "Ed Reed" To: , , , 08/14/2002 05:29 Christine Yoon/US/ABAS/PwC@Americas-US PM cc: Subject: RE: [ldapext] draft-ietf-ldapext-locate Sorry, this conversation takes me back to wondering why 48 bit mac addresses aren't sufficient as names... What is the purpose of prohibiting the use the hierarchical name, whether DN or DNS, to gather information about the support and policies of an organization? Has that practice, of searching for authoritative MX records for a host name, proven so broken that we don't want to use it as a way to find LDAP servers for a DN, either? I don't think I'm mixing metaphores, here...I see a convergence in DNs and DNS names over the long run. I must not recall the problem we're trying to avoid, here. As for naming - there is no right answer - it's a matter for local politics and engineering to work out. "What this directory needs is a good secondary index". And thus was born a never ending stream of catalogues and centroids. Ed =============== Edwards E Reed Novell, Inc. +1 585 624 2402 >>> 08/14/02 05:14PM >>> Is this (Directory best practices) something that one of the IETF ldap working groups can do? If so, I would like to contribute. I represent PricewaterhouseCoopers (PwC) and am working on Security Integration practices. We (PwC) have implemented many directory services for various clients. What is the process to initiate such work? Please advise. -Christine Yoon PricewaterhouseCoopers (201)981-1172 (cell) (732)706-3559 (office) "Alexis Bor" , "'Patrik Fältström'" yworks.com> Sent by: cc: ldapext-admin@ietf.o Subject: RE: [ldapext] draft-ietf-ldapext-locate rg 08/14/2002 04:00 PM I proved to myself and others (while I was at Boeing doing R&D work in Directory) back in 1992 that putting any meaning into a DN is not a good practice. We took the example of a company of 100,000 and looked at the different approaches for DN's - Geographic, Political, Hybrid and others. It became clear that it would be a maintenance headache and cause lots of stress on the overall infrastructure. It was very hard to convince most people for a long time until some work that Jeff Hodges did at Stanford got a lot of attention in the late 90's. A real hard piece of work to put forward is a best practices document. The number of opinions will typically exceed the number of people working on the document. What we learned in the mid 90's was that such a document evolves faster than the review cycle (part of an EMA effort to write a white paper on directory best practices), making it out of date before you even finish the review of it. However, with all of the experience that everyone is getting, it may be worth resurrecting the idea again. Perhaps an industry group can step up to the challenge - any takers? -- Alexis Alexis Bor Directory Works, Inc. www.directoryworks.com -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf Of Liben, Michael (GTS) Sent: Tuesday, August 13, 2002 5:32 PM To: 'Patrik Fältström' Cc: ldapext@ietf.org Subject: RE: [ldapext] draft-ietf-ldapext-locate In general, divining any meaning from a distinguished name is not good practice (my $.02). The implications are that your app will likely break. The SHOULD NOT allows you impart meaning to your distinguished name if you so choose. A MUST NOT would be an absolute prohibition. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, August 13, 2002 5:54 AM To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; rlmorgan@washington.edu Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se Subject: [ldapext] draft-ietf-ldapext-locate Comments from the IESG: ------- The document says: If there are no matching SRV records available for the converted DN the client SHOULD NOT attempt to 'walk the tree' by removing the least significant portion of the constructed fully qualified domain name. The meaning of "SHOULD NOT" is "don't do this unless you understand the implications". Well, I don't know where to look to understand the implications. Thus I think it would be useful to either make it a MUST NOT, or explain something about the implications of using shorter labels. Alternatively specify SHOULD NOT do this in general, but MUST NOT ever use this with just one label (i.e. MUST NOT look for _ldap._tcp.) or something similar. ------- The document is unclear (see next note) on: (a) When this is to be used (only when not having the foggiest clue where a record with a specific DN is, or every time a record is to be accessed?) (b) How to handle the case when one have a DN which have both dc and non-dc components. Example of this is when two records stored on two different servers share the same dc components. IF those records per definition (of this document) have to be stored on the same server, or referrals have to be stored on them to point to the other, then this document has a scope which is larger than at first glance. I.e. part from stating how to locate a record using DNS, it also has an implicit result that DC is _the_ naming convention for the Internet. Please explain. ------- This document define a conversion that is over-restrictive. The output domain name is initially empty. The DN is processed in right-to-left order (i.e., beginning with the first RDN in the sequence of RDNs). An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue; (2) the attribute type is "DC"; and (3) the attribute value is non-null. If it can be converted, the attribute value is used as a domain name component (label). The first such value becomes the rightmost (i.e., most significant) domain name component, and successive converted RDN values extend to the left. If an RDN cannot be converted, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ processing stops. If the output domain name is empty when ^^^^^^^^^^^^^^^^^ processing stops, the DN cannot be converted into a domain name. The underscored text should be removed and replaced with text that states the non-DC RDN's are skipped over. So for example the DN: cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, dc=edu Can be unambiguously translated into: lees.mit.edu Yet the underscored words make this translation invalid. With the Underscored rule in place this DN would convert to just 'mit.edu' which is not the desired result. The additional flexibility offered will permit us to convert existing PKI systems to make use of this feature without requiring all certificates to be re-issued. It will also permit us to create DIT's that can be delegated at more points rather then requiring all structure to be at the very top where the DC components are, prior to any non-DC component. For example if MIT had a DIT with a top level name of: o=MIT,c=US and a subordinate lab wanted to use this document, they could have a delegated subtree like: ou=Lab for X,o=MIT,c=US and then add a DC component below this as: dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US Under my more flexible approach this would work. Without the flexibility they would be SOL until MIT redid its entire DIT to be: o=MIT,c=US,dc=mit,dc=edu and then they would have to be jointed in as: o=MIT,c=US,dc=labx,dc=mit,dc=edu Ned: I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. ------- References should be split in normative and non-normative. ------- I wonder about the reference to RFC1700, which has been obsoleted by RFC3232, and that RFC actuallt talks about a DB that contains the info. So How should this doc refer to that? ------- Needs better abstract; doesn't even use the word "SRV". (and the rfc editor will surely complain when they get it...) Might be good to use SRV in the title as well, as opposed to just "DNS". But this I'm less concerned about, as there are two steps, and only the second step is SRV records. E.g., maybe change: Discovering LDAP Services with DNS To something like: Discovering LDAP Services with DNS SRV Resource Records However, the rfc editor probably won't like the abbreviation "SRV". Unfortunately, I don't think the acronym expands into anything useful. ------- I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. _______________________________________________ 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 _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 06:24:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19831 for ; Thu, 15 Aug 2002 06:24:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17970; Thu, 15 Aug 2002 06:16:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17940 for ; Thu, 15 Aug 2002 06:16:45 -0400 (EDT) Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19637 for ; Thu, 15 Aug 2002 06:15:23 -0400 (EDT) Received: from CHRIS-H.opengroup.org (dhcp192-153-166-32.rdg.opengroup.org [192.153.166.32]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id g7FAG3Q11045; Thu, 15 Aug 2002 11:16:03 +0100 Message-Id: <5.1.0.14.1.20020815110209.00affd40@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 Aug 2002 11:20:02 +0100 To: "Alexis Bor" From: Chris Harding Subject: RE: [ldapext] draft-ietf-ldapext-locate Cc: , "'Liben, Michael \(GTS\)'" , "'Patrik Fältström'" , dif-members@opengroup.org In-Reply-To: <004401c243cd$4a94fd30$f609cda8@directoryworks.com> References: <9B5CBD4986A9D511BE2100065B045DDF0238BD26@ehope21.hew.us.ml.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit Hi, Alexis - A Directory Best Practices Guide is something that is clearly needed. I believe that the Directory Interoperability Forum should support its creation and contribute to it. The DIF could for example provide publication or web page hosting facilities if needed, and could provide some review effort. However, I don't believe that the DIF could on its own provide the technical authoring and review effort needed to deliver an authoritative guide. Because there is (as you point out) a need for rapid evolution, a set of web pages would be far and away the best medium for such a guide. What we need is a set of contributors, a review group, and an editorial committee, working within the framework of an established review and publications procedure. This procedure must be public and must allow rapid turnaround from authoring to publication - I would say within 2 months at the outside. Perhaps it could be handled as a kind of Open Source project. I believe (the members make the decisions, I just support them) that the DIF would be interested in co-ordinating or participating in a project of this nature. At 16:00 14/08/2002 -0400, Alexis Bor wrote: >I proved to myself and others (while I was at Boeing doing R&D work in >Directory) back in 1992 that putting any meaning into a DN is not a good >practice. We took the example of a company of 100,000 and looked at the >different approaches for DN's - Geographic, Political, Hybrid and >others. > >It became clear that it would be a maintenance headache and cause lots >of stress on the overall infrastructure. It was very hard to convince >most people for a long time until some work that Jeff Hodges did at >Stanford got a lot of attention in the late 90's. > >A real hard piece of work to put forward is a best practices document. >The number of opinions will typically exceed the number of people >working on the document. What we learned in the mid 90's was that such >a document evolves faster than the review cycle (part of an EMA effort >to write a white paper on directory best practices), making it out of >date before you even finish the review of it. However, with all of the >experience that everyone is getting, it may be worth resurrecting the >idea again. > >Perhaps an industry group can step up to the challenge - any takers? > >-- Alexis > >Alexis Bor >Directory Works, Inc. >www.directoryworks.com > > >-----Original Message----- >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf >Of Liben, Michael (GTS) >Sent: Tuesday, August 13, 2002 5:32 PM >To: 'Patrik Fältström' >Cc: ldapext@ietf.org >Subject: RE: [ldapext] draft-ietf-ldapext-locate > >In general, divining any meaning from a distinguished name is not good >practice (my $.02). The implications are that your app will likely >break. The SHOULD NOT allows you impart meaning to your >distinguished name if you so choose. A MUST NOT would be an absolute >prohibition. > > > >-----Original Message----- >From: Patrik Fältström [mailto:paf@cisco.com] >Sent: Tuesday, August 13, 2002 5:54 AM >To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; >rlmorgan@washington.edu >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se >Subject: [ldapext] draft-ietf-ldapext-locate > >Comments from the IESG: >------- >The document says: > If there are no > matching SRV records available for the converted DN the client >SHOULD > NOT attempt to 'walk the tree' by removing the least significant > portion of the constructed fully qualified domain name. > >The meaning of "SHOULD NOT" is "don't do this unless you understand the >implications". Well, I don't know where to look to understand the >implications. >Thus I think it would be useful to either make it a MUST NOT, or explain >something about the implications of using shorter labels. > >Alternatively specify SHOULD NOT do this in general, but MUST NOT ever >use this with just one label (i.e. MUST NOT look for _ldap._tcp.) >or something similar. > >------- >The document is unclear (see next note) on: > >(a) When this is to be used (only when not having the foggiest clue >where a >record with a specific DN is, or every time a record is to be accessed?) > >(b) How to handle the case when one have a DN which have both dc and >non-dc >components. Example of this is when two records stored on two different >servers share the same dc components. IF those records per definition >(of >this document) have to be stored on the same server, or referrals have >to >be stored on them to point to the other, then this document has a scope >which is larger than at first glance. I.e. part from stating how to >locate >a record using DNS, it also has an implicit result that DC is _the_ >naming >convention for the Internet. Please explain. > >------- >This document define a conversion that is over-restrictive. > > The output domain name is initially empty. The DN is processed >in > right-to-left order (i.e., beginning with the first RDN in the > sequence of RDNs). An RDN is able to be converted if it (1) > consists of a single AttributeTypeAndValue; (2) the attribute >type > is "DC"; and (3) the attribute value is non-null. If it can be > converted, the attribute value is used as a domain name >component > (label). The first such value becomes the rightmost (i.e., most > significant) domain name component, and successive converted RDN > values extend to the left. If an RDN cannot be converted, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > processing stops. If the output domain name is empty when > ^^^^^^^^^^^^^^^^^ > processing stops, the DN cannot be converted into a domain name. > >The underscored text should be removed and replaced with text that >states the non-DC RDN's are skipped over. So for example the DN: > > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, > dc=edu > >Can be unambiguously translated into: > > lees.mit.edu > >Yet the underscored words make this translation invalid. With the >Underscored rule in place this DN would convert to just 'mit.edu' >which is not the desired result. > >The additional flexibility offered will permit us to convert existing >PKI systems to make use of this feature without requiring all >certificates to be re-issued. It will also permit us to create DIT's >that can be delegated at more points rather then requiring all >structure to be at the very top where the DC components are, prior to >any non-DC component. > >For example if MIT had a DIT with a top level name of: > > o=MIT,c=US > >and a subordinate lab wanted to use this document, they could have a >delegated subtree like: > > ou=Lab for X,o=MIT,c=US > >and then add a DC component below this as: > > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US > >Under my more flexible approach this would work. Without the >flexibility they would be SOL until MIT redid its entire DIT to >be: > > o=MIT,c=US,dc=mit,dc=edu > >and then they would have to be jointed in as: > > o=MIT,c=US,dc=labx,dc=mit,dc=edu > >Ned: I have three concerns here: > >(0) It isn't clear when this approach is supposed to be used. DNs are an > integral part of *every* LDAP operation. Is it the intent that >an >LDAP > client check every DN it sees for DC fields and if it finds them >use > this approach. Or is it only appropriate in specific situations? > >(1) This document specifies two things: How to translate a DN to a DNS > name and how to use a DNS name to locate a corresponding LDAP >server. > The document seems to imply that the latter is only used when a >DNS > name is produced by the former. I wonder if this restriction is >a >good > idea: Isn't the ability to use SRV records to locate more >generally > useful than this limited context? > > The answer to this may be no, but if so, the rationale for that >answer > should be part of the specification. > >(2) I don't see any provision for fallback to A records if SRV records > don't exist. I can easily see this being a Bad Idea, if so, >there > should be an explicit prohibition of it in the document along >with > some explanation of why it is a bad idea. > > > >------- >References should be split in normative and non-normative. >------- >I wonder about the reference to RFC1700, which has been obsoleted >by RFC3232, and that RFC actuallt talks about a DB that contains >the info. So How should this doc refer to that? >------- >Needs better abstract; doesn't even use the word "SRV". (and the rfc >editor will surely complain when they get it...) > >Might be good to use SRV in the title as well, as opposed to just >"DNS". But this I'm less concerned about, as there are two steps, and >only the second step is SRV records. > >E.g., maybe change: > > Discovering LDAP Services with DNS > >To something like: > > Discovering LDAP Services with DNS SRV Resource Records > >However, the rfc editor probably won't like the abbreviation >"SRV". Unfortunately, I don't think the acronym expands into anything >useful. >------- >I have three concerns here: > >(0) It isn't clear when this approach is supposed to be used. DNs are an > integral part of *every* LDAP operation. Is it the intent that an >LDAP > client check every DN it sees for DC fields and if it finds them use > this approach. Or is it only appropriate in specific situations? > >(1) This document specifies two things: How to translate a DN to a DNS > name and how to use a DNS name to locate a corresponding LDAP >server. > The document seems to imply that the latter is only used when a DNS > name is produced by the former. I wonder if this restriction is a >good > idea: Isn't the ability to use SRV records to locate more generally > useful than this limited context? > > The answer to this may be no, but if so, the rationale for that >answer > should be part of the specification. > >(2) I don't see any provision for fallback to A records if SRV records > don't exist. I can easily see this being a Bad Idea, if so, there > should be an explicit prohibition of it in the document along with > some explanation of why it is a bad idea. > > > > > >_______________________________________________ >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 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 ======================================================================== The Open Group Conference Boundaryless Information Flow: The Role of Open Source Cannes, France, 14-18th October http://www.opengroup.org/cannes2002 ======================================================================== _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 06:46:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20194 for ; Thu, 15 Aug 2002 06:46:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19731; Thu, 15 Aug 2002 06:36:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19703 for ; Thu, 15 Aug 2002 06:36:51 -0400 (EDT) Received: from lists.su.se (lists.su.se [130.237.162.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20047 for ; Thu, 15 Aug 2002 06:35:29 -0400 (EDT) Received: from it.su.se (klapautius.it.su.se [130.237.95.23]) by lists.su.se (8.11.6/8.11.6) with ESMTP id g7FAaRM28044; Thu, 15 Aug 2002 12:36:27 +0200 Message-ID: <3D5B842E.70008@it.su.se> Date: Thu, 15 Aug 2002 12:36:30 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Leach CC: "Kurt D. Zeilenga" , =?ISO-8859-1?Q?Patrik_F=E4l?= =?ISO-8859-1?Q?tstr=F6m?= , Michael Armijo , Levon Esibov , rlmorgan@washington.edu, ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se, roland@catalogix.se, D.W.Chadwick@salford.ac.uk Subject: Re: [ldapext] draft-ietf-ldapext-locate References: <4AEE3169443CDD4796CA8A00B02191CD0492980F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7bit Paul Leach wrote: >>-----Original Message----- snip > In addition, I at least don't know that I understand the PK scenario > very well. > If I have a certificate for user with DN "X" in my hands, why do I need > to locate an LDAP server for DN X? Certainly not to get the cert for > that user, which seems like the most obvious reason. If I don't have > such a cert, how did I get the user's DN? Isn't it more likely that I > know the user's email address and want to get their cert so as to send > them S/MIME protected email? Also, I know that cert chains contain I think cert path construction is a better application to think about. You have the issuer name and need to find the issuer cert. This is a real problem but it arises from the fact that most pki applications have used the issuer and subject DN fields both as "display" names and adresses (into a instead of using subjectAltName to locate certificates. This is a misstake and the current discussion about what meaning to assign to DN's in the context of certificates and ldap is a result of the fact that DN's in ldap are *only* used as adresses whereas DN's in certificates are both used as addresses (into something -- the global DIT -- which doesn't even exist) and as a source of displayable user information. leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 10:52:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28694 for ; Thu, 15 Aug 2002 10:52:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03120; Thu, 15 Aug 2002 10:41:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03054 for ; Thu, 15 Aug 2002 10:41:26 -0400 (EDT) Received: from uxtpaprx1.nam.pwcinternal.com (uxtpaprx1.pwcglobal.com [155.201.16.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28154 for ; Thu, 15 Aug 2002 10:40:07 -0400 (EDT) From: christine.yoon@us.pwcglobal.com Received: from us-amsmta005.nam.pwcinternal.com (us-amsmta005.nam.pwcinternal.com [10.26.104.89]) by uxtpaprx1.nam.pwcinternal.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7FEeXg07184; Thu, 15 Aug 2002 10:40:33 -0400 (EDT) Subject: RE: [ldapext] draft-ietf-ldapext-locate To: c.harding@opengroup.org, "Alexis Bor" Cc: , "'Liben, Michael \(GTS\)'" , "'Patrik =?iso-8859-1?Q?F=E4ltstr=F6m'?=" , dif-members@opengroup.org, michael.d.compton@us.pwcglobal.com, jamie.quick@us.pwcglobal.com, brian.jensen@us.pwcglobal.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 15 Aug 2002 10:40:23 -0400 X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.9 |November 16, 2001) at 08/15/2002 10:40:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA03055 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit Chris, We (PwC) have many years of experience in directory/security implementation for various clients including Fortune 500 companies. I would like to volunteer to author the Directory Best Practice Guide. -Christine Yoon PricewaterhouseCoopers (201)981-1172 - cell (732)706-3559 - office Chris Harding up.org> cc: , "'Liben, Michael \(GTS\)'" , "'Patrik Sent by: Fältström'" , dif-members@opengroup.org ldapext-admin@ietf Subject: RE: [ldapext] draft-ietf-ldapext-locate .org 08/15/2002 06:20 AM Hi, Alexis - A Directory Best Practices Guide is something that is clearly needed. I believe that the Directory Interoperability Forum should support its creation and contribute to it. The DIF could for example provide publication or web page hosting facilities if needed, and could provide some review effort. However, I don't believe that the DIF could on its own provide the technical authoring and review effort needed to deliver an authoritative guide. Because there is (as you point out) a need for rapid evolution, a set of web pages would be far and away the best medium for such a guide. What we need is a set of contributors, a review group, and an editorial committee, working within the framework of an established review and publications procedure. This procedure must be public and must allow rapid turnaround from authoring to publication - I would say within 2 months at the outside. Perhaps it could be handled as a kind of Open Source project. I believe (the members make the decisions, I just support them) that the DIF would be interested in co-ordinating or participating in a project of this nature. At 16:00 14/08/2002 -0400, Alexis Bor wrote: >I proved to myself and others (while I was at Boeing doing R&D work in >Directory) back in 1992 that putting any meaning into a DN is not a good >practice. We took the example of a company of 100,000 and looked at the >different approaches for DN's - Geographic, Political, Hybrid and >others. > >It became clear that it would be a maintenance headache and cause lots >of stress on the overall infrastructure. It was very hard to convince >most people for a long time until some work that Jeff Hodges did at >Stanford got a lot of attention in the late 90's. > >A real hard piece of work to put forward is a best practices document. >The number of opinions will typically exceed the number of people >working on the document. What we learned in the mid 90's was that such >a document evolves faster than the review cycle (part of an EMA effort >to write a white paper on directory best practices), making it out of >date before you even finish the review of it. However, with all of the >experience that everyone is getting, it may be worth resurrecting the >idea again. > >Perhaps an industry group can step up to the challenge - any takers? > >-- Alexis > >Alexis Bor >Directory Works, Inc. >www.directoryworks.com > > >-----Original Message----- >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf >Of Liben, Michael (GTS) >Sent: Tuesday, August 13, 2002 5:32 PM >To: 'Patrik Fältström' >Cc: ldapext@ietf.org >Subject: RE: [ldapext] draft-ietf-ldapext-locate > >In general, divining any meaning from a distinguished name is not good >practice (my $.02). The implications are that your app will likely >break. The SHOULD NOT allows you impart meaning to your >distinguished name if you so choose. A MUST NOT would be an absolute >prohibition. > > > >-----Original Message----- >From: Patrik Fältström [mailto:paf@cisco.com] >Sent: Tuesday, August 13, 2002 5:54 AM >To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; >rlmorgan@washington.edu >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se >Subject: [ldapext] draft-ietf-ldapext-locate > >Comments from the IESG: >------- >The document says: > If there are no > matching SRV records available for the converted DN the client >SHOULD > NOT attempt to 'walk the tree' by removing the least significant > portion of the constructed fully qualified domain name. > >The meaning of "SHOULD NOT" is "don't do this unless you understand the >implications". Well, I don't know where to look to understand the >implications. >Thus I think it would be useful to either make it a MUST NOT, or explain >something about the implications of using shorter labels. > >Alternatively specify SHOULD NOT do this in general, but MUST NOT ever >use this with just one label (i.e. MUST NOT look for _ldap._tcp.) >or something similar. > >------- >The document is unclear (see next note) on: > >(a) When this is to be used (only when not having the foggiest clue >where a >record with a specific DN is, or every time a record is to be accessed?) > >(b) How to handle the case when one have a DN which have both dc and >non-dc >components. Example of this is when two records stored on two different >servers share the same dc components. IF those records per definition >(of >this document) have to be stored on the same server, or referrals have >to >be stored on them to point to the other, then this document has a scope >which is larger than at first glance. I.e. part from stating how to >locate >a record using DNS, it also has an implicit result that DC is _the_ >naming >convention for the Internet. Please explain. > >------- >This document define a conversion that is over-restrictive. > > The output domain name is initially empty. The DN is processed >in > right-to-left order (i.e., beginning with the first RDN in the > sequence of RDNs). An RDN is able to be converted if it (1) > consists of a single AttributeTypeAndValue; (2) the attribute >type > is "DC"; and (3) the attribute value is non-null. If it can be > converted, the attribute value is used as a domain name >component > (label). The first such value becomes the rightmost (i.e., most > significant) domain name component, and successive converted RDN > values extend to the left. If an RDN cannot be converted, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > processing stops. If the output domain name is empty when > ^^^^^^^^^^^^^^^^^ > processing stops, the DN cannot be converted into a domain name. > >The underscored text should be removed and replaced with text that >states the non-DC RDN's are skipped over. So for example the DN: > > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, > dc=edu > >Can be unambiguously translated into: > > lees.mit.edu > >Yet the underscored words make this translation invalid. With the >Underscored rule in place this DN would convert to just 'mit.edu' >which is not the desired result. > >The additional flexibility offered will permit us to convert existing >PKI systems to make use of this feature without requiring all >certificates to be re-issued. It will also permit us to create DIT's >that can be delegated at more points rather then requiring all >structure to be at the very top where the DC components are, prior to >any non-DC component. > >For example if MIT had a DIT with a top level name of: > > o=MIT,c=US > >and a subordinate lab wanted to use this document, they could have a >delegated subtree like: > > ou=Lab for X,o=MIT,c=US > >and then add a DC component below this as: > > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US > >Under my more flexible approach this would work. Without the >flexibility they would be SOL until MIT redid its entire DIT to >be: > > o=MIT,c=US,dc=mit,dc=edu > >and then they would have to be jointed in as: > > o=MIT,c=US,dc=labx,dc=mit,dc=edu > >Ned: I have three concerns here: > >(0) It isn't clear when this approach is supposed to be used. DNs are an > integral part of *every* LDAP operation. Is it the intent that >an >LDAP > client check every DN it sees for DC fields and if it finds them >use > this approach. Or is it only appropriate in specific situations? > >(1) This document specifies two things: How to translate a DN to a DNS > name and how to use a DNS name to locate a corresponding LDAP >server. > The document seems to imply that the latter is only used when a >DNS > name is produced by the former. I wonder if this restriction is >a >good > idea: Isn't the ability to use SRV records to locate more >generally > useful than this limited context? > > The answer to this may be no, but if so, the rationale for that >answer > should be part of the specification. > >(2) I don't see any provision for fallback to A records if SRV records > don't exist. I can easily see this being a Bad Idea, if so, >there > should be an explicit prohibition of it in the document along >with > some explanation of why it is a bad idea. > > > >------- >References should be split in normative and non-normative. >------- >I wonder about the reference to RFC1700, which has been obsoleted >by RFC3232, and that RFC actuallt talks about a DB that contains >the info. So How should this doc refer to that? >------- >Needs better abstract; doesn't even use the word "SRV". (and the rfc >editor will surely complain when they get it...) > >Might be good to use SRV in the title as well, as opposed to just >"DNS". But this I'm less concerned about, as there are two steps, and >only the second step is SRV records. > >E.g., maybe change: > > Discovering LDAP Services with DNS > >To something like: > > Discovering LDAP Services with DNS SRV Resource Records > >However, the rfc editor probably won't like the abbreviation >"SRV". Unfortunately, I don't think the acronym expands into anything >useful. >------- >I have three concerns here: > >(0) It isn't clear when this approach is supposed to be used. DNs are an > integral part of *every* LDAP operation. Is it the intent that an >LDAP > client check every DN it sees for DC fields and if it finds them use > this approach. Or is it only appropriate in specific situations? > >(1) This document specifies two things: How to translate a DN to a DNS > name and how to use a DNS name to locate a corresponding LDAP >server. > The document seems to imply that the latter is only used when a DNS > name is produced by the former. I wonder if this restriction is a >good > idea: Isn't the ability to use SRV records to locate more generally > useful than this limited context? > > The answer to this may be no, but if so, the rationale for that >answer > should be part of the specification. > >(2) I don't see any provision for fallback to A records if SRV records > don't exist. I can easily see this being a Bad Idea, if so, there > should be an explicit prohibition of it in the document along with > some explanation of why it is a bad idea. > > > > > >_______________________________________________ >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 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 ======================================================================== The Open Group Conference Boundaryless Information Flow: The Role of Open Source Cannes, France, 14-18th October http://www.opengroup.org/cannes2002 ======================================================================== _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 11:34:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01078 for ; Thu, 15 Aug 2002 11:34:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06762; Thu, 15 Aug 2002 11:31:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06730 for ; Thu, 15 Aug 2002 11:31:40 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00788 for ; Thu, 15 Aug 2002 11:30:20 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7FFU6W1029060; Thu, 15 Aug 2002 17:30:09 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 15 Aug 2002 17:31:03 +0200 Received: from [192.168.1.9] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 15 Aug 2002 17:31:02 +0200 Date: Wed, 14 Aug 2002 15:11:39 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Paul Leach , Michael Armijo , Levon Esibov , rlmorgan@washington.edu cc: ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se Message-ID: <26690956.1029337899@localhost> In-Reply-To: <4AEE3169443CDD4796CA8A00B02191CD4ECB88@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <4AEE3169443CDD4796CA8A00B02191CD4ECB88@win-msg-01.wingroup.wind eploy.ntdev.microsoft.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 15 Aug 2002 15:31:03.0032 (UTC) FILETIME=[C3B63780:01C24470] Content-Transfer-Encoding: 7bit Subject: [ldapext] RE: draft-ietf-ldapext-locate Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7bit --On 2002-08-13 14.50 -0700 Paul Leach wrote: > It isn't _the_ naming convention for the Internet. It isn't even _the_ > naming convention for LDAP. If you want to think of it this way, I guess > one could say that it is _the_ convention for LDAP DNs that contain DC > components, but not for ones that don't. Good, I am happy with that, but, this probably have to be spelled out explicitly. Example of a problem: Take the domain name issues, and the project which try to have LDAP access to Whois data. We have whois data both at the registry and the registar about a domain name. In the project, both records, the referral thing in the registry and the actual whois info at the registrar use the same DN, and that is exactly the dc components of the domain name itself. And, then the user himself probably want/will have an LDAP server himself for the same DN. Example, my domain paf.se with "dc=paf, dc=se" might exists on three different locations. The registry, the registrar and myself. paf _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 11:56:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02083 for ; Thu, 15 Aug 2002 11:56:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08085; Thu, 15 Aug 2002 11:47:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08055 for ; Thu, 15 Aug 2002 11:47:15 -0400 (EDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01518 for ; Thu, 15 Aug 2002 11:45:55 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g7FFlCkC022820; Thu, 15 Aug 2002 15:47:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020815084330.02943f28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 Aug 2002 08:46:55 -0700 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: "Kurt D. Zeilenga" Subject: Re: [ldapext] RE: draft-ietf-ldapext-locate Cc: Paul Leach , Michael Armijo , Levon Esibov , rlmorgan@washington.edu, ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se In-Reply-To: <26690956.1029337899@localhost> References: <4AEE3169443CDD4796CA8A00B02191CD4ECB88@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <4AEE3169443CDD4796CA8A00B02191CD4ECB88@win-msg-01.wingroup.wind eploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA08056 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit At 12:11 PM 2002-08-14, Patrik Fältström wrote: >Example, my domain paf.se with "dc=paf, dc=se" might exists on three >different locations. >The registry, the registrar and myself. Well, the owner of the domain paf.se owns dc=paf,dc=se. The others (the registry and registrar) have hijacking namespace. Luckily, you are the source of authority for _ldap._tcp.paf.se. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 12:04:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02706 for ; Thu, 15 Aug 2002 12:04:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09007; Thu, 15 Aug 2002 11:58:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08979 for ; Thu, 15 Aug 2002 11:58:16 -0400 (EDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02102 for ; Thu, 15 Aug 2002 11:56:55 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g7FFwFkC022871; Thu, 15 Aug 2002 15:58:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020815085059.02941a60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 Aug 2002 08:57:58 -0700 To: From: "Kurt D. Zeilenga" Cc: ldapext@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA08980 Subject: [ldapext] Re: draft-ietf-ldapext-locate Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit I had a number of discussions with WHOIS/LDAP folks. Basically, since the registrar/registry doesn't have authority over _ldap._tcp.paf.se, they shouldn't name their entries "dc=paf,dc=se". I suggested they name them "dc=paf,dc=se,o=whois" and then define their own DNS SRV based location process for DNs under o=whois. Of course, if Jeff's proposal was adopted, this approach wouldn't work. They would have to do something like: whoisdc=paf,whois=se,o=whois. And the next application needing it's own chunk of namespace couldn't use dc either... so we end up with a DC-like attribute for each application space. yuk! Kurt At 12:11 PM 2002-08-14, Patrik Fältström wrote: >--On 2002-08-13 14.50 -0700 Paul Leach wrote: > >> It isn't _the_ naming convention for the Internet. It isn't even _the_ >> naming convention for LDAP. If you want to think of it this way, I guess >> one could say that it is _the_ convention for LDAP DNs that contain DC >> components, but not for ones that don't. > >Good, I am happy with that, but, this probably have to be spelled out >explicitly. > >Example of a problem: > >Take the domain name issues, and the project which try to have LDAP access >to Whois data. > >We have whois data both at the registry and the registar about a domain >name. In the project, both records, the referral thing in the registry and >the actual whois info at the registrar use the same DN, and that is exactly >the dc components of the domain name itself. And, then the user himself >probably want/will have an LDAP server himself for the same DN. > >Example, my domain paf.se with "dc=paf, dc=se" might exists on three >different locations. > >The registry, the registrar and myself. > > paf _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 13:12:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05204 for ; Thu, 15 Aug 2002 13:12:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15208; Thu, 15 Aug 2002 13:06:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15177 for ; Thu, 15 Aug 2002 13:06:47 -0400 (EDT) Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04935 for ; Thu, 15 Aug 2002 13:05:26 -0400 (EDT) Received: from CHRIS-H.opengroup.org (dhcp192-153-166-32.rdg.opengroup.org [192.153.166.32]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id g7FGtiQ22554; Thu, 15 Aug 2002 17:55:44 +0100 Message-Id: <5.1.0.14.1.20020815174302.00b06740@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 Aug 2002 17:45:04 +0100 To: christine.yoon@us.pwcglobal.com From: Chris Harding Cc: , "'Liben, Michael \(GTS\)'" , "'Patrik Fältström'" , dif-members@opengroup.org, michael.d.compton@us.pwcglobal.com, jamie.quick@us.pwcglobal.com, brian.jensen@us.pwcglobal.com, "Alexis Bor" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [ldapext] Directory Best Practice Guide Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit Hi, Christine - That's great! We need lots more volunteers, though. How about it, folks? At 10:40 15/08/2002 -0400, christine.yoon@us.pwcglobal.com wrote: >Chris, > >We (PwC) have many years of experience in directory/security >implementation for various clients including Fortune 500 companies. >I would like to volunteer to author the Directory Best Practice Guide. > > >-Christine Yoon >PricewaterhouseCoopers >(201)981-1172 - cell >(732)706-3559 - office > > > > > > Chris > Harding > > > up.org> cc: , > "'Liben, Michael \(GTS\)'" , "'Patrik > Sent by: Fältström'" > , dif-members@opengroup.org > ldapext-admin@ietf Subject: RE: [ldapext] > draft-ietf-ldapext-locate > .org > > 08/15/2002 > 06:20 > > AM > > > > > > > > > > > >Hi, Alexis - > >A Directory Best Practices Guide is something that is clearly needed. I >believe that the Directory Interoperability Forum should support its >creation and contribute to it. The DIF could for example provide >publication or web page hosting facilities if needed, and could provide >some review effort. However, I don't believe that the DIF could on its own >provide the technical authoring and review effort needed to deliver an >authoritative guide. > >Because there is (as you point out) a need for rapid evolution, a set of >web pages would be far and away the best medium for such a guide. What we >need is a set of contributors, a review group, and an editorial committee, >working within the framework of an established review and publications >procedure. This procedure must be public and must allow rapid turnaround >from authoring to publication - I would say within 2 months at the outside. > >Perhaps it could be handled as a kind of Open Source project. > >I believe (the members make the decisions, I just support them) that the >DIF would be interested in co-ordinating or participating in a project of >this nature. > >At 16:00 14/08/2002 -0400, Alexis Bor wrote: > >I proved to myself and others (while I was at Boeing doing R&D work in > >Directory) back in 1992 that putting any meaning into a DN is not a good > >practice. We took the example of a company of 100,000 and looked at the > >different approaches for DN's - Geographic, Political, Hybrid and > >others. > > > >It became clear that it would be a maintenance headache and cause lots > >of stress on the overall infrastructure. It was very hard to convince > >most people for a long time until some work that Jeff Hodges did at > >Stanford got a lot of attention in the late 90's. > > > >A real hard piece of work to put forward is a best practices document. > >The number of opinions will typically exceed the number of people > >working on the document. What we learned in the mid 90's was that such > >a document evolves faster than the review cycle (part of an EMA effort > >to write a white paper on directory best practices), making it out of > >date before you even finish the review of it. However, with all of the > >experience that everyone is getting, it may be worth resurrecting the > >idea again. > > > >Perhaps an industry group can step up to the challenge - any takers? > > > >-- Alexis > > > >Alexis Bor > >Directory Works, Inc. > >www.directoryworks.com > > > > > >-----Original Message----- > >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf > >Of Liben, Michael (GTS) > >Sent: Tuesday, August 13, 2002 5:32 PM > >To: 'Patrik Fältström' > >Cc: ldapext@ietf.org > >Subject: RE: [ldapext] draft-ietf-ldapext-locate > > > >In general, divining any meaning from a distinguished name is not good > >practice (my $.02). The implications are that your app will likely > >break. The SHOULD NOT allows you impart meaning to your > >distinguished name if you so choose. A MUST NOT would be an absolute > >prohibition. > > > > > > > >-----Original Message----- > >From: Patrik Fältström [mailto:paf@cisco.com] > >Sent: Tuesday, August 13, 2002 5:54 AM > >To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; > >rlmorgan@washington.edu > >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > >Subject: [ldapext] draft-ietf-ldapext-locate > > > >Comments from the IESG: > >------- > >The document says: > > If there are no > > matching SRV records available for the converted DN the client > >SHOULD > > NOT attempt to 'walk the tree' by removing the least significant > > portion of the constructed fully qualified domain name. > > > >The meaning of "SHOULD NOT" is "don't do this unless you understand the > >implications". Well, I don't know where to look to understand the > >implications. > >Thus I think it would be useful to either make it a MUST NOT, or explain > >something about the implications of using shorter labels. > > > >Alternatively specify SHOULD NOT do this in general, but MUST NOT ever > >use this with just one label (i.e. MUST NOT look for _ldap._tcp.) > >or something similar. > > > >------- > >The document is unclear (see next note) on: > > > >(a) When this is to be used (only when not having the foggiest clue > >where a > >record with a specific DN is, or every time a record is to be accessed?) > > > >(b) How to handle the case when one have a DN which have both dc and > >non-dc > >components. Example of this is when two records stored on two different > >servers share the same dc components. IF those records per definition > >(of > >this document) have to be stored on the same server, or referrals have > >to > >be stored on them to point to the other, then this document has a scope > >which is larger than at first glance. I.e. part from stating how to > >locate > >a record using DNS, it also has an implicit result that DC is _the_ > >naming > >convention for the Internet. Please explain. > > > >------- > >This document define a conversion that is over-restrictive. > > > > The output domain name is initially empty. The DN is processed > >in > > right-to-left order (i.e., beginning with the first RDN in the > > sequence of RDNs). An RDN is able to be converted if it (1) > > consists of a single AttributeTypeAndValue; (2) the attribute > >type > > is "DC"; and (3) the attribute value is non-null. If it can be > > converted, the attribute value is used as a domain name > >component > > (label). The first such value becomes the rightmost (i.e., most > > significant) domain name component, and successive converted RDN > > values extend to the left. If an RDN cannot be converted, > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > processing stops. If the output domain name is empty when > > ^^^^^^^^^^^^^^^^^ > > processing stops, the DN cannot be converted into a domain name. > > > >The underscored text should be removed and replaced with text that > >states the non-DC RDN's are skipped over. So for example the DN: > > > > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, > > dc=edu > > > >Can be unambiguously translated into: > > > > lees.mit.edu > > > >Yet the underscored words make this translation invalid. With the > >Underscored rule in place this DN would convert to just 'mit.edu' > >which is not the desired result. > > > >The additional flexibility offered will permit us to convert existing > >PKI systems to make use of this feature without requiring all > >certificates to be re-issued. It will also permit us to create DIT's > >that can be delegated at more points rather then requiring all > >structure to be at the very top where the DC components are, prior to > >any non-DC component. > > > >For example if MIT had a DIT with a top level name of: > > > > o=MIT,c=US > > > >and a subordinate lab wanted to use this document, they could have a > >delegated subtree like: > > > > ou=Lab for X,o=MIT,c=US > > > >and then add a DC component below this as: > > > > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US > > > >Under my more flexible approach this would work. Without the > >flexibility they would be SOL until MIT redid its entire DIT to > >be: > > > > o=MIT,c=US,dc=mit,dc=edu > > > >and then they would have to be jointed in as: > > > > o=MIT,c=US,dc=labx,dc=mit,dc=edu > > > >Ned: I have three concerns here: > > > >(0) It isn't clear when this approach is supposed to be used. DNs are an > > integral part of *every* LDAP operation. Is it the intent that > >an > >LDAP > > client check every DN it sees for DC fields and if it finds them > >use > > this approach. Or is it only appropriate in specific situations? > > > >(1) This document specifies two things: How to translate a DN to a DNS > > name and how to use a DNS name to locate a corresponding LDAP > >server. > > The document seems to imply that the latter is only used when a > >DNS > > name is produced by the former. I wonder if this restriction is > >a > >good > > idea: Isn't the ability to use SRV records to locate more > >generally > > useful than this limited context? > > > > The answer to this may be no, but if so, the rationale for that > >answer > > should be part of the specification. > > > >(2) I don't see any provision for fallback to A records if SRV records > > don't exist. I can easily see this being a Bad Idea, if so, > >there > > should be an explicit prohibition of it in the document along > >with > > some explanation of why it is a bad idea. > > > > > > > >------- > >References should be split in normative and non-normative. > >------- > >I wonder about the reference to RFC1700, which has been obsoleted > >by RFC3232, and that RFC actuallt talks about a DB that contains > >the info. So How should this doc refer to that? > >------- > >Needs better abstract; doesn't even use the word "SRV". (and the rfc > >editor will surely complain when they get it...) > > > >Might be good to use SRV in the title as well, as opposed to just > >"DNS". But this I'm less concerned about, as there are two steps, and > >only the second step is SRV records. > > > >E.g., maybe change: > > > > Discovering LDAP Services with DNS > > > >To something like: > > > > Discovering LDAP Services with DNS SRV Resource Records > > > >However, the rfc editor probably won't like the abbreviation > >"SRV". Unfortunately, I don't think the acronym expands into anything > >useful. > >------- > >I have three concerns here: > > > >(0) It isn't clear when this approach is supposed to be used. DNs are an > > integral part of *every* LDAP operation. Is it the intent that an > >LDAP > > client check every DN it sees for DC fields and if it finds them use > > this approach. Or is it only appropriate in specific situations? > > > >(1) This document specifies two things: How to translate a DN to a DNS > > name and how to use a DNS name to locate a corresponding LDAP > >server. > > The document seems to imply that the latter is only used when a DNS > > name is produced by the former. I wonder if this restriction is a > >good > > idea: Isn't the ability to use SRV records to locate more generally > > useful than this limited context? > > > > The answer to this may be no, but if so, the rationale for that > >answer > > should be part of the specification. > > > >(2) I don't see any provision for fallback to A records if SRV records > > don't exist. I can easily see this being a Bad Idea, if so, there > > should be an explicit prohibition of it in the document along with > > some explanation of why it is a bad idea. > > > > > > > > > > > >_______________________________________________ > >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 > > >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 >======================================================================== >The Open Group Conference >Boundaryless Information Flow: The Role of Open Source >Cannes, France, 14-18th October >http://www.opengroup.org/cannes2002 >======================================================================== > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > > > >_________________________________________________________________ > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential > and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance > upon, this information by persons or entities other than the > intended recipient is prohibited. If you received this in error, > please contact the sender and delete the material from any > computer. > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext 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 ======================================================================== The Open Group Conference Boundaryless Information Flow: The Role of Open Source Cannes, France, 14-18th October http://www.opengroup.org/cannes2002 ======================================================================== _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 13:21:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05552 for ; Thu, 15 Aug 2002 13:21:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16112; Thu, 15 Aug 2002 13:18:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16042 for ; Thu, 15 Aug 2002 13:18:16 -0400 (EDT) Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05401 for ; Thu, 15 Aug 2002 13:16:54 -0400 (EDT) Received: from timmy ([24.112.131.40]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20020815171745.WEOZ334399.fep02-mail.bloor.is.net.cable.rogers.com@timmy>; Thu, 15 Aug 2002 13:17:45 -0400 From: "James Benedict" To: "'Chris Harding'" , Cc: , "'Liben, Michael \(GTS\)'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , , , , , "'Alexis Bor'" Subject: RE: [ldapext] Directory Best Practice Guide Date: Thu, 15 Aug 2002 13:17:36 -0400 Organization: 2009615 Ontario Inc Message-ID: <000501c2447f$aa1bf710$0c01a8c0@timmy> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.1.20020815174302.00b06740@mailhome.rdg.opengroup.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.112.131.40] using ID at Thu, 15 Aug 2002 13:17:36 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA16043 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit Add me to the list... I'm sure I can dreg up some comments/recommendations on directory best practices ;-) -- James Benedict -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf Of Chris Harding Sent: Thursday, August 15, 2002 12:45 PM To: christine.yoon@us.pwcglobal.com Cc: ldapext@ietf.org; 'Liben, Michael (GTS)'; 'Patrik Fältström'; dif-members@opengroup.org; michael.d.compton@us.pwcglobal.com; jamie.quick@us.pwcglobal.com; brian.jensen@us.pwcglobal.com; Alexis Bor Subject: [ldapext] Directory Best Practice Guide Hi, Christine - That's great! We need lots more volunteers, though. How about it, folks? At 10:40 15/08/2002 -0400, christine.yoon@us.pwcglobal.com wrote: >Chris, > >We (PwC) have many years of experience in directory/security >implementation for various clients including Fortune 500 companies. >I would like to volunteer to author the Directory Best Practice Guide. > > >-Christine Yoon >PricewaterhouseCoopers >(201)981-1172 - cell >(732)706-3559 - office > > > > > > Chris > Harding > > > up.org> cc: , > "'Liben, Michael \(GTS\)'" , "'Patrik > Sent by: Fältström'" > , dif-members@opengroup.org > ldapext-admin@ietf Subject: RE: [ldapext] > draft-ietf-ldapext-locate > .org > > 08/15/2002 > 06:20 > > AM > > > > > > > > > > > >Hi, Alexis - > >A Directory Best Practices Guide is something that is clearly needed. I >believe that the Directory Interoperability Forum should support its >creation and contribute to it. The DIF could for example provide >publication or web page hosting facilities if needed, and could provide >some review effort. However, I don't believe that the DIF could on its own >provide the technical authoring and review effort needed to deliver an >authoritative guide. > >Because there is (as you point out) a need for rapid evolution, a set of >web pages would be far and away the best medium for such a guide. What we >need is a set of contributors, a review group, and an editorial committee, >working within the framework of an established review and publications >procedure. This procedure must be public and must allow rapid turnaround >from authoring to publication - I would say within 2 months at the outside. > >Perhaps it could be handled as a kind of Open Source project. > >I believe (the members make the decisions, I just support them) that the >DIF would be interested in co-ordinating or participating in a project of >this nature. > >At 16:00 14/08/2002 -0400, Alexis Bor wrote: > >I proved to myself and others (while I was at Boeing doing R&D work in > >Directory) back in 1992 that putting any meaning into a DN is not a good > >practice. We took the example of a company of 100,000 and looked at the > >different approaches for DN's - Geographic, Political, Hybrid and > >others. > > > >It became clear that it would be a maintenance headache and cause lots > >of stress on the overall infrastructure. It was very hard to convince > >most people for a long time until some work that Jeff Hodges did at > >Stanford got a lot of attention in the late 90's. > > > >A real hard piece of work to put forward is a best practices document. > >The number of opinions will typically exceed the number of people > >working on the document. What we learned in the mid 90's was that such > >a document evolves faster than the review cycle (part of an EMA effort > >to write a white paper on directory best practices), making it out of > >date before you even finish the review of it. However, with all of the > >experience that everyone is getting, it may be worth resurrecting the > >idea again. > > > >Perhaps an industry group can step up to the challenge - any takers? > > > >-- Alexis > > > >Alexis Bor > >Directory Works, Inc. > >www.directoryworks.com > > > > > >-----Original Message----- > >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf > >Of Liben, Michael (GTS) > >Sent: Tuesday, August 13, 2002 5:32 PM > >To: 'Patrik Fältström' > >Cc: ldapext@ietf.org > >Subject: RE: [ldapext] draft-ietf-ldapext-locate > > > >In general, divining any meaning from a distinguished name is not good > >practice (my $.02). The implications are that your app will likely > >break. The SHOULD NOT allows you impart meaning to your > >distinguished name if you so choose. A MUST NOT would be an absolute > >prohibition. > > > > > > > >-----Original Message----- > >From: Patrik Fältström [mailto:paf@cisco.com] > >Sent: Tuesday, August 13, 2002 5:54 AM > >To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; > >rlmorgan@washington.edu > >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > >Subject: [ldapext] draft-ietf-ldapext-locate > > > >Comments from the IESG: > >------- > >The document says: > > If there are no > > matching SRV records available for the converted DN the client > >SHOULD > > NOT attempt to 'walk the tree' by removing the least significant > > portion of the constructed fully qualified domain name. > > > >The meaning of "SHOULD NOT" is "don't do this unless you understand the > >implications". Well, I don't know where to look to understand the > >implications. > >Thus I think it would be useful to either make it a MUST NOT, or explain > >something about the implications of using shorter labels. > > > >Alternatively specify SHOULD NOT do this in general, but MUST NOT ever > >use this with just one label (i.e. MUST NOT look for _ldap._tcp.) > >or something similar. > > > >------- > >The document is unclear (see next note) on: > > > >(a) When this is to be used (only when not having the foggiest clue > >where a > >record with a specific DN is, or every time a record is to be accessed?) > > > >(b) How to handle the case when one have a DN which have both dc and > >non-dc > >components. Example of this is when two records stored on two different > >servers share the same dc components. IF those records per definition > >(of > >this document) have to be stored on the same server, or referrals have > >to > >be stored on them to point to the other, then this document has a scope > >which is larger than at first glance. I.e. part from stating how to > >locate > >a record using DNS, it also has an implicit result that DC is _the_ > >naming > >convention for the Internet. Please explain. > > > >------- > >This document define a conversion that is over-restrictive. > > > > The output domain name is initially empty. The DN is processed > >in > > right-to-left order (i.e., beginning with the first RDN in the > > sequence of RDNs). An RDN is able to be converted if it (1) > > consists of a single AttributeTypeAndValue; (2) the attribute > >type > > is "DC"; and (3) the attribute value is non-null. If it can be > > converted, the attribute value is used as a domain name > >component > > (label). The first such value becomes the rightmost (i.e., most > > significant) domain name component, and successive converted RDN > > values extend to the left. If an RDN cannot be converted, > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > processing stops. If the output domain name is empty when > > ^^^^^^^^^^^^^^^^^ > > processing stops, the DN cannot be converted into a domain name. > > > >The underscored text should be removed and replaced with text that > >states the non-DC RDN's are skipped over. So for example the DN: > > > > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, > > dc=edu > > > >Can be unambiguously translated into: > > > > lees.mit.edu > > > >Yet the underscored words make this translation invalid. With the > >Underscored rule in place this DN would convert to just 'mit.edu' > >which is not the desired result. > > > >The additional flexibility offered will permit us to convert existing > >PKI systems to make use of this feature without requiring all > >certificates to be re-issued. It will also permit us to create DIT's > >that can be delegated at more points rather then requiring all > >structure to be at the very top where the DC components are, prior to > >any non-DC component. > > > >For example if MIT had a DIT with a top level name of: > > > > o=MIT,c=US > > > >and a subordinate lab wanted to use this document, they could have a > >delegated subtree like: > > > > ou=Lab for X,o=MIT,c=US > > > >and then add a DC component below this as: > > > > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US > > > >Under my more flexible approach this would work. Without the > >flexibility they would be SOL until MIT redid its entire DIT to > >be: > > > > o=MIT,c=US,dc=mit,dc=edu > > > >and then they would have to be jointed in as: > > > > o=MIT,c=US,dc=labx,dc=mit,dc=edu > > > >Ned: I have three concerns here: > > > >(0) It isn't clear when this approach is supposed to be used. DNs are an > > integral part of *every* LDAP operation. Is it the intent that > >an > >LDAP > > client check every DN it sees for DC fields and if it finds them > >use > > this approach. Or is it only appropriate in specific situations? > > > >(1) This document specifies two things: How to translate a DN to a DNS > > name and how to use a DNS name to locate a corresponding LDAP > >server. > > The document seems to imply that the latter is only used when a > >DNS > > name is produced by the former. I wonder if this restriction is > >a > >good > > idea: Isn't the ability to use SRV records to locate more > >generally > > useful than this limited context? > > > > The answer to this may be no, but if so, the rationale for that > >answer > > should be part of the specification. > > > >(2) I don't see any provision for fallback to A records if SRV records > > don't exist. I can easily see this being a Bad Idea, if so, > >there > > should be an explicit prohibition of it in the document along > >with > > some explanation of why it is a bad idea. > > > > > > > >------- > >References should be split in normative and non-normative. > >------- > >I wonder about the reference to RFC1700, which has been obsoleted > >by RFC3232, and that RFC actuallt talks about a DB that contains > >the info. So How should this doc refer to that? > >------- > >Needs better abstract; doesn't even use the word "SRV". (and the rfc > >editor will surely complain when they get it...) > > > >Might be good to use SRV in the title as well, as opposed to just > >"DNS". But this I'm less concerned about, as there are two steps, and > >only the second step is SRV records. > > > >E.g., maybe change: > > > > Discovering LDAP Services with DNS > > > >To something like: > > > > Discovering LDAP Services with DNS SRV Resource Records > > > >However, the rfc editor probably won't like the abbreviation > >"SRV". Unfortunately, I don't think the acronym expands into anything > >useful. > >------- > >I have three concerns here: > > > >(0) It isn't clear when this approach is supposed to be used. DNs are an > > integral part of *every* LDAP operation. Is it the intent that an > >LDAP > > client check every DN it sees for DC fields and if it finds them use > > this approach. Or is it only appropriate in specific situations? > > > >(1) This document specifies two things: How to translate a DN to a DNS > > name and how to use a DNS name to locate a corresponding LDAP > >server. > > The document seems to imply that the latter is only used when a DNS > > name is produced by the former. I wonder if this restriction is a > >good > > idea: Isn't the ability to use SRV records to locate more generally > > useful than this limited context? > > > > The answer to this may be no, but if so, the rationale for that > >answer > > should be part of the specification. > > > >(2) I don't see any provision for fallback to A records if SRV records > > don't exist. I can easily see this being a Bad Idea, if so, there > > should be an explicit prohibition of it in the document along with > > some explanation of why it is a bad idea. > > > > > > > > > > > >_______________________________________________ > >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 > > >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 >======================================================================= = >The Open Group Conference >Boundaryless Information Flow: The Role of Open Source >Cannes, France, 14-18th October >http://www.opengroup.org/cannes2002 >======================================================================= = > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > > > >_________________________________________________________________ > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential > and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance > upon, this information by persons or entities other than the > intended recipient is prohibited. If you received this in error, > please contact the sender and delete the material from any > computer. > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext 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 ======================================================================== The Open Group Conference Boundaryless Information Flow: The Role of Open Source Cannes, France, 14-18th October http://www.opengroup.org/cannes2002 ======================================================================== _______________________________________________ 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 Aug 15 13:40:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06357 for ; Thu, 15 Aug 2002 13:40:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17991; Thu, 15 Aug 2002 13:39:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15607 for ; Thu, 15 Aug 2002 13:12:24 -0400 (EDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05173 for ; Thu, 15 Aug 2002 13:11:03 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KLBKH8JJ280001B1@mauve.mrochek.com> for ldapext@ietf.org; Thu, 15 Aug 2002 10:12:17 -0700 (PDT) Date: Thu, 15 Aug 2002 09:57:16 -0700 (PDT) Subject: Re: [ldapext] draft-ietf-ldapext-locate In-reply-to: "Your message dated Tue, 13 Aug 2002 21:36:05 -0700" <5.1.0.14.0.20020813201324.0674c688@127.0.0.1> To: "Kurt D. Zeilenga" Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , micharm@microsoft.com, paulle@microsoft.com, levone@microsoft.com, rlmorgan@washington.edu, ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se Message-id: <01KLBN5PE4D60001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <24876124.1029218035@localhost> <5.1.0.14.0.20020813201324.0674c688@127.0.0.1> Content-Transfer-Encoding: 7BIT Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7BIT I'm going to take the liberty of responding directly here. > >(0) It isn't clear when this approach is supposed to be used. DNs are an > >integral part of *every* LDAP operation. Is it the intent that an > >LDAP client check every DN it sees for DC fields and if it finds them use > >this approach. Or is it only appropriate in specific situations? > It is intended to be a general mechanism for locating LDAP servers > having knowledge of directory objects associated with a DN in > absence of location information. This DN may have been provided > to the application via LDAP or other means. If the DN was provided > with location information, such as a LDAP URL with host part, > that information should be used. Howeer, where the DN is provided > without any location information, this mechanism provides a means, > for a subset of DNs (those using RFC 2247 naming), for the > application to locate servers with knowledge of the DN. > This application may be an LDAP client or server. OpenLDAP's server, > for example, can use this mechanism to generate referrals to clients > requesting DN which it otherwise has no knowledge of. This is precisely the sort of thing I'm afraid of. OpenLDAP does this but I doubt SunOne Directory Server (to pick a specific example) does. And given this document doesn't spell out when this is supposed to be used you cannot claim that the issue is Sun's failure to implement this standard. THe opposite situation is also a concern. Suppose I have an LDAP library that implements this unconditionally and I try to use that library in a situation where I don't want it to happen. (Uses of DC DNs that don't expect this to happen do exist, you know; the product I work on in my day job is an example of this.) This can be fixed in a bunch of ways. The most obvious one would be to say that this should be implemented in the following places and whether or not it is used needs to be configurable. > >(1) This document specifies two things: How to translate a DN to a DNS > >name and how to use a DNS name to locate a corresponding LDAP > >server. > I argue that the document specifies one process, to locate LDAP > servers with knowledge of a particular DN, which has two steps. > >The document seems to imply that the latter is only used when a DNS > >name is produced by the former. I wonder if this restriction is a > >good idea: Isn't the ability to use SRV records to locate more generally > >useful than this limited context? > I don't believe this document restricts how DNS SRV records > can be used. It also doesn't restrict construction of additional > processes for locating LDAP servers with knowledge of a particular > DN. In fact, draft-zeilenga-ldap-x500-locate suggests a process > for DNs using geo-political naming. > Additionally, DNS SRVs could be used to answer questions such > as "Are there LDAP servers associated with this domain?". This is the separate case I was thinking of. > Of course, this would be followed by, "What DN is used by > the owner of this domain for their objects?". If a listed > server provides 100s of namingContext, which one is the right one? > Luckily, we have RFC 2247 which says how the owner of the > domain should name objects. Then you should make it clear that this document specifies a single process, and that it does not specify a process for locating LDAP servers for a given domain. Ned _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 13:42:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06503 for ; Thu, 15 Aug 2002 13:42:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18024; Thu, 15 Aug 2002 13:39:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27151 for ; Wed, 14 Aug 2002 17:30:29 -0400 (EDT) Received: from prv-mail10.provo.novell.com (prv3-mh.provo.novell.com [137.65.81.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25605 for ; Wed, 14 Aug 2002 17:29:07 -0400 (EDT) Received: from INET-PRV3-MTA by prv-mail10.provo.novell.com with Novell_GroupWise; Wed, 14 Aug 2002 15:29:49 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Beta Date: Wed, 14 Aug 2002 15:29:52 -0600 From: "Ed Reed" To: , , , Cc: Subject: RE: [ldapext] draft-ietf-ldapext-locate Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA27155 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit Sorry, this conversation takes me back to wondering why 48 bit mac addresses aren't sufficient as names... What is the purpose of prohibiting the use the hierarchical name, whether DN or DNS, to gather information about the support and policies of an organization? Has that practice, of searching for authoritative MX records for a host name, proven so broken that we don't want to use it as a way to find LDAP servers for a DN, either? I don't think I'm mixing metaphores, here...I see a convergence in DNs and DNS names over the long run. I must not recall the problem we're trying to avoid, here. As for naming - there is no right answer - it's a matter for local politics and engineering to work out. "What this directory needs is a good secondary index". And thus was born a never ending stream of catalogues and centroids. Ed =============== Edwards E Reed Novell, Inc. +1 585 624 2402 >>> 08/14/02 05:14PM >>> Is this (Directory best practices) something that one of the IETF ldap working groups can do? If so, I would like to contribute. I represent PricewaterhouseCoopers (PwC) and am working on Security Integration practices. We (PwC) have implemented many directory services for various clients. What is the process to initiate such work? Please advise. -Christine Yoon PricewaterhouseCoopers (201)981-1172 (cell) (732)706-3559 (office) "Alexis Bor" , "'Patrik Fältström'" yworks.com> Sent by: cc: ldapext-admin@ietf.o Subject: RE: [ldapext] draft-ietf-ldapext-locate rg 08/14/2002 04:00 PM I proved to myself and others (while I was at Boeing doing R&D work in Directory) back in 1992 that putting any meaning into a DN is not a good practice. We took the example of a company of 100,000 and looked at the different approaches for DN's - Geographic, Political, Hybrid and others. It became clear that it would be a maintenance headache and cause lots of stress on the overall infrastructure. It was very hard to convince most people for a long time until some work that Jeff Hodges did at Stanford got a lot of attention in the late 90's. A real hard piece of work to put forward is a best practices document. The number of opinions will typically exceed the number of people working on the document. What we learned in the mid 90's was that such a document evolves faster than the review cycle (part of an EMA effort to write a white paper on directory best practices), making it out of date before you even finish the review of it. However, with all of the experience that everyone is getting, it may be worth resurrecting the idea again. Perhaps an industry group can step up to the challenge - any takers? -- Alexis Alexis Bor Directory Works, Inc. www.directoryworks.com -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf Of Liben, Michael (GTS) Sent: Tuesday, August 13, 2002 5:32 PM To: 'Patrik Fältström' Cc: ldapext@ietf.org Subject: RE: [ldapext] draft-ietf-ldapext-locate In general, divining any meaning from a distinguished name is not good practice (my $.02). The implications are that your app will likely break. The SHOULD NOT allows you impart meaning to your distinguished name if you so choose. A MUST NOT would be an absolute prohibition. -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Tuesday, August 13, 2002 5:54 AM To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; rlmorgan@washington.edu Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se Subject: [ldapext] draft-ietf-ldapext-locate Comments from the IESG: ------- The document says: If there are no matching SRV records available for the converted DN the client SHOULD NOT attempt to 'walk the tree' by removing the least significant portion of the constructed fully qualified domain name. The meaning of "SHOULD NOT" is "don't do this unless you understand the implications". Well, I don't know where to look to understand the implications. Thus I think it would be useful to either make it a MUST NOT, or explain something about the implications of using shorter labels. Alternatively specify SHOULD NOT do this in general, but MUST NOT ever use this with just one label (i.e. MUST NOT look for _ldap._tcp.) or something similar. ------- The document is unclear (see next note) on: (a) When this is to be used (only when not having the foggiest clue where a record with a specific DN is, or every time a record is to be accessed?) (b) How to handle the case when one have a DN which have both dc and non-dc components. Example of this is when two records stored on two different servers share the same dc components. IF those records per definition (of this document) have to be stored on the same server, or referrals have to be stored on them to point to the other, then this document has a scope which is larger than at first glance. I.e. part from stating how to locate a record using DNS, it also has an implicit result that DC is _the_ naming convention for the Internet. Please explain. ------- This document define a conversion that is over-restrictive. The output domain name is initially empty. The DN is processed in right-to-left order (i.e., beginning with the first RDN in the sequence of RDNs). An RDN is able to be converted if it (1) consists of a single AttributeTypeAndValue; (2) the attribute type is "DC"; and (3) the attribute value is non-null. If it can be converted, the attribute value is used as a domain name component (label). The first such value becomes the rightmost (i.e., most significant) domain name component, and successive converted RDN values extend to the left. If an RDN cannot be converted, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ processing stops. If the output domain name is empty when ^^^^^^^^^^^^^^^^^ processing stops, the DN cannot be converted into a domain name. The underscored text should be removed and replaced with text that states the non-DC RDN's are skipped over. So for example the DN: cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, dc=edu Can be unambiguously translated into: lees.mit.edu Yet the underscored words make this translation invalid. With the Underscored rule in place this DN would convert to just 'mit.edu' which is not the desired result. The additional flexibility offered will permit us to convert existing PKI systems to make use of this feature without requiring all certificates to be re-issued. It will also permit us to create DIT's that can be delegated at more points rather then requiring all structure to be at the very top where the DC components are, prior to any non-DC component. For example if MIT had a DIT with a top level name of: o=MIT,c=US and a subordinate lab wanted to use this document, they could have a delegated subtree like: ou=Lab for X,o=MIT,c=US and then add a DC component below this as: dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US Under my more flexible approach this would work. Without the flexibility they would be SOL until MIT redid its entire DIT to be: o=MIT,c=US,dc=mit,dc=edu and then they would have to be jointed in as: o=MIT,c=US,dc=labx,dc=mit,dc=edu Ned: I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. ------- References should be split in normative and non-normative. ------- I wonder about the reference to RFC1700, which has been obsoleted by RFC3232, and that RFC actuallt talks about a DB that contains the info. So How should this doc refer to that? ------- Needs better abstract; doesn't even use the word "SRV". (and the rfc editor will surely complain when they get it...) Might be good to use SRV in the title as well, as opposed to just "DNS". But this I'm less concerned about, as there are two steps, and only the second step is SRV records. E.g., maybe change: Discovering LDAP Services with DNS To something like: Discovering LDAP Services with DNS SRV Resource Records However, the rfc editor probably won't like the abbreviation "SRV". Unfortunately, I don't think the acronym expands into anything useful. ------- I have three concerns here: (0) It isn't clear when this approach is supposed to be used. DNs are an integral part of *every* LDAP operation. Is it the intent that an LDAP client check every DN it sees for DC fields and if it finds them use this approach. Or is it only appropriate in specific situations? (1) This document specifies two things: How to translate a DN to a DNS name and how to use a DNS name to locate a corresponding LDAP server. The document seems to imply that the latter is only used when a DNS name is produced by the former. I wonder if this restriction is a good idea: Isn't the ability to use SRV records to locate more generally useful than this limited context? The answer to this may be no, but if so, the rationale for that answer should be part of the specification. (2) I don't see any provision for fallback to A records if SRV records don't exist. I can easily see this being a Bad Idea, if so, there should be an explicit prohibition of it in the document along with some explanation of why it is a bad idea. _______________________________________________ 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 _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ 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 Aug 15 13:42:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06538 for ; Thu, 15 Aug 2002 13:42:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17944; Thu, 15 Aug 2002 13:39:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16439 for ; Thu, 15 Aug 2002 13:20:17 -0400 (EDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05474 for ; Thu, 15 Aug 2002 13:18:56 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KLBKH8JJ280001B1@mauve.mrochek.com> for ldapext@ietf.org; Thu, 15 Aug 2002 10:20:13 -0700 (PDT) Date: Thu, 15 Aug 2002 10:12:52 -0700 (PDT) Subject: RE: [ldapext] draft-ietf-ldapext-locate In-reply-to: "Your message dated Wed, 14 Aug 2002 16:59:45 -0700" <4AEE3169443CDD4796CA8A00B02191CD04929810@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> To: Paul Leach Cc: "Kurt D. Zeilenga" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Michael Armijo , Levon Esibov , rlmorgan@washington.edu, ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se Message-id: <01KLBNFJTLTA0001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <4AEE3169443CDD4796CA8A00B02191CD04929810@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Transfer-Encoding: 7BIT Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7BIT > > > (1) This document specifies two things: How to translate a DN to a DNS > > > name and how to use a DNS name to locate a corresponding LDAP server. > > I argue that the document specifies one process, to locate > > LDAP servers with knowledge of a particular DN, which has two steps. > > > The document seems to imply that the latter is only used when a DNS > > > name is produced by the former. I wonder if this restriction is a good > > > idea: Isn't the ability to use SRV records to locate more generally > > > useful than this limited context? > > I don't believe this document restricts how DNS SRV records > > can be used. > I think the real question being asked was "Isn't the ability to use SRV > records to locate _LDAP servers_ more generally useful than this limited > context?". Yes, that's the question I was asking. > If so, then I agree that it is more generally useful. Independently of > DC laden DNs, ff one has the name of a domain, name, say "mit.edu", and > wants to find LDAP servers associated with that domain, then it is > logical that one should look up SRV RRs for "_ldap._tcp.mit.edu". > However, I think that this capability is already adequately specified in > RFC 2782 (DNS SRV RR RFC), where it says: > "The format of the SRV RR > Here is the format of the SRV RR, whose DNS type code is 33: > _Service._Proto.Name TTL Class SRV Priority Weight Port Target > (There is an example near the end of this document.) > Service > The symbolic name of the desired service, as defined in Assigned > Numbers [STD 2] or locally. An underscore (_) is prepended to > the service identifier to avoid collisions with DNS labels that > occur in nature. > ..." > In the case of LDAP, the symbolic name is "LDAP". Er, no. I remember this one... I wasn't an AD at the time but I was the IAB's liason to the IESG. There was strong objection from the IESG to this DNS ops document specifying how a particular application service should be located using SRV records. As a result the text was modified to include the following: Note: LDAP is chosen as an example for illustrative purposes only, and the LDAP examples used in this document should not be considered a definitive statement on the recommended way for LDAP to use SRV records. As described in the earlier applicability section, consult the appropriate LDAP documents for the recommended procedures. The bottom line is that if you think this sufficies as a specification of the way to use SRV records to locate LDAP, you're mistaken. (And I know a particular person who was on the IESG at the time who would be very amused to hear this mistake was made.) I don't know if this changes the previous assertion that this document shouldn't make such a recommendation. Either way is fine with me as long as it is clear what is meant. Ned _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 13:43:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06582 for ; Thu, 15 Aug 2002 13:43:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17974; Thu, 15 Aug 2002 13:39:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07924 for ; Thu, 15 Aug 2002 11:46:02 -0400 (EDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01430 for ; Thu, 15 Aug 2002 11:44:34 -0400 (EDT) Received: from mailscan-out1.cac.washington.edu (mailscan-out1.cac.washington.edu [140.142.32.17]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.06) with SMTP id g7FFjsej009651 for ; Thu, 15 Aug 2002 08:45:54 -0700 Received: FROM smtp.washington.edu BY mailscan-out1.cac.washington.edu ; Thu Aug 15 08:45:53 2002 -0700 Received: from [10.0.1.147] (12-231-112-60.client.attbi.com [12.231.112.60]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.06) with ESMTP id g7FFjqTb020096 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 15 Aug 2002 08:45:53 -0700 Date: Thu, 15 Aug 2002 08:45:57 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: Paul Leach , Michael Armijo , Levon Esibov , , Ned Freed , In-Reply-To: <26690956.1029337899@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id LAA07925 Subject: [ldapext] RE: draft-ietf-ldapext-locate Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit On Wed, 14 Aug 2002, [ISO-8859-1] Patrik Fältström wrote: > Example of a problem: > > Take the domain name issues, and the project which try to have LDAP > access to Whois data. > > We have whois data both at the registry and the registar about a domain > name. In the project, both records, the referral thing in the registry > and the actual whois info at the registrar use the same DN, and that is > exactly the dc components of the domain name itself. And, then the user > himself probably want/will have an LDAP server himself for the same DN. > > Example, my domain paf.se with "dc=paf, dc=se" might exists on three > different locations. > > The registry, the registrar and myself. The entry naming you propose for this application raises the question of the information model for the directory, and for this application, and whether they are consistent. The traditional information model for the X.500 directory is that a DN names a distinct entry, and that entry provides the same information regardless of the physical server it resides on; this is the same information model as the DNS. In practice, due to the lack of a global view of an X.500 DIT, it is common for different DSAs to contain entries with identical DNs but which contain different information; this puts the burden on the client (or application) to know the difference between the entries held by different servers. If the Whois application you describe intends to have exactly the same info in each of the DC-named entries, regardless of whether it is held by the registry, the registrar, or the domain name holder, then its requirements are perfectly well met by the draft-ldapext-locate scheme. The SRV record would contain pointers to each of the locations, and it wouldn't matter which the client went to. If, in this application, the information provided by the different servers for the same DN is different, then there's a problem. Either you've designed a case where SRV-record lookup won't work, so it's up to your application to figure out how to map from names to servers, and to distinguish the different kinds of servers; or you need to change your entry naming to reflect the fact that the logical entry held by the different servers about the same DNS name is a different entry. So which is it? - RL "Bob" _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 13:44:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06628 for ; Thu, 15 Aug 2002 13:44:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19085; Thu, 15 Aug 2002 13:41:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18977 for ; Thu, 15 Aug 2002 13:41:06 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06325 for ; Thu, 15 Aug 2002 13:39:44 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 15 Aug 2002 10:40:34 -0700 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Aug 2002 10:40:34 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 15 Aug 2002 10:40:34 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 15 Aug 2002 10:40:34 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 15 Aug 2002 10:40:34 -0700 Content-Class: urn:content-classes:message Subject: RE: [ldapext] draft-ietf-ldapext-locate MIME-Version: 1.0 Date: Thu, 15 Aug 2002 10:40:33 -0700 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_000E_01C24448.2E6091D0" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD04929813@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: [ldapext] draft-ietf-ldapext-locate thread-index: AcJEgAenmMq3QfEZSWCGn2g20fDc/AAAayjQ From: "Paul Leach" To: Cc: "Kurt D. Zeilenga" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Michael Armijo" , "Levon Esibov" , , , X-OriginalArrivalTime: 15 Aug 2002 17:40:34.0002 (UTC) FILETIME=[DB922320:01C24482] Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C24448.2E6091D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]=20 > Sent: Thursday, August 15, 2002 10:13 AM > To: Paul Leach > Cc: Kurt D. Zeilenga; Patrik F=E4ltstr=F6m; Michael Armijo; Levon=20 > Esibov; rlmorgan@washington.edu; ldapext@ietf.org; Ned Freed;=20 > ietf-ldap@paf.se > Subject: RE: [ldapext] draft-ietf-ldapext-locate >=20 >=20 >=20 > > "The format of the SRV RR >=20 > > Here is the format of the SRV RR, whose DNS type code is 33: >=20 > > _Service._Proto.Name TTL Class SRV Priority Weight=20 > Port Target >=20 > > (There is an example near the end of this document.) >=20 > > Service > > The symbolic name of the desired service, as=20 > defined in Assigned > > Numbers [STD 2] or locally. An underscore (_) is=20 > prepended to > > the service identifier to avoid collisions with DNS=20 > labels that > > occur in nature. > > ..." >=20 > > In the case of LDAP, the symbolic name is "LDAP". >=20 > Er, no. I remember this one... I wasn't an AD at the time but=20 > I was the IAB's liason to the IESG. There was strong=20 > objection from the IESG to this DNS ops document specifying=20 > how a particular application service should be located using=20 > SRV records. As a result the text was modified to include the=20 > following: >=20 > Note: LDAP is chosen as an example for illustrative purposes only, > and the LDAP examples used in this document should not be=20 > considered > a definitive statement on the recommended way for LDAP to use SRV > records. As described in the earlier applicability section, consult > the appropriate LDAP documents for the recommended procedures. >=20 > The bottom line is that if you think this sufficies as a=20 > specification of the way to use SRV records to locate LDAP,=20 > you're mistaken. (And I know a particular person who was on=20 > the IESG at the time who would be very amused to hear this=20 > mistake was made.) How about it 99% suffices. We would just need a one sentence (after boilerplate) RFC to say that locating an LDAP server given a domain name is done as per RFC 2782. Right? >=20 > I don't know if this changes the previous assertion that this=20 > document shouldn't make such a recommendation. Either way is=20 > fine with me as long as it is clear what is meant. I think it would be pretty easy to restructure the draft-ietf-ldapext-locate for that it was in two parts: 1. How to find LDAP server given domain name - use SRV records as per 2782 2. How to find LDAP server given DC laden DN - Derive domain name from DC laden DN - use step 1 But I'd have to check the current wording to see how much work that is. It would be just an editorial change. ------=_NextPart_000_000E_01C24448.2E6091D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkSzCCA0Aw ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIGPzCCBf+gAwIBAgIKdZ/59AACAAAB VjAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X DTAxMDkxNDAzMTY1MFoXDTAyMDkyMDIxMzMyOFowSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1p Y3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAupHMN0lJw9ae2Ic2yZBICCqeP2H6Re4B1Rnk+KETtF0S15jq 7ea5n/+z43Da9CqjunNJaLT7rX4o9NHUN7eP5aKlZ7aRP+EoT0wB51OPsjZKuFWptbdL7PEVHAuO UrOOjyZ0ITR432vqcJ/L3AouTyuCuN7/1kw9tMMRl5erzkUCAwEAAaOCBG0wggRpMBAGCSsGAQQB gjcVAQQDAgEBMCMGCSsGAQQBgjcVAgQWBBRdMJl7HuLsmpzfroTjjkV60iifVTAdBgNVHQ4EFgQU yURWSpATfKnzMwZr3tCZu+fIzukwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQD AgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUz8W6F/8txxCA9bkOmUpv9Jwr+xkwggI+ BgNVHR8EggI1MIICMTCCAi2gggIpoIICJYaB32xkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlh dGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKSxDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGX2h0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNv bS9DZXJ0RW5yb2xsL05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIo MSkuY3JshoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIw V2hpY2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludDCCAXMGCCsGAQUFBwEBBIIBZTCCAWEwgdUGCCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERF ViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMl MjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERD PW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgYYGCCsGAQUFBzAChnpodHRwOi8vd2hpY2EyLm50ZGV2Lm1pY3Jvc29m dC5jb20vQ2VydEVucm9sbC93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVy bWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDIpLmNydDAJBgcqhkjOOAQDAy8AMCwCFFMe +4NdwTMB4JPtUG8oni8k6DDeAhR524Ez1P2PwtOazvpFd7iVYMg9aDCCBmIwggXLoAMCAQICCkRj c78AAQAaXtAwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m dDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMjA4MDcxNjQx MTNaFw0wMjA5MjAyMTMzMjhaMIHHMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQB GRYJbWljcm9zb2Z0MRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxEDAOBgNVBAsTB0lNLVNlbGYxFzAV BgNVBAsTDkxpZ2h0bHlNYW5hZ2VkMREwDwYDVQQLEwhMb3dUQ08tRTETMBEGA1UEAxMKUGF1bCBM ZWFjaDErMCkGCSqGSIb3DQEJARYccGF1bGxlQHdpbmRvd3MubWljcm9zb2Z0LmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAl+n5rSPZqRfL6zy1NoJixbtV50ebFda2djq9D+UFhOxuaGWZ mQmqJWGc0WOAElvpSE311v42gLO+CAuJRPPEgZOKqX8p9SJi5pAYPMG1UkSMVi8Ri2nM82rxYq+v ZcV0CxLoMEGHNXtOjhXA64mcph1LHVNZ9CdNBtrEDV9ChccCAwEAAaOCA84wggPKMAsGA1UdDwQE AwIEMDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYF Kw4DAgcwCgYIKoZIhvcNAwcwPgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIjeDRiU6E15zDB4am hvscj9O/phWHp77iCY6xrfFNAgFxAgECMBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcV CgQOMAwwCgYIKwYBBQUHAwQwUwYDVR0RBEwwSqAqBgorBgEEAYI3FAIDoBwMGnBhdWxsZUBudGRl di5taWNyb3NvZnQuY29tgRxwYXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMB0GA1UdDgQWBBT1 y3RYpjRuAcwPrL2J2wUezKNSAzAfBgNVHSMEGDAWgBTJRFZKkBN8qfMzBmve0Jm758jO6TCCASYG A1UdHwSCAR0wggEZMIIBFaCCARGgggENhoHEbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENB LENOPVdISUNBMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMs Q049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZEaHR0 cDovL3doaWNhMy5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJU1NVRTMl MjBDQS5jcmwwggFCBggrBgEFBQcBAQSCATQwggEwMIG9BggrBgEFBQcwAoaBsGxkYXA6Ly8vQ049 TlRERVYlMjBJU1NVRTMlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MG4GCCsG AQUFBzAChmJodHRwOi8vd2hpY2EzLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9XSElD QTMubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMElTU1VFMyUyMENBKDEpLmNydDANBgkqhkiG 9w0BAQUFAAOBgQCatGM+Ii3m1xd/DXloVV8MkIT6yqQljhGyscpPNVKHW/NtwglVgWYMl7yLStnF c4TgBdWnsdG/weLDofE5fqNx0psiGUM4DbVkQGhHp2YqHwd472EswMelhRwx2bByfNXWZW5gMbP9 skh3MSe9KuoC+skVa73D7itkDg4BXgkn9zCCBqcwggYQoAMCAQICChRel0MAAAAAACgwDQYJKoZI hvcNAQEFBQAwTDELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRk ZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJvb3QgQ0EwHhcNMDExMTAxMjA1NzExWhcNMDIwOTIwMjEz MzI4WjBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEu MCwGA1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMjCCAbYwggErBgcq hkjOOAQBMIIBHgKBgQD4Ly2xZP3/BEVJKm5f8RYN3D0lcE0i1w2lCKMzyIcaEIC84swy1gpKY0Z4 R8RAzij8hRkw8ciXT6at5mgDHo7lJ3aPmEOsxwnxkN8hhZs50hPBtGGVs6B1ijVEZiGdTzlTLneI Fc6Mk7HEMv3sP7S1KvWJDls9rrRJYFlyTB35AQIVALpK4A0b7aa6zeQ1ZkPPC9iRcCjfAoGAZ7hM x51ULfa+kKU94Fo1HH3cDdrSm6db5w8oqxOJkj9+qa23p9kl3cPdioGshDQjF4LO8R+vSRPM/UG5 ir7LkkE6uivrzXDGHF16C4/ZoMAdZHU7UGtuoHhI92GmibmzXkbiMWNyvD3YiM14Pq/BY9RHNVC8 V2tuUNe+bJ17lQsDgYQAAoGABlYEqKplvCqnqB1HWeyQOfRQ5UJLtSTNGKkL6PPAcbxdWsN1JiDa mLDxvmTXYm8kWSuRkzSqrGPispNIDLOAmXRY79tX4IWD9IpsVhGP8U6C7ycNzZpNM6bEuBQgAVVf fSBa99Qsq7gSrPkkFA8EeikTolxKM5dOM01Z2BGdpfmjggNhMIIDXTASBgkrBgEEAYI3FQEEBQID AQADMCMGCSsGAQQBgjcVAgQWBBQYxRo0WCyvkaAaxWWDIpP6xv8VFTAdBgNVHQ4EFgQUz8W6F/8t xxCA9bkOmUpv9Jwr+xkwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgHGMA8G A1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUd8l0aSw5/jhl9IcFWAjOvbqX2hAwggE6BgNVHR8E ggExMIIBLTCCASmgggEloIIBIYaBzmxkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSxD Tj13aGljYXNhcm9vdGNhLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2 aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hk5odHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRE RVYlMjBTQSUyMFJvb3QlMjBDQS5jcmwwggFTBggrBgEFBQcBAQSCAUUwggFBMIHABggrBgEFBQcw AoaBs2xkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSxDTj1BSUEsQ049UHVibGljJTIw S2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1t aWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MHwGCCsGAQUFBzAChnBodHRwOi8vd2hpY2FzYXJvb3RjYS5udGRldi5taWNy b3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tX05U REVWJTIwU0ElMjBSb290JTIwQ0EuY3J0MBQGA1UdIAEB/wQKMAgwBgYEVR0gADANBgkqhkiG9w0B AQUFAAOBgQAxYiUUmrT3jDFqE+1g0gCnBxgfC3mMkIRtVA3sS+AZCB5QdVwHMIn5Vbcz+UHzq+GK S/fRM2ETd19y56KAaNFI5NSLPuuvZIYuzw0QCsVjb1o0JDT8Z60ebroLDDtlXOBnmasVjmc5PDyV KrlGtTyCLiWK9oZkNNUV4OJ/xruinzCCBqwwggZroAMCAQICChnMypwAAgAAAWAwCQYHKoZIzjgE AzBhMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEuMCwG A1UEAxMlTlRERVYgSW50ZXJtZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMjAeFw0wMTEwMjUwMDQw MjFaFw0wMjA5MjAyMTMzMjhaMHsxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZ FgltaWNyb3NvZnQxFTATBgoJkiaJk/IsZAEZFgVudGRldjEyMDAGA1UEAwwpTlRERVbjgIDvvKnv vZPvvZPvvZXvvYXvvKrvvLDvvK7jgIDjgovjgbEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMLpdqtuCBDrs6W5nglAbizKGz0nZ6Xc00ZGNF/toXvZbvRTRfan+wj1HzcLG4qBlcudEbmir08S Y2fL6lBS607lcrujUul9n5w5Nxm5CfFCO4SegOglrYaBiE7GJZia3cpRiR3T5J5TJ69GGWTJTnb9 IdLaoZNdzzx8jvydHrEnAgMBAAGjggSpMIIEpTAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQU qXZyJ4BnnmSuH+3DpPN82oJrYbswGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQD AgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUz8W6F/8txxCA9bkOmUpv9Jwr+xkwggKf BgNVHR8EggKWMIICkjCCAo6gggKKoIIChoaB32xkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlh dGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKSxDTj13aGljYTIsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGX2h0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNv bS9DZXJ0RW5yb2xsL05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIo MSkuY3JshoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIw V2hpY2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludIZfaHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYl MjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKS5jcmwwggFzBggrBgEFBQcB AQSCAWUwggFhMIHVBggrBgEFBQcwAoaByGxkYXA6Ly8vQ049TlRERVYlMjBJbnRlcm1lZGlhdGUl MjBTdWJvcmRpbmF0ZSUyMFdoaWNhMixDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29t P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGG BggrBgEFBQcwAoZ6aHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwv d2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb21fTlRERVYlMjBJbnRlcm1lZGlhdGUlMjBTdWJvcmRp bmF0ZSUyMFdoaWNhMigyKS5jcnQwCQYHKoZIzjgEAwMwADAtAhUArQS6yf+6F2yfZOaFlrSUHaiz PYMCFAkXqtidhCmi1K1WdMAiPGRNQTrYMIIG/zCCBmigAwIBAgIKcRZeBgAAAAvo0DANBgkqhkiG 9w0BAQUFADB7MRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0 MRUwEwYKCZImiZPyLGQBGRYFbnRkZXYxMjAwBgNVBAMMKU5UREVW44CA77yp772T772T772V772F 77yq77yw77yu44CA44KL44GxMB4XDTAyMDcyNjAxMjc1M1oXDTAyMDkyMDIxMzMyOFowgZoxEzAR BgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJk/Is ZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQxETAP BgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCh42bvExv/cQoRw2WkfSbTgPyywQhHjdtr/hfjbc3TFS7lhhGtOwcU0oxO3XNHdOiY GeKnh/x3Dblte6lNUrwVGV/thcTCFMUSoxOhrgm5a1iC9Kus+YEr250H9zEeu6fkfX4SeUpt1DDi A7yb5XOOfhtfS8vfsz1ariZttUej6QIDAQABo4IEaDCCBGQwCwYDVR0PBAQDAgeAMD4GCSsGAQQB gjcVBwQxMC8GJysGAQQBgjcVCI3g0YlOhNecwweGpob7HI/Tv6YVgr+c9nyG3uaAVAIBcQIBAzAT BgNVHSUEDDAKBggrBgEFBQcDBDAtBgNVHSAEJjAkMCIGICsGAQQBgjcVCI3g0YlOhNecwweGpob7 HI/Tv6YVAYMRMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwUwYDVR0RBEwwSqAqBgorBgEE AYI3FAIDoBwMGnBhdWxsZUBudGRldi5taWNyb3NvZnQuY29tgRxwYXVsbGVAd2luZG93cy5taWNy b3NvZnQuY29tMB0GA1UdDgQWBBSfEaNowL9yqWZMmp4708X5d6ZTCzAfBgNVHSMEGDAWgBSpdnIn gGeeZK4f7cOk83zagmthuzCCAX8GA1UdHwSCAXYwggFyMIIBbqCCAWqgggFmhoHsbGRhcDovLy9D Tj1OVERFViEzMDAwIWZmMjkhZmY1MyFmZjUzIWZmNTUhZmY0NSFmZjJhIWZmMzAhZmYyZS0zNTkz MSxDTj13aGljYWludGwsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp Y2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZp Y2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSG dWh0dHA6Ly93aGljYWludGwubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWITMw MDAhZmYyOSFmZjUzIWZmNTMhZmY1NSFmZjQ1IWZmMmEhZmYzMCFmZjJlITMwMDAhMzA4YiEzMDcx LmNybDCCAZoGCCsGAQUFBwEBBIIBjDCCAYgwgeIGCCsGAQUFBzAChoHVbGRhcDovLy9DTj1OVERF ViEzMDAwIWZmMjkhZmY1MyFmZjUzIWZmNTUhZmY0NSFmZjJhIWZmMzAhZmYyZS0zNTkzMSxDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RD bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGgBggrBgEFBQcwAoaBk2h0dHA6Ly93aGljYWlu dGwubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhaW50bC5udGRldi5taWNyb3Nv ZnQuY29tX05UREVWITMwMDAhZmYyOSFmZjUzIWZmNTMhZmY1NSFmZjQ1IWZmMmEhZmYzMCFmZjJl ITMwMDAhMzA4YiEzMDcxLmNydDANBgkqhkiG9w0BAQUFAAOBgQCoM/gG0V19xqqB++fMgMQWg5W5 cMvpd7m84Bbt9qXhFtTcLJ9CXhdBxNN60igTUPC0+4f507cQMZGdZFEPZjXkZ3gnPApKTD4SVJTb TUzat8Gy+iLJ81HwfDzxoWltIsFIA8htS4FZaevDT7O7YNFhi9ig2Nb1Si3f2juhfeb+0TGCAtAw ggLMAgEBMIGJMHsxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3Nv ZnQxFTATBgoJkiaJk/IsZAEZFgVudGRldjEyMDAGA1UEAwwpTlRERVbjgIDvvKnvvZPvvZPvvZXv vYXvvKrvvLDvvK7jgIDjgovjgbECCnEWXgYAAAAL6NAwCQYFKw4DAhoFAKCCAZwwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwODE1MTc0MDMyWjAjBgkqhkiG9w0B CQQxFgQU64cvlvZzrlBcuSzyefV3YS4IP0kwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAEMVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UE ChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgpE Y3O/AAEAGl7QMGoGCyqGSIb3DQEJEAILMVugWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgpEY3O/AAEA Gl7QMA0GCSqGSIb3DQEBAQUABIGAUL2ZRl0S93AdB7/UAZMNIT0Viv/ThD73YMmqJAZvuAe2r/Id 8/ZrKzYQwjkrRCuBrehKEBnHJp0OqVwqr2N/sEpEyqy4kP37WpEKAdkjh9fqcuWInX81B0huSHHv YyfehclWwGXGI18eYTBm00h2BF8fL9D5mbPL2sFK807SL9sAAAAAAAA= ------=_NextPart_000_000E_01C24448.2E6091D0-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 14:13:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07889 for ; Thu, 15 Aug 2002 14:13:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22582; Thu, 15 Aug 2002 14:05:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22550 for ; Thu, 15 Aug 2002 14:05:45 -0400 (EDT) Received: from carnelian.propagation.net (carnelian.propagation.net [209.164.120.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07495 for ; Thu, 15 Aug 2002 14:04:24 -0400 (EDT) Received: from CELLO (c-24-130-38-213.we.client2.attbi.com [24.130.38.213]) by carnelian.propagation.net (8.8.5/8.8.5) with SMTP id NAA23601; Thu, 15 Aug 2002 13:05:26 -0500 From: "Howard Chu" To: "Chris Harding" , Cc: , "'Liben, Michael \(GTS\)'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , , , , , "Alexis Bor" Subject: RE: [ldapext] Directory Best Practice Guide Date: Thu, 15 Aug 2002 11:05:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.1.0.14.1.20020815174302.00b06740@mailhome.rdg.opengroup.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit I work with the OpenLDAP project and would be happy to contribute. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support > -----Original Message----- > From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On Behalf Of > Chris Harding > Sent: Thursday, August 15, 2002 9:45 AM > To: christine.yoon@us.pwcglobal.com > Cc: ldapext@ietf.org; 'Liben, Michael (GTS)'; 'Patrik Fältström'; > dif-members@opengroup.org; michael.d.compton@us.pwcglobal.com; > jamie.quick@us.pwcglobal.com; brian.jensen@us.pwcglobal.com; Alexis Bor > Subject: [ldapext] Directory Best Practice Guide > > > Hi, Christine - > > That's great! We need lots more volunteers, though. How about it, folks? > > At 10:40 15/08/2002 -0400, christine.yoon@us.pwcglobal.com wrote: > > >Chris, > > > >We (PwC) have many years of experience in directory/security > >implementation for various clients including Fortune 500 companies. > >I would like to volunteer to author the Directory Best Practice Guide. > > > > > >-Christine Yoon > >PricewaterhouseCoopers > >(201)981-1172 - cell > >(732)706-3559 - office > > > > > > > > > > > > Chris > > Harding > > > > > > > up.org> cc: , > > "'Liben, Michael \(GTS\)'" , "'Patrik > > Sent by: Fältström'" > > , dif-members@opengroup.org > > ldapext-admin@ietf Subject: RE: [ldapext] > > draft-ietf-ldapext-locate > > .org > > > > 08/15/2002 > > 06:20 > > > > AM > > > > > > > > > > > > > > > > > > > > > > > >Hi, Alexis - > > > >A Directory Best Practices Guide is something that is clearly needed. I > >believe that the Directory Interoperability Forum should support its > >creation and contribute to it. The DIF could for example provide > >publication or web page hosting facilities if needed, and could provide > >some review effort. However, I don't believe that the DIF could on its own > >provide the technical authoring and review effort needed to deliver an > >authoritative guide. > > > >Because there is (as you point out) a need for rapid evolution, a set of > >web pages would be far and away the best medium for such a guide. What we > >need is a set of contributors, a review group, and an editorial committee, > >working within the framework of an established review and publications > >procedure. This procedure must be public and must allow rapid turnaround > >from authoring to publication - I would say within 2 months at > the outside. > > > >Perhaps it could be handled as a kind of Open Source project. > > > >I believe (the members make the decisions, I just support them) that the > >DIF would be interested in co-ordinating or participating in a project of > >this nature. > > > >At 16:00 14/08/2002 -0400, Alexis Bor wrote: > > >I proved to myself and others (while I was at Boeing doing R&D work in > > >Directory) back in 1992 that putting any meaning into a DN is not a good > > >practice. We took the example of a company of 100,000 and looked at the > > >different approaches for DN's - Geographic, Political, Hybrid and > > >others. > > > > > >It became clear that it would be a maintenance headache and cause lots > > >of stress on the overall infrastructure. It was very hard to convince > > >most people for a long time until some work that Jeff Hodges did at > > >Stanford got a lot of attention in the late 90's. > > > > > >A real hard piece of work to put forward is a best practices document. > > >The number of opinions will typically exceed the number of people > > >working on the document. What we learned in the mid 90's was that such > > >a document evolves faster than the review cycle (part of an EMA effort > > >to write a white paper on directory best practices), making it out of > > >date before you even finish the review of it. However, with all of the > > >experience that everyone is getting, it may be worth resurrecting the > > >idea again. > > > > > >Perhaps an industry group can step up to the challenge - any takers? > > > > > >-- Alexis > > > > > >Alexis Bor > > >Directory Works, Inc. > > >www.directoryworks.com > > > > > > > > >-----Original Message----- > > >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf > > >Of Liben, Michael (GTS) > > >Sent: Tuesday, August 13, 2002 5:32 PM > > >To: 'Patrik Fältström' > > >Cc: ldapext@ietf.org > > >Subject: RE: [ldapext] draft-ietf-ldapext-locate > > > > > >In general, divining any meaning from a distinguished name is not good > > >practice (my $.02). The implications are that your app will likely > > >break. The SHOULD NOT allows you impart meaning to your > > >distinguished name if you so choose. A MUST NOT would be an absolute > > >prohibition. > > > > > > > > > > > >-----Original Message----- > > >From: Patrik Fältström [mailto:paf@cisco.com] > > >Sent: Tuesday, August 13, 2002 5:54 AM > > >To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; > > >rlmorgan@washington.edu > > >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > > >Subject: [ldapext] draft-ietf-ldapext-locate > > > > > >Comments from the IESG: > > >------- > > >The document says: > > > If there are no > > > matching SRV records available for the converted DN the client > > >SHOULD > > > NOT attempt to 'walk the tree' by removing the least significant > > > portion of the constructed fully qualified domain name. > > > > > >The meaning of "SHOULD NOT" is "don't do this unless you understand the > > >implications". Well, I don't know where to look to understand the > > >implications. > > >Thus I think it would be useful to either make it a MUST NOT, or explain > > >something about the implications of using shorter labels. > > > > > >Alternatively specify SHOULD NOT do this in general, but MUST NOT ever > > >use this with just one label (i.e. MUST NOT look for _ldap._tcp.) > > >or something similar. > > > > > >------- > > >The document is unclear (see next note) on: > > > > > >(a) When this is to be used (only when not having the foggiest clue > > >where a > > >record with a specific DN is, or every time a record is to be accessed?) > > > > > >(b) How to handle the case when one have a DN which have both dc and > > >non-dc > > >components. Example of this is when two records stored on two different > > >servers share the same dc components. IF those records per definition > > >(of > > >this document) have to be stored on the same server, or referrals have > > >to > > >be stored on them to point to the other, then this document has a scope > > >which is larger than at first glance. I.e. part from stating how to > > >locate > > >a record using DNS, it also has an implicit result that DC is _the_ > > >naming > > >convention for the Internet. Please explain. > > > > > >------- > > >This document define a conversion that is over-restrictive. > > > > > > The output domain name is initially empty. The DN is processed > > >in > > > right-to-left order (i.e., beginning with the first RDN in the > > > sequence of RDNs). An RDN is able to be converted if it (1) > > > consists of a single AttributeTypeAndValue; (2) the attribute > > >type > > > is "DC"; and (3) the attribute value is non-null. If it can be > > > converted, the attribute value is used as a domain name > > >component > > > (label). The first such value becomes the rightmost (i.e., most > > > significant) domain name component, and successive > converted RDN > > > values extend to the left. If an RDN cannot be converted, > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > processing stops. If the output domain name is empty when > > > ^^^^^^^^^^^^^^^^^ > > > processing stops, the DN cannot be converted into a > domain name. > > > > > >The underscored text should be removed and replaced with text that > > >states the non-DC RDN's are skipped over. So for example the DN: > > > > > > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, > > > dc=edu > > > > > >Can be unambiguously translated into: > > > > > > lees.mit.edu > > > > > >Yet the underscored words make this translation invalid. With the > > >Underscored rule in place this DN would convert to just 'mit.edu' > > >which is not the desired result. > > > > > >The additional flexibility offered will permit us to convert existing > > >PKI systems to make use of this feature without requiring all > > >certificates to be re-issued. It will also permit us to create DIT's > > >that can be delegated at more points rather then requiring all > > >structure to be at the very top where the DC components are, prior to > > >any non-DC component. > > > > > >For example if MIT had a DIT with a top level name of: > > > > > > o=MIT,c=US > > > > > >and a subordinate lab wanted to use this document, they could have a > > >delegated subtree like: > > > > > > ou=Lab for X,o=MIT,c=US > > > > > >and then add a DC component below this as: > > > > > > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US > > > > > >Under my more flexible approach this would work. Without the > > >flexibility they would be SOL until MIT redid its entire DIT to > > >be: > > > > > > o=MIT,c=US,dc=mit,dc=edu > > > > > >and then they would have to be jointed in as: > > > > > > o=MIT,c=US,dc=labx,dc=mit,dc=edu > > > > > >Ned: I have three concerns here: > > > > > >(0) It isn't clear when this approach is supposed to be used. DNs are an > > > integral part of *every* LDAP operation. Is it the intent that > > >an > > >LDAP > > > client check every DN it sees for DC fields and if it > finds them > > >use > > > this approach. Or is it only appropriate in specific > situations? > > > > > >(1) This document specifies two things: How to translate a DN to a DNS > > > name and how to use a DNS name to locate a corresponding LDAP > > >server. > > > The document seems to imply that the latter is only used when a > > >DNS > > > name is produced by the former. I wonder if this restriction is > > >a > > >good > > > idea: Isn't the ability to use SRV records to locate more > > >generally > > > useful than this limited context? > > > > > > The answer to this may be no, but if so, the rationale for that > > >answer > > > should be part of the specification. > > > > > >(2) I don't see any provision for fallback to A records if SRV records > > > don't exist. I can easily see this being a Bad Idea, if so, > > >there > > > should be an explicit prohibition of it in the document along > > >with > > > some explanation of why it is a bad idea. > > > > > > > > > > > >------- > > >References should be split in normative and non-normative. > > >------- > > >I wonder about the reference to RFC1700, which has been obsoleted > > >by RFC3232, and that RFC actuallt talks about a DB that contains > > >the info. So How should this doc refer to that? > > >------- > > >Needs better abstract; doesn't even use the word "SRV". (and the rfc > > >editor will surely complain when they get it...) > > > > > >Might be good to use SRV in the title as well, as opposed to just > > >"DNS". But this I'm less concerned about, as there are two steps, and > > >only the second step is SRV records. > > > > > >E.g., maybe change: > > > > > > Discovering LDAP Services with DNS > > > > > >To something like: > > > > > > Discovering LDAP Services with DNS SRV Resource Records > > > > > >However, the rfc editor probably won't like the abbreviation > > >"SRV". Unfortunately, I don't think the acronym expands into anything > > >useful. > > >------- > > >I have three concerns here: > > > > > >(0) It isn't clear when this approach is supposed to be used. DNs are an > > > integral part of *every* LDAP operation. Is it the intent that an > > >LDAP > > > client check every DN it sees for DC fields and if it > finds them use > > > this approach. Or is it only appropriate in specific situations? > > > > > >(1) This document specifies two things: How to translate a DN to a DNS > > > name and how to use a DNS name to locate a corresponding LDAP > > >server. > > > The document seems to imply that the latter is only used when a DNS > > > name is produced by the former. I wonder if this restriction is a > > >good > > > idea: Isn't the ability to use SRV records to locate more generally > > > useful than this limited context? > > > > > > The answer to this may be no, but if so, the rationale for that > > >answer > > > should be part of the specification. > > > > > >(2) I don't see any provision for fallback to A records if SRV records > > > don't exist. I can easily see this being a Bad Idea, if so, there > > > should be an explicit prohibition of it in the document along with > > > some explanation of why it is a bad idea. > > > > > > > > > > > > > > > > > >_______________________________________________ > > >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 > > > > > >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 > >======================================================================== > >The Open Group Conference > >Boundaryless Information Flow: The Role of Open Source > >Cannes, France, 14-18th October > >http://www.opengroup.org/cannes2002 > >======================================================================== > > > > > >_______________________________________________ > >Ldapext mailing list > >Ldapext@ietf.org > >https://www1.ietf.org/mailman/listinfo/ldapext > > > > > > > > > >_________________________________________________________________ > > The information transmitted is intended only for the person or > > entity to which it is addressed and may contain confidential > > and/or privileged material. Any review, retransmission, > > dissemination or other use of, or taking of any action > in reliance > > upon, this information by persons or entities other than the > > intended recipient is prohibited. If you received > this in error, > > please contact the sender and delete the material from any > > computer. > > > > > >_______________________________________________ > >Ldapext mailing list > >Ldapext@ietf.org > >https://www1.ietf.org/mailman/listinfo/ldapext > > > 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 > ======================================================================== > The Open Group Conference > Boundaryless Information Flow: The Role of Open Source > Cannes, France, 14-18th October > http://www.opengroup.org/cannes2002 > ======================================================================== > > > _______________________________________________ > 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 Aug 15 14:27:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09005 for ; Thu, 15 Aug 2002 14:27:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23367; Thu, 15 Aug 2002 14:16:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23297 for ; Thu, 15 Aug 2002 14:16:29 -0400 (EDT) Received: from mxsmta02.inithost.com (104-209.235.30.interliant.com [209.235.30.104] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07976 for ; Thu, 15 Aug 2002 14:15:09 -0400 (EDT) Received: from alexis98 ([168.205.9.246]) by mxsmta02.inithost.com (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20020815181535.WNAS5866.mxsmta02.inithost.com@alexis98>; Thu, 15 Aug 2002 14:15:35 -0400 From: "Alexis Bor" To: "'Chris Harding'" , Cc: , "'Liben, Michael \(GTS\)'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , , , , Subject: RE: [ldapext] Directory Best Practice Guide Date: Thu, 15 Aug 2002 14:16:26 -0400 Message-ID: <003f01c24487$df435200$f609cda8@directoryworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.1.20020815174302.00b06740@mailhome.rdg.opengroup.org> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA23298 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit Chris, I would be more than happy to help and work on this. -- Alexis Alexis Bor Directory Works, Inc. www.directoryworks.com -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf Of Chris Harding Sent: Thursday, August 15, 2002 12:45 PM To: christine.yoon@us.pwcglobal.com Cc: ldapext@ietf.org; 'Liben, Michael (GTS)'; 'Patrik Fältström'; dif-members@opengroup.org; michael.d.compton@us.pwcglobal.com; jamie.quick@us.pwcglobal.com; brian.jensen@us.pwcglobal.com; Alexis Bor Subject: [ldapext] Directory Best Practice Guide Hi, Christine - That's great! We need lots more volunteers, though. How about it, folks? At 10:40 15/08/2002 -0400, christine.yoon@us.pwcglobal.com wrote: >Chris, > >We (PwC) have many years of experience in directory/security >implementation for various clients including Fortune 500 companies. >I would like to volunteer to author the Directory Best Practice Guide. > > >-Christine Yoon >PricewaterhouseCoopers >(201)981-1172 - cell >(732)706-3559 - office > > > > > > Chris > Harding > > > up.org> cc: , > "'Liben, Michael \(GTS\)'" , "'Patrik > Sent by: Fältström'" > , dif-members@opengroup.org > ldapext-admin@ietf Subject: RE: [ldapext] > draft-ietf-ldapext-locate > .org > > 08/15/2002 > 06:20 > > AM > > > > > > > > > > > >Hi, Alexis - > >A Directory Best Practices Guide is something that is clearly needed. I >believe that the Directory Interoperability Forum should support its >creation and contribute to it. The DIF could for example provide >publication or web page hosting facilities if needed, and could provide >some review effort. However, I don't believe that the DIF could on its own >provide the technical authoring and review effort needed to deliver an >authoritative guide. > >Because there is (as you point out) a need for rapid evolution, a set of >web pages would be far and away the best medium for such a guide. What we >need is a set of contributors, a review group, and an editorial committee, >working within the framework of an established review and publications >procedure. This procedure must be public and must allow rapid turnaround >from authoring to publication - I would say within 2 months at the outside. > >Perhaps it could be handled as a kind of Open Source project. > >I believe (the members make the decisions, I just support them) that the >DIF would be interested in co-ordinating or participating in a project of >this nature. > >At 16:00 14/08/2002 -0400, Alexis Bor wrote: > >I proved to myself and others (while I was at Boeing doing R&D work in > >Directory) back in 1992 that putting any meaning into a DN is not a good > >practice. We took the example of a company of 100,000 and looked at the > >different approaches for DN's - Geographic, Political, Hybrid and > >others. > > > >It became clear that it would be a maintenance headache and cause lots > >of stress on the overall infrastructure. It was very hard to convince > >most people for a long time until some work that Jeff Hodges did at > >Stanford got a lot of attention in the late 90's. > > > >A real hard piece of work to put forward is a best practices document. > >The number of opinions will typically exceed the number of people > >working on the document. What we learned in the mid 90's was that such > >a document evolves faster than the review cycle (part of an EMA effort > >to write a white paper on directory best practices), making it out of > >date before you even finish the review of it. However, with all of the > >experience that everyone is getting, it may be worth resurrecting the > >idea again. > > > >Perhaps an industry group can step up to the challenge - any takers? > > > >-- Alexis > > > >Alexis Bor > >Directory Works, Inc. > >www.directoryworks.com > > > > > >-----Original Message----- > >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf > >Of Liben, Michael (GTS) > >Sent: Tuesday, August 13, 2002 5:32 PM > >To: 'Patrik Fältström' > >Cc: ldapext@ietf.org > >Subject: RE: [ldapext] draft-ietf-ldapext-locate > > > >In general, divining any meaning from a distinguished name is not good > >practice (my $.02). The implications are that your app will likely > >break. The SHOULD NOT allows you impart meaning to your > >distinguished name if you so choose. A MUST NOT would be an absolute > >prohibition. > > > > > > > >-----Original Message----- > >From: Patrik Fältström [mailto:paf@cisco.com] > >Sent: Tuesday, August 13, 2002 5:54 AM > >To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; > >rlmorgan@washington.edu > >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > >Subject: [ldapext] draft-ietf-ldapext-locate > > > >Comments from the IESG: > >------- > >The document says: > > If there are no > > matching SRV records available for the converted DN the client > >SHOULD > > NOT attempt to 'walk the tree' by removing the least significant > > portion of the constructed fully qualified domain name. > > > >The meaning of "SHOULD NOT" is "don't do this unless you understand the > >implications". Well, I don't know where to look to understand the > >implications. > >Thus I think it would be useful to either make it a MUST NOT, or explain > >something about the implications of using shorter labels. > > > >Alternatively specify SHOULD NOT do this in general, but MUST NOT ever > >use this with just one label (i.e. MUST NOT look for _ldap._tcp.) > >or something similar. > > > >------- > >The document is unclear (see next note) on: > > > >(a) When this is to be used (only when not having the foggiest clue > >where a > >record with a specific DN is, or every time a record is to be accessed?) > > > >(b) How to handle the case when one have a DN which have both dc and > >non-dc > >components. Example of this is when two records stored on two different > >servers share the same dc components. IF those records per definition > >(of > >this document) have to be stored on the same server, or referrals have > >to > >be stored on them to point to the other, then this document has a scope > >which is larger than at first glance. I.e. part from stating how to > >locate > >a record using DNS, it also has an implicit result that DC is _the_ > >naming > >convention for the Internet. Please explain. > > > >------- > >This document define a conversion that is over-restrictive. > > > > The output domain name is initially empty. The DN is processed > >in > > right-to-left order (i.e., beginning with the first RDN in the > > sequence of RDNs). An RDN is able to be converted if it (1) > > consists of a single AttributeTypeAndValue; (2) the attribute > >type > > is "DC"; and (3) the attribute value is non-null. If it can be > > converted, the attribute value is used as a domain name > >component > > (label). The first such value becomes the rightmost (i.e., most > > significant) domain name component, and successive converted RDN > > values extend to the left. If an RDN cannot be converted, > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > processing stops. If the output domain name is empty when > > ^^^^^^^^^^^^^^^^^ > > processing stops, the DN cannot be converted into a domain name. > > > >The underscored text should be removed and replaced with text that > >states the non-DC RDN's are skipped over. So for example the DN: > > > > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, > > dc=edu > > > >Can be unambiguously translated into: > > > > lees.mit.edu > > > >Yet the underscored words make this translation invalid. With the > >Underscored rule in place this DN would convert to just 'mit.edu' > >which is not the desired result. > > > >The additional flexibility offered will permit us to convert existing > >PKI systems to make use of this feature without requiring all > >certificates to be re-issued. It will also permit us to create DIT's > >that can be delegated at more points rather then requiring all > >structure to be at the very top where the DC components are, prior to > >any non-DC component. > > > >For example if MIT had a DIT with a top level name of: > > > > o=MIT,c=US > > > >and a subordinate lab wanted to use this document, they could have a > >delegated subtree like: > > > > ou=Lab for X,o=MIT,c=US > > > >and then add a DC component below this as: > > > > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US > > > >Under my more flexible approach this would work. Without the > >flexibility they would be SOL until MIT redid its entire DIT to > >be: > > > > o=MIT,c=US,dc=mit,dc=edu > > > >and then they would have to be jointed in as: > > > > o=MIT,c=US,dc=labx,dc=mit,dc=edu > > > >Ned: I have three concerns here: > > > >(0) It isn't clear when this approach is supposed to be used. DNs are an > > integral part of *every* LDAP operation. Is it the intent that > >an > >LDAP > > client check every DN it sees for DC fields and if it finds them > >use > > this approach. Or is it only appropriate in specific situations? > > > >(1) This document specifies two things: How to translate a DN to a DNS > > name and how to use a DNS name to locate a corresponding LDAP > >server. > > The document seems to imply that the latter is only used when a > >DNS > > name is produced by the former. I wonder if this restriction is > >a > >good > > idea: Isn't the ability to use SRV records to locate more > >generally > > useful than this limited context? > > > > The answer to this may be no, but if so, the rationale for that > >answer > > should be part of the specification. > > > >(2) I don't see any provision for fallback to A records if SRV records > > don't exist. I can easily see this being a Bad Idea, if so, > >there > > should be an explicit prohibition of it in the document along > >with > > some explanation of why it is a bad idea. > > > > > > > >------- > >References should be split in normative and non-normative. > >------- > >I wonder about the reference to RFC1700, which has been obsoleted > >by RFC3232, and that RFC actuallt talks about a DB that contains > >the info. So How should this doc refer to that? > >------- > >Needs better abstract; doesn't even use the word "SRV". (and the rfc > >editor will surely complain when they get it...) > > > >Might be good to use SRV in the title as well, as opposed to just > >"DNS". But this I'm less concerned about, as there are two steps, and > >only the second step is SRV records. > > > >E.g., maybe change: > > > > Discovering LDAP Services with DNS > > > >To something like: > > > > Discovering LDAP Services with DNS SRV Resource Records > > > >However, the rfc editor probably won't like the abbreviation > >"SRV". Unfortunately, I don't think the acronym expands into anything > >useful. > >------- > >I have three concerns here: > > > >(0) It isn't clear when this approach is supposed to be used. DNs are an > > integral part of *every* LDAP operation. Is it the intent that an > >LDAP > > client check every DN it sees for DC fields and if it finds them use > > this approach. Or is it only appropriate in specific situations? > > > >(1) This document specifies two things: How to translate a DN to a DNS > > name and how to use a DNS name to locate a corresponding LDAP > >server. > > The document seems to imply that the latter is only used when a DNS > > name is produced by the former. I wonder if this restriction is a > >good > > idea: Isn't the ability to use SRV records to locate more generally > > useful than this limited context? > > > > The answer to this may be no, but if so, the rationale for that > >answer > > should be part of the specification. > > > >(2) I don't see any provision for fallback to A records if SRV records > > don't exist. I can easily see this being a Bad Idea, if so, there > > should be an explicit prohibition of it in the document along with > > some explanation of why it is a bad idea. > > > > > > > > > > > >_______________________________________________ > >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 > > >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 >======================================================================= = >The Open Group Conference >Boundaryless Information Flow: The Role of Open Source >Cannes, France, 14-18th October >http://www.opengroup.org/cannes2002 >======================================================================= = > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > > > >_________________________________________________________________ > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential > and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance > upon, this information by persons or entities other than the > intended recipient is prohibited. If you received this in error, > please contact the sender and delete the material from any > computer. > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext 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 ======================================================================== The Open Group Conference Boundaryless Information Flow: The Role of Open Source Cannes, France, 14-18th October http://www.opengroup.org/cannes2002 ======================================================================== _______________________________________________ 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 Aug 15 14:35:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09553 for ; Thu, 15 Aug 2002 14:35:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25143; Thu, 15 Aug 2002 14:31:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25108 for ; Thu, 15 Aug 2002 14:30:57 -0400 (EDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09133 for ; Thu, 15 Aug 2002 14:29:37 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g7FIUrkC023675; Thu, 15 Aug 2002 18:30:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020815111448.02962c98@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 Aug 2002 11:30:36 -0700 To: ned.freed@mrochek.com From: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-ietf-ldapext-locate Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , micharm@microsoft.com, paulle@microsoft.com, levone@microsoft.com, rlmorgan@washington.edu, ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se In-Reply-To: <01KLBN5PE4D60001B1@mauve.mrochek.com> References: <"Your message dated Tue, 13 Aug 2002 21:36:05 -0700" <5.1.0.14.0.20020813201324.0674c688@127.0.0.1> <24876124.1029218035@localhost> <5.1.0.14.0.20020813201324.0674c688@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org At 09:57 AM 2002-08-15, ned.freed@mrochek.com wrote: >I'm going to take the liberty of responding directly here. > >> >(0) It isn't clear when this approach is supposed to be used. DNs are an >> >integral part of *every* LDAP operation. Is it the intent that an >> >LDAP client check every DN it sees for DC fields and if it finds them use >> >this approach. Or is it only appropriate in specific situations? > >> It is intended to be a general mechanism for locating LDAP servers >> having knowledge of directory objects associated with a DN in >> absence of location information. This DN may have been provided >> to the application via LDAP or other means. If the DN was provided >> with location information, such as a LDAP URL with host part, >> that information should be used. Howeer, where the DN is provided >> without any location information, this mechanism provides a means, >> for a subset of DNs (those using RFC 2247 naming), for the >> application to locate servers with knowledge of the DN. > >> This application may be an LDAP client or server. OpenLDAP's server, >> for example, can use this mechanism to generate referrals to clients >> requesting DN which it otherwise has no knowledge of. > >This is precisely the sort of thing I'm afraid of. OpenLDAP does this but I >doubt SunOne Directory Server (to pick a specific example) does. And given this >document doesn't spell out when this is supposed to be used you cannot claim >that the issue is Sun's failure to implement this standard. OpenLDAP supports a particular experimental service, described in RFC 3088, which uses this location mechanism. What I think you asking us to clarify is when should this mechanism be implemented/used. My answer to this is, the mechanism should be implemented/used as detailed in the technical specification for the application (or protocol) requiring its use. That is, I agree that implementations should not use this mechanism unless they implement a particular technical specification which prescribes use of the mechanism. This should be clarified. >THe opposite situation is also a concern. Suppose I have an LDAP library that >implements this unconditionally and I try to use that library in a situation >where I don't want it to happen. (Uses of DC DNs that don't expect this to >happen do exist, you know; the product I work on in my day job is an example of >this.) > >This can be fixed in a bunch of ways. The most obvious one would be to say that >this should be implemented in the following places and whether or not it is >used needs to be configurable. I don't the IETF should attempt to draw lines of what belongs in the application-specific code versus a library implementing an API. Requirements should be placed upon the "implementation". It is implementor's choice on wether to use libraries or not, which libraries to use, etc.. But regardless of the choices made, the resulting implementation needs to meet all implementation requirements. Now, in a technical specification for an LDAP API, that specification should clearly state where the location is to be used in implemented by providers of the API. >> >(1) This document specifies two things: How to translate a DN to a DNS >> >name and how to use a DNS name to locate a corresponding LDAP >> >server. > >> I argue that the document specifies one process, to locate LDAP >> servers with knowledge of a particular DN, which has two steps. > >> >The document seems to imply that the latter is only used when a DNS >> >name is produced by the former. I wonder if this restriction is a >> >good idea: Isn't the ability to use SRV records to locate more generally >> >useful than this limited context? > >> I don't believe this document restricts how DNS SRV records >> can be used. It also doesn't restrict construction of additional >> processes for locating LDAP servers with knowledge of a particular >> DN. In fact, draft-zeilenga-ldap-x500-locate suggests a process >> for DNs using geo-political naming. > >> Additionally, DNS SRVs could be used to answer questions such >> as "Are there LDAP servers associated with this domain?". > >This is the separate case I was thinking of. > >> Of course, this would be followed by, "What DN is used by >> the owner of this domain for their objects?". If a listed >> server provides 100s of namingContext, which one is the right one? >> Luckily, we have RFC 2247 which says how the owner of the >> domain should name objects. > >Then you should make it clear that this document specifies a single >process, and that it does not specify a process for locating LDAP >servers for a given domain. > > Ned > > >_______________________________________________ >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 Aug 15 15:44:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13213 for ; Thu, 15 Aug 2002 15:44:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29906; Thu, 15 Aug 2002 15:37:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23899 for ; Thu, 15 Aug 2002 14:19:26 -0400 (EDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08188 for ; Thu, 15 Aug 2002 14:18:07 -0400 (EDT) Received: from gmp1-mail1.UK.Sun.COM ([129.156.85.200]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24379; Thu, 15 Aug 2002 12:19:05 -0600 (MDT) Received: from sr-egmp02-10 (sr-egmp02-10 [129.156.85.116]) by gmp1-mail1.UK.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.1p1) with SMTP id g7FIJ3d28049; Thu, 15 Aug 2002 19:19:04 +0100 (BST) Message-Id: <200208151819.g7FIJ3d28049@gmp1-mail1.UK.Sun.COM> Date: Thu, 15 Aug 2002 19:19:03 +0100 (BST) From: Michael Haines - Sun Reply-To: Michael Haines - Sun Subject: RE: [ldapext] Directory Best Practice Guide To: c.harding@opengroup.org, christine.yoon@us.pwcglobal.com, alexis.bor@directoryworks.com Cc: ldapext@ietf.org, mliben@exchange.ml.com, paf@cisco.com, dif-members@opengroup.org, michael.d.compton@us.pwcglobal.com, jamie.quick@us.pwcglobal.com, brian.jensen@us.pwcglobal.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: RfbK4pv/IkfW7NUXNEOIRw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id OAA23900 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit Hi Chris, >> >> Chris, >> I would be more than happy to help and work on this. Please include me in this to. >> >> -- Alexis >> >> Alexis Bor >> Directory Works, Inc. >> www.directoryworks.com Regards -Michael Sun Microsystems Inc. Sun ONE Products - Directory Server Group >> >> >> -----Original Message----- >> From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf >> Of Chris Harding >> Sent: Thursday, August 15, 2002 12:45 PM >> To: christine.yoon@us.pwcglobal.com >> Cc: ldapext@ietf.org; 'Liben, Michael (GTS)'; 'Patrik Fältström'; >> dif-members@opengroup.org; michael.d.compton@us.pwcglobal.com; >> jamie.quick@us.pwcglobal.com; brian.jensen@us.pwcglobal.com; Alexis Bor >> Subject: [ldapext] Directory Best Practice Guide >> >> Hi, Christine - >> >> That's great! We need lots more volunteers, though. How about it, folks? >> >> At 10:40 15/08/2002 -0400, christine.yoon@us.pwcglobal.com wrote: >> >> >Chris, >> > >> >We (PwC) have many years of experience in directory/security >> >implementation for various clients including Fortune 500 companies. >> >I would like to volunteer to author the Directory Best Practice Guide. >> > >> > >> >-Christine Yoon >> >PricewaterhouseCoopers >> >(201)981-1172 - cell >> >(732)706-3559 - office >> > >> > >> > >> > >> > >> > Chris >> > Harding >> > >> > > > >> > up.org> cc: , >> >> > "'Liben, Michael \(GTS\)'" , "'Patrik >> > Sent by: Fältström'" >> > , dif-members@opengroup.org >> > ldapext-admin@ietf Subject: RE: [ldapext] >> >> > draft-ietf-ldapext-locate >> > .org >> > >> > 08/15/2002 >> > 06:20 >> > >> > AM >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >Hi, Alexis - >> > >> >A Directory Best Practices Guide is something that is clearly needed. I >> >believe that the Directory Interoperability Forum should support its >> >creation and contribute to it. The DIF could for example provide >> >publication or web page hosting facilities if needed, and could provide >> >some review effort. However, I don't believe that the DIF could on its >> own >> >provide the technical authoring and review effort needed to deliver an >> >authoritative guide. >> > >> >Because there is (as you point out) a need for rapid evolution, a set >> of >> >web pages would be far and away the best medium for such a guide. What >> we >> >need is a set of contributors, a review group, and an editorial >> committee, >> >working within the framework of an established review and publications >> >procedure. This procedure must be public and must allow rapid >> turnaround >> >from authoring to publication - I would say within 2 months at the >> outside. >> > >> >Perhaps it could be handled as a kind of Open Source project. >> > >> >I believe (the members make the decisions, I just support them) that >> the >> >DIF would be interested in co-ordinating or participating in a project >> of >> >this nature. >> > >> >At 16:00 14/08/2002 -0400, Alexis Bor wrote: >> > >I proved to myself and others (while I was at Boeing doing R&D work >> in >> > >Directory) back in 1992 that putting any meaning into a DN is not a >> good >> > >practice. We took the example of a company of 100,000 and looked at >> the >> > >different approaches for DN's - Geographic, Political, Hybrid and >> > >others. >> > > >> > >It became clear that it would be a maintenance headache and cause >> lots >> > >of stress on the overall infrastructure. It was very hard to >> convince >> > >most people for a long time until some work that Jeff Hodges did at >> > >Stanford got a lot of attention in the late 90's. >> > > >> > >A real hard piece of work to put forward is a best practices >> document. >> > >The number of opinions will typically exceed the number of people >> > >working on the document. What we learned in the mid 90's was that >> such >> > >a document evolves faster than the review cycle (part of an EMA >> effort >> > >to write a white paper on directory best practices), making it out of >> > >date before you even finish the review of it. However, with all of >> the >> > >experience that everyone is getting, it may be worth resurrecting the >> > >idea again. >> > > >> > >Perhaps an industry group can step up to the challenge - any takers? >> > > >> > >-- Alexis >> > > >> > >Alexis Bor >> > >Directory Works, Inc. >> > >www.directoryworks.com >> > > >> > > >> > >-----Original Message----- >> > >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On >> Behalf >> > >Of Liben, Michael (GTS) >> > >Sent: Tuesday, August 13, 2002 5:32 PM >> > >To: 'Patrik Fältström' >> > >Cc: ldapext@ietf.org >> > >Subject: RE: [ldapext] draft-ietf-ldapext-locate >> > > >> > >In general, divining any meaning from a distinguished name is not >> good >> > >practice (my $.02). The implications are that your app will likely >> > >break. The SHOULD NOT allows you impart meaning to your >> > >distinguished name if you so choose. A MUST NOT would be an absolute >> > >prohibition. >> > > >> > > >> > > >> > >-----Original Message----- >> > >From: Patrik Fältström [mailto:paf@cisco.com] >> > >Sent: Tuesday, August 13, 2002 5:54 AM >> > >To: micharm@microsoft.com; paulle@microsoft.com; >> levone@microsoft.com; >> > >rlmorgan@washington.edu >> > >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se >> > >Subject: [ldapext] draft-ietf-ldapext-locate >> > > >> > >Comments from the IESG: >> > >------- >> > >The document says: >> > > If there are no >> > > matching SRV records available for the converted DN the client >> > >SHOULD >> > > NOT attempt to 'walk the tree' by removing the least >> significant >> > > portion of the constructed fully qualified domain name. >> > > >> > >The meaning of "SHOULD NOT" is "don't do this unless you understand >> the >> > >implications". Well, I don't know where to look to understand the >> > >implications. >> > >Thus I think it would be useful to either make it a MUST NOT, or >> explain >> > >something about the implications of using shorter labels. >> > > >> > >Alternatively specify SHOULD NOT do this in general, but MUST NOT >> ever >> > >use this with just one label (i.e. MUST NOT look for >> _ldap._tcp.) >> > >or something similar. >> > > >> > >------- >> > >The document is unclear (see next note) on: >> > > >> > >(a) When this is to be used (only when not having the foggiest clue >> > >where a >> > >record with a specific DN is, or every time a record is to be >> accessed?) >> > > >> > >(b) How to handle the case when one have a DN which have both dc and >> > >non-dc >> > >components. Example of this is when two records stored on two >> different >> > >servers share the same dc components. IF those records per definition >> > >(of >> > >this document) have to be stored on the same server, or referrals >> have >> > >to >> > >be stored on them to point to the other, then this document has a >> scope >> > >which is larger than at first glance. I.e. part from stating how to >> > >locate >> > >a record using DNS, it also has an implicit result that DC is _the_ >> > >naming >> > >convention for the Internet. Please explain. >> > > >> > >------- >> > >This document define a conversion that is over-restrictive. >> > > >> > > The output domain name is initially empty. The DN is >> processed >> > >in >> > > right-to-left order (i.e., beginning with the first RDN in >> the >> > > sequence of RDNs). An RDN is able to be converted if it (1) >> > > consists of a single AttributeTypeAndValue; (2) the >> attribute >> > >type >> > > is "DC"; and (3) the attribute value is non-null. If it can >> be >> > > converted, the attribute value is used as a domain name >> > >component >> > > (label). The first such value becomes the rightmost (i.e., >> most >> > > significant) domain name component, and successive converted >> RDN >> > > values extend to the left. If an RDN cannot be converted, >> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > > processing stops. If the output domain name is empty when >> > > ^^^^^^^^^^^^^^^^^ >> > > processing stops, the DN cannot be converted into a domain >> name. >> > > >> > >The underscored text should be removed and replaced with text that >> > >states the non-DC RDN's are skipped over. So for example the DN: >> > > >> > > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, >> > > dc=edu >> > > >> > >Can be unambiguously translated into: >> > > >> > > lees.mit.edu >> > > >> > >Yet the underscored words make this translation invalid. With the >> > >Underscored rule in place this DN would convert to just 'mit.edu' >> > >which is not the desired result. >> > > >> > >The additional flexibility offered will permit us to convert existing >> > >PKI systems to make use of this feature without requiring all >> > >certificates to be re-issued. It will also permit us to create DIT's >> > >that can be delegated at more points rather then requiring all >> > >structure to be at the very top where the DC components are, prior to >> > >any non-DC component. >> > > >> > >For example if MIT had a DIT with a top level name of: >> > > >> > > o=MIT,c=US >> > > >> > >and a subordinate lab wanted to use this document, they could have a >> > >delegated subtree like: >> > > >> > > ou=Lab for X,o=MIT,c=US >> > > >> > >and then add a DC component below this as: >> > > >> > > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US >> > > >> > >Under my more flexible approach this would work. Without the >> > >flexibility they would be SOL until MIT redid its entire DIT to >> > >be: >> > > >> > > o=MIT,c=US,dc=mit,dc=edu >> > > >> > >and then they would have to be jointed in as: >> > > >> > > o=MIT,c=US,dc=labx,dc=mit,dc=edu >> > > >> > >Ned: I have three concerns here: >> > > >> > >(0) It isn't clear when this approach is supposed to be used. DNs are >> an >> > > integral part of *every* LDAP operation. Is it the intent >> that >> > >an >> > >LDAP >> > > client check every DN it sees for DC fields and if it finds >> them >> > >use >> > > this approach. Or is it only appropriate in specific >> situations? >> > > >> > >(1) This document specifies two things: How to translate a DN to a >> DNS >> > > name and how to use a DNS name to locate a corresponding >> LDAP >> > >server. >> > > The document seems to imply that the latter is only used >> when a >> > >DNS >> > > name is produced by the former. I wonder if this restriction >> is >> > >a >> > >good >> > > idea: Isn't the ability to use SRV records to locate more >> > >generally >> > > useful than this limited context? >> > > >> > > The answer to this may be no, but if so, the rationale for >> that >> > >answer >> > > should be part of the specification. >> > > >> > >(2) I don't see any provision for fallback to A records if SRV >> records >> > > don't exist. I can easily see this being a Bad Idea, if so, >> > >there >> > > should be an explicit prohibition of it in the document >> along >> > >with >> > > some explanation of why it is a bad idea. >> > > >> > > >> > > >> > >------- >> > >References should be split in normative and non-normative. >> > >------- >> > >I wonder about the reference to RFC1700, which has been obsoleted >> > >by RFC3232, and that RFC actuallt talks about a DB that contains >> > >the info. So How should this doc refer to that? >> > >------- >> > >Needs better abstract; doesn't even use the word "SRV". (and the rfc >> > >editor will surely complain when they get it...) >> > > >> > >Might be good to use SRV in the title as well, as opposed to just >> > >"DNS". But this I'm less concerned about, as there are two steps, and >> > >only the second step is SRV records. >> > > >> > >E.g., maybe change: >> > > >> > > Discovering LDAP Services with DNS >> > > >> > >To something like: >> > > >> > > Discovering LDAP Services with DNS SRV Resource Records >> > > >> > >However, the rfc editor probably won't like the abbreviation >> > >"SRV". Unfortunately, I don't think the acronym expands into anything >> > >useful. >> > >------- >> > >I have three concerns here: >> > > >> > >(0) It isn't clear when this approach is supposed to be used. DNs are >> an >> > > integral part of *every* LDAP operation. Is it the intent that >> an >> > >LDAP >> > > client check every DN it sees for DC fields and if it finds them >> use >> > > this approach. Or is it only appropriate in specific situations? >> > > >> > >(1) This document specifies two things: How to translate a DN to a >> DNS >> > > name and how to use a DNS name to locate a corresponding LDAP >> > >server. >> > > The document seems to imply that the latter is only used when a >> DNS >> > > name is produced by the former. I wonder if this restriction is >> a >> > >good >> > > idea: Isn't the ability to use SRV records to locate more >> generally >> > > useful than this limited context? >> > > >> > > The answer to this may be no, but if so, the rationale for that >> > >answer >> > > should be part of the specification. >> > > >> > >(2) I don't see any provision for fallback to A records if SRV >> records >> > > don't exist. I can easily see this being a Bad Idea, if so, >> there >> > > should be an explicit prohibition of it in the document along >> with >> > > some explanation of why it is a bad idea. >> > > >> > > >> > > >> > > >> > > >> > >_______________________________________________ >> > >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 >> > >> > >> >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 >> >======================================================================= >> = >> >The Open Group Conference >> >Boundaryless Information Flow: The Role of Open Source >> >Cannes, France, 14-18th October >> >http://www.opengroup.org/cannes2002 >> >======================================================================= >> = >> > >> > >> >_______________________________________________ >> >Ldapext mailing list >> >Ldapext@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ldapext >> > >> > >> > >> > >> >_________________________________________________________________ >> > The information transmitted is intended only for the person >> or >> > entity to which it is addressed and may contain confidential >> > and/or privileged material. Any review, retransmission, >> > dissemination or other use of, or taking of any action in >> reliance >> > upon, this information by persons or entities other than the >> > intended recipient is prohibited. If you received this in >> error, >> > please contact the sender and delete the material from any >> > computer. >> > >> > >> >_______________________________________________ >> >Ldapext mailing list >> >Ldapext@ietf.org >> >https://www1.ietf.org/mailman/listinfo/ldapext >> >> >> 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 >> ======================================================================== >> The Open Group Conference >> Boundaryless Information Flow: The Role of Open Source >> Cannes, France, 14-18th October >> http://www.opengroup.org/cannes2002 >> ======================================================================== >> >> >> _______________________________________________ >> 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 Aug 15 15:47:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13347 for ; Thu, 15 Aug 2002 15:47:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29876; Thu, 15 Aug 2002 15:37:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29667 for ; Thu, 15 Aug 2002 15:34:10 -0400 (EDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12596 for ; Thu, 15 Aug 2002 15:32:49 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KLBPTVCVJK0001B1@mauve.mrochek.com> for ldapext@ietf.org; Thu, 15 Aug 2002 12:34:04 -0700 (PDT) Date: Thu, 15 Aug 2002 12:32:55 -0700 (PDT) Subject: Re: [ldapext] draft-ietf-ldapext-locate In-reply-to: "Your message dated Thu, 15 Aug 2002 11:30:36 -0700" <5.1.0.14.0.20020815111448.02962c98@127.0.0.1> To: "Kurt D. Zeilenga" Cc: ned.freed@mrochek.com, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , micharm@microsoft.com, paulle@microsoft.com, levone@microsoft.com, rlmorgan@washington.edu, ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se Message-id: <01KLBS4HAGSE0001B1@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <24876124.1029218035@localhost> <5.1.0.14.0.20020813201324.0674c688@127.0.0.1> <01KLBN5PE4D60001B1@mauve.mrochek.com> <5.1.0.14.0.20020815111448.02962c98@127.0.0.1> Content-Transfer-Encoding: 7BIT Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7BIT > At 09:57 AM 2002-08-15, ned.freed@mrochek.com wrote: > >I'm going to take the liberty of responding directly here. > > > >> >(0) It isn't clear when this approach is supposed to be used. DNs are an > >> >integral part of *every* LDAP operation. Is it the intent that an > >> >LDAP client check every DN it sees for DC fields and if it finds them use > >> >this approach. Or is it only appropriate in specific situations? > > > >> It is intended to be a general mechanism for locating LDAP servers > >> having knowledge of directory objects associated with a DN in > >> absence of location information. This DN may have been provided > >> to the application via LDAP or other means. If the DN was provided > >> with location information, such as a LDAP URL with host part, > >> that information should be used. Howeer, where the DN is provided > >> without any location information, this mechanism provides a means, > >> for a subset of DNs (those using RFC 2247 naming), for the > >> application to locate servers with knowledge of the DN. > > > >> This application may be an LDAP client or server. OpenLDAP's server, > >> for example, can use this mechanism to generate referrals to clients > >> requesting DN which it otherwise has no knowledge of. > > > >This is precisely the sort of thing I'm afraid of. OpenLDAP does this but I > >doubt SunOne Directory Server (to pick a specific example) does. And given this > >document doesn't spell out when this is supposed to be used you cannot claim > >that the issue is Sun's failure to implement this standard. > OpenLDAP supports a particular experimental service, described > in RFC 3088, which uses this location mechanism. > What I think you asking us to clarify is when should this mechanism > be implemented/used. Exactly. > My answer to this is, the mechanism should be > implemented/used as detailed in the technical specification for the application (or protocol) requiring its use. That's a very reasonable answer. > That is, I agree that implementations should not use this mechanism > unless they implement a particular technical specification which > prescribes use of the mechanism. This should be clarified. Good. The addresses the issue as far as I'm concerned. Ned _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 17:22:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16584 for ; Thu, 15 Aug 2002 17:22:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07240; Thu, 15 Aug 2002 17:11:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07173 for ; Thu, 15 Aug 2002 17:11:03 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16095 for ; Thu, 15 Aug 2002 17:09:43 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 15 Aug 2002 14:10:32 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Aug 2002 14:10:32 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 15 Aug 2002 14:10:32 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 15 Aug 2002 14:10:30 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 15 Aug 2002 14:10:29 -0700 Content-Class: urn:content-classes:message Subject: RE: [ldapext] draft-ietf-ldapext-locate MIME-Version: 1.0 Date: Thu, 15 Aug 2002 14:10:29 -0700 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0000_01C24465.88292A20" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD04929817@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: [ldapext] draft-ietf-ldapext-locate thread-index: AcJEkrppzdty4TP7QiGVZRue1MHMvwAA8DNQ From: "Paul Leach" To: , "Kurt D. Zeilenga" Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Michael Armijo" , "Levon Esibov" , , , X-OriginalArrivalTime: 15 Aug 2002 21:10:29.0730 (UTC) FILETIME=[2F35B420:01C244A0] Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C24465.88292A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]=20 > Sent: Thursday, August 15, 2002 12:33 > To: Kurt D. Zeilenga > Cc: ned.freed@mrochek.com; Patrik F=E4ltstr=F6m; Michael Armijo;=20 > Paul Leach; Levon Esibov; rlmorgan@washington.edu;=20 > ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > Subject: Re: [ldapext] draft-ietf-ldapext-locate >=20 >=20 > > My answer to this is, the mechanism should be implemented/used as=20 > > detailed in the technical specification for the application (or=20 > > protocol) requiring its use. >=20 > That's a very reasonable answer. >=20 > > That is, I agree that implementations should not use this mechanism=20 > > unless they implement a particular technical specification which=20 > > prescribes use of the mechanism. This should be clarified. I don't agree with this, because there are existing specs that don't prescribe its use, where is was in fact the intent that this mechanism be allowed to be used. I propose that we say this about when it MAY be used: 1. By clients wishing to locate an authoritative LDAP server for DNs that contain DCs on the right side of a DN, when they have not been configured with either implementation specific information to the contrary, or when they are not using some other (future) standard for locating said LDAP server. 2. By servers wishing to generate referrals to Naming Contexts for which it doesn't have any other way to return location information. In addition, standards for other scenarios may require or allow its its use in those scenarios. Paul ------=_NextPart_000_0000_01C24465.88292A20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIipTCCA0Aw ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIFdzCCBTagAwIBAgIKbR8tRgADAAAB kjAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X DTAyMDEyOTAwMTYwMVoXDTAyMDkyMDIxMzMyOFowYjETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcG CgmSJomT8ixkARkWCW1pY3Jvc29mdDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRkwFwYDVQQDExBO VERFViBJc3N1ZTY0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCe7uH1+lUYtdzFSBiM LOSsVfDwSUU8V13PLZU4qYeC91SoFyZ2FLFxbMiqUpX0dmt5/WrJ4jerwBQlmheVkZ5i5E1zHyWh Im3xaScMBCJ4dj9Ax4sHIPCKiYPDfneDJbKbriZKqTwTvuoV+4H9AfcE88HQ+l52ecpW3I5A0DFk gQIDAQABo4IDjTCCA4kwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQULLYra2BeKCVgmpPpUKrc bxP2E8AwCwYDVR0PBAQDAgGGMBIGCSsGAQQBgjcVAQQFAgMFAAYwIwYJKwYBBAGCNxUCBBYEFFn6 2/e2PIGLWb3JaMwy6YMDvfPQMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaA FM/Fuhf/LccQgPW5DplKb/ScK/sZMIIBXAYDVR0fBIIBUzCCAU8wggFLoIIBR6CCAUOGgd9sZGFw Oi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoMSksQ049 d2hpY2EyLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hl9odHRwOi8v d2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMEludGVybWVkaWF0 ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDEpLmNybDCCAXMGCCsGAQUFBwEBBIIBZTCCAWEwgdUG CCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRl JTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0 ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgYYGCCsGAQUFBzAChnpo dHRwOi8vd2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYTIubnRkZXYu bWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2Ey KDMpLmNydDAJBgcqhkjOOAQDAzAAMC0CFQCTJcIxIcR6X/F39s4eRbklukPqkAIUdbQr5+2UZc7a 841oHuICRpJxdbswggY/MIIF/6ADAgECAgp1n/n0AAIAAAFWMAkGByqGSM44BAMwYTELMAkGA1UE BhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVW IEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcNMDEwOTE0MDMxNjUwWhcNMDIwOTIw MjEzMzI4WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRl djEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6 kcw3SUnD1p7YhzbJkEgIKp4/YfpF7gHVGeT4oRO0XRLXmOrt5rmf/7PjcNr0KqO6c0lotPutfij0 0dQ3t4/loqVntpE/4ShPTAHnU4+yNkq4Vam1t0vs8RUcC45Ss46PJnQhNHjfa+pwn8vcCi5PK4K4 3v/WTD20wxGXl6vORQIDAQABo4IEbTCCBGkwEAYJKwYBBAGCNxUBBAMCAQEwIwYJKwYBBAGCNxUC BBYEFF0wmXse4uyanN+uhOOORXrSKJ9VMB0GA1UdDgQWBBTJRFZKkBN8qfMzBmve0Jm758jO6TAZ BgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAf BgNVHSMEGDAWgBTPxboX/y3HEID1uQ6ZSm/0nCv7GTCCAj4GA1UdHwSCAjUwggIxMIICLaCCAimg ggIlhoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hp Y2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIZfaHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJ bnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKS5jcmyGgd9sZGFwOi8vL0NOPU5U REVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoMSksQ049d2hpY2EyLENO PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBcwYIKwYBBQUHAQEEggFl MIIBYTCB1QYIKwYBBQUHMAKGgchsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhgYIKwYB BQUHMAKGemh0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNh Mi5udGRldi5taWNyb3NvZnQuY29tX05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUl MjBXaGljYTIoMikuY3J0MAkGByqGSM44BAMDLwAwLAIUUx77g13BMwHgk+1QbyieLyToMN4CFHnb gTPU/Y/C05rO+kV3uJVgyD1oMIIGYjCCBcugAwIBAgIKKB26agABABleeTANBgkqhkiG9w0BAQUF ADBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYG A1UEAxMPTlRERVYgSVNTVUUzIENBMB4XDTAyMDcwODA4MjMwMloXDTAyMDkwNjA4MjMwMlowgccx EzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJ k/IsZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQx ETAPBgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxw YXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDc Ifu483kq/hLla0LcvAFNw84N4YiXBNCSTmx3/RB1oOsXsH776cr43a0fP7LgQVMliao0OXU97xwZ 4NR+fUtqTk/FGNhx/gvlz+5D6BerfBMES7p5nnC/djXHDCKOdfbf9gPtWxY1DjBDVEtw3C8aSGAc TnQY6yril8FzBnWaNQIDAQABo4IDzjCCA8owCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+Bgkr BgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXEC AQIwEwYDVR0lBAwwCgYIKwYBBQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNV HREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxs ZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYDVR0OBBYEFHL72L3FksyRMphJsUK0PoYmyIQ9MB8G A1UdIwQYMBaAFMlEVkqQE3yp8zMGa97QmbvnyM7pMIIBJgYDVR0fBIIBHTCCARkwggEVoIIBEaCC AQ2GgcRsZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049V0hJQ0EzLENOPUNEUCxDTj1Q dWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50 ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29i amVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hkRodHRwOi8vd2hpY2EzLm50ZGV2Lm1pY3Jv c29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElTU1VFMyUyMENBLmNybDCCAUIGCCsGAQUFBwEB BIIBNDCCATAwgb0GCCsGAQUFBzAChoGwbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENO PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVj dENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwbgYIKwYBBQUHMAKGYmh0dHA6Ly93aGljYTMu bnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL1dISUNBMy5udGRldi5taWNyb3NvZnQuY29t X05UREVWJTIwSVNTVUUzJTIwQ0EoMSkuY3J0MA0GCSqGSIb3DQEBBQUAA4GBAFf+QZur5gxtJiK7 QC75LGeLcLys77vN3Tr3ailS0rD+oXAY9oXYGFcAHaFUygfOAiQxDNinhuABsdyKfCCwHUUMkr7p jt/O9cEgnhGsM2okZGi6u9nrHDaN7d+EPM9hzreYIZz5lxOJ2aUFl3HuiszOUmV22rh1ClAnkKyn 1ZptMIIGjjCCBfegAwIBAgIKQPyrngAGABV2OjANBgkqhkiG9w0BAQUFADBiMRMwEQYKCZImiZPy LGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0MRUwEwYKCZImiZPyLGQBGRYFbnRk ZXYxGTAXBgNVBAMTEE5UREVWIElzc3VlNjQgQ0EwHhcNMDIwNzMxMDAwMjQyWhcNMDIwOTIwMjEz MzI4WjCBmjETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEV MBMGCgmSJomT8ixkARkWBW50ZGV2MRAwDgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5 TWFuYWdlZDERMA8GA1UECxMITG93VENPLUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAOU71leNXD/9bfcgs+tzFM6I8heI5sujO299Z/q++lwwFY0gR0ju C/72sc8MZ9TYQhxReqRTrwaDAQxl+7rjLP244jXFnzo+obpSDiIY9APSbJOMgJinbdBWRkGMBqy8 4qH3YOg9pTkkpITSFazLwXvr/IGqZLoW3IFq/HHR7OGdAgMBAAGjggQQMIIEDDALBgNVHQ8EBAMC B4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe 5oBUAgFxAgEDMBMGA1UdJQQMMAoGCCsGAQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDR iU6E15zDB4amhvscj9O/phUBgxEwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREE TDBKoCoGCisGAQQBgjcUAgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3 aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYDVR0OBBYEFCE8CMC/VepkzftXBD06OeKJdxp2MB8GA1Ud IwQYMBaAFCy2K2tgXiglYJqT6VCq3G8T9hPAMIIBewYDVR0fBIIBcjCCAW4wggFqoIIBZqCCAWKG gclsZGFwOi8vL0NOPU5UREVWJTIwSXNzdWU2NCUyMENBKDUpLENOPXdoaWNhNjQsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGSWh0dHA6Ly93aGljYTY0Lm50ZGV2Lm1p Y3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElzc3VlNjQlMjBDQSg1KS5jcmyGSWh0dHA6 Ly93aGljYTY0Lm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElzc3VlNjQl MjBDQSg1KS5jcmwwggFGBggrBgEFBQcBAQSCATgwggE0MIG+BggrBgEFBQcwAoaBsWxkYXA6Ly8v Q049TlRERVYlMjBJc3N1ZTY0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBx BggrBgEFBQcwAoZlaHR0cDovL3doaWNhNjQubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L3doaWNhNjQubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMElzc3VlNjQlMjBDQSg2KS5jcnQw DQYJKoZIhvcNAQEFBQADgYEAmxk1iyBSfJYeDZzKZYvd0fUJtCgb3XHlXXk5FSYIF9MhQIiNEqXr RCKqbZ04NAQ9GWNLd18TTKlCtyX58ExkQem0gopXqVz2vosiduGg3ClcNxft1VCuAsAeO3Ut+kCy roKF2c2Z1DXV2Xef0XTUopvr/GxnvETceAcFjhRr5xswgganMIIGEKADAgECAgoUXpdDAAAAAAAo MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNV BAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAxMTEwMTIwNTcxMVoXDTAy MDkyMDIxMzMyOFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwggG2 MIIBKwYHKoZIzjgEATCCAR4CgYEA+C8tsWT9/wRFSSpuX/EWDdw9JXBNItcNpQijM8iHGhCAvOLM MtYKSmNGeEfEQM4o/IUZMPHIl0+mreZoAx6O5Sd2j5hDrMcJ8ZDfIYWbOdITwbRhlbOgdYo1RGYh nU85Uy53iBXOjJOxxDL97D+0tSr1iQ5bPa60SWBZckwd+QECFQC6SuANG+2mus3kNWZDzwvYkXAo 3wKBgGe4TMedVC32vpClPeBaNRx93A3a0punW+cPKKsTiZI/fqmtt6fZJd3D3YqBrIQ0IxeCzvEf r0kTzP1BuYq+y5JBOror681wxhxdeguP2aDAHWR1O1BrbqB4SPdhpom5s15G4jFjcrw92IjNeD6v wWPURzVQvFdrblDXvmyde5ULA4GEAAKBgAZWBKiqZbwqp6gdR1nskDn0UOVCS7UkzRipC+jzwHG8 XVrDdSYg2piw8b5k12JvJFkrkZM0qqxj4rKTSAyzgJl0WO/bV+CFg/SKbFYRj/FOgu8nDc2aTTOm xLgUIAFVX30gWvfULKu4Eqz5JBQPBHopE6JcSjOXTjNNWdgRnaX5o4IDYTCCA10wEgYJKwYBBAGC NxUBBAUCAwEAAzAjBgkrBgEEAYI3FQIEFgQUGMUaNFgsr5GgGsVlgyKT+sb/FRUwHQYDVR0OBBYE FM/Fuhf/LccQgPW5DplKb/ScK/sZMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQE AwIBxjAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFHfJdGksOf44ZfSHBVgIzr26l9oQMIIB OgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgc5sZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290 JTIwQ0EsQ049d2hpY2FzYXJvb3RjYSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29t P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZOaHR0cDovL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5y b2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMIIBUwYIKwYBBQUHAQEEggFFMIIBQTCBwAYI KwYBBQUHMAKGgbNsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1 YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRk ZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2Vy dGlmaWNhdGlvbkF1dGhvcml0eTB8BggrBgEFBQcwAoZwaHR0cDovL3doaWNhc2Fyb290Y2EubnRk ZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0 LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBLmNydDAUBgNVHSABAf8ECjAIMAYGBFUdIAAwDQYJ KoZIhvcNAQEFBQADgYEAMWIlFJq094wxahPtYNIApwcYHwt5jJCEbVQN7EvgGQgeUHVcBzCJ+VW3 M/lB86vhikv30TNhE3dfcueigGjRSOTUiz7rr2SGLs8NEArFY29aNCQ0/GetHm66Cww7ZVzgZ5mr FY5nOTw8lSq5RrU8gi4livaGZDTVFeDif8a7op8xggK2MIICsgIBATBwMGIxEzARBgoJkiaJk/Is ZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJk/IsZAEZFgVudGRl djEZMBcGA1UEAxMQTlRERVYgSXNzdWU2NCBDQQIKQPyrngAGABV2OjAJBgUrDgMCGgUAoIIBnDAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA4MTUyMTEwMzhaMCMG CSqGSIb3DQEJBDEWBBRLiQiXVARPmuHSIhvqcrQHPMHQDzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgkrBgEEAYI3EAQxWzBZMEsxCzAJBgNVBAYTAlVT MRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NV RTMgQ0ECCigdumoAAQAZXnkwagYLKoZIhvcNAQkQAgsxW6BZMEsxCzAJBgNVBAYTAlVTMRIwEAYD VQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EC CigdumoAAQAZXnkwDQYJKoZIhvcNAQEBBQAEgYCDsbn4zhuEO4HRRwPBh5nIQnklq7nQVhUn45Zv 93Yf065dfz3y0fzvuJMMXkKomjS61RX9NeAMmXKFDr+Z8ZPMYLNFSi/oF+NRyrVBtpc3POHZLexm rZfD/gAs4NKwE6EwRxvsIzLU8oKn5mdGoW+IfDxa+egPOVP91J9xoa2GBwAAAAAAAA== ------=_NextPart_000_0000_01C24465.88292A20-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 17:38:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17099 for ; Thu, 15 Aug 2002 17:38:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08542; Thu, 15 Aug 2002 17:24:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08513 for ; Thu, 15 Aug 2002 17:24:50 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16613 for ; Thu, 15 Aug 2002 17:23:30 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7FLN4iT006776; Thu, 15 Aug 2002 23:23:23 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 15 Aug 2002 22:24:17 +0100 Received: from [192.168.1.9] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 15 Aug 2002 23:24:15 +0200 Date: Thu, 15 Aug 2002 22:52:04 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Liben, Michael (GTS)" , "'christine.yoon@us.pwcglobal.com'" , ereed@novell.com, alexis.bor@directoryworks.com, "Liben, Michael (GTS)" cc: ldapext@ietf.org Subject: RE: [ldapext] draft-ietf-ldapext-locate Message-ID: <28148503.1029451924@localhost> In-Reply-To: <9B5CBD4986A9D511BE2100065B045DDF0238BD41@ehope21.hew.us.ml.com> References: <9B5CBD4986A9D511BE2100065B045DDF0238BD41@ehope21.hew.us.ml.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 15 Aug 2002 21:24:16.0036 (UTC) FILETIME=[1BB9FE40:01C244A2] Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7bit --On 2002-08-14 22.51 -0400 "Liben, Michael (GTS)" wrote: > It should not be up to the client application to divine any relevant > information from the distinguished name of an object. Then, what does the ldapext-locate draft say? paf _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 18:10:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17968 for ; Thu, 15 Aug 2002 18:10:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12140; Thu, 15 Aug 2002 18:09:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12112 for ; Thu, 15 Aug 2002 18:09:09 -0400 (EDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17854 for ; Thu, 15 Aug 2002 18:07:48 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g7FM95kC024779; Thu, 15 Aug 2002 22:09:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020815144528.0293c080@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 Aug 2002 15:08:48 -0700 To: "Paul Leach" From: "Kurt D. Zeilenga" Subject: RE: [ldapext] draft-ietf-ldapext-locate Cc: , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Michael Armijo" , "Levon Esibov" , , , In-Reply-To: <4AEE3169443CDD4796CA8A00B02191CD04929817@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA12113 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit At 02:10 PM 2002-08-15, Paul Leach wrote: >> -----Original Message----- >> From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] >> Sent: Thursday, August 15, 2002 12:33 >> To: Kurt D. Zeilenga >> Cc: ned.freed@mrochek.com; Patrik Fältström; Michael Armijo; >> Paul Leach; Levon Esibov; rlmorgan@washington.edu; >> ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se >> Subject: Re: [ldapext] draft-ietf-ldapext-locate >> > > > >> >> > My answer to this is, the mechanism should be implemented/used as >> > detailed in the technical specification for the application (or >> > protocol) requiring its use. >> >> That's a very reasonable answer. >> >> > That is, I agree that implementations should not use this mechanism >> > unless they implement a particular technical specification which >> > prescribes use of the mechanism. This should be clarified. > >I don't agree with this, because there are existing specs that don't >prescribe its use, where is was in fact the intent that this mechanism >be allowed to be used. I have a problem with allowing use of locate whenever or whereever an implementation might choose to use it. For example, it would be not be appropriate for a server implementing draft-zeilenga-ldap-namedref (approved for publication) to replace an empty hostpart of a LDAP URLs of a referral object based on DNS SRV information when generating referrals and search references (writing the hostpart is not allowed by namedref). However, if the object was a dnsref instead, then the server should rewrite the empty hostpart because that's exactly what the technical specification (draft-zeilenga-ldap-dnsref, presently expired) prescribes. >I propose that we say this about when it MAY be used: > >1. By clients wishing to locate an authoritative LDAP server for DNs >that contain DCs on the right side of a DN, when they have not been >configured with either implementation specific information to the >contrary, or when they are not using some other (future) standard for >locating said LDAP server. I have problem with locate providing a specification of this application of the mechanism. For example, this specification would state whether it was appropriate or not for a client to ignore explicit location information provided with a DN... or whether the client which obtained a DN from a server should ask that server for location information before using the locate mechanism. >2. By servers wishing to generate referrals to Naming Contexts for which >it doesn't have any other way to return location information. Should such a server publish "" as a value of namingContexts or not? >In addition, standards for other scenarios may require or allow its its >use in those scenarios. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 18:33:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18584 for ; Thu, 15 Aug 2002 18:33:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13374; Thu, 15 Aug 2002 18:28:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13342 for ; Thu, 15 Aug 2002 18:28:35 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18342 for ; Thu, 15 Aug 2002 18:27:15 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 15 Aug 2002 15:28:05 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Aug 2002 15:28:05 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 15 Aug 2002 15:28:05 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 15 Aug 2002 15:28:05 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 15 Aug 2002 15:28:04 -0700 Content-Class: urn:content-classes:message Subject: RE: [ldapext] draft-ietf-ldapext-locate MIME-Version: 1.0 Date: Thu, 15 Aug 2002 15:28:04 -0700 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0036_01C24470.59124270" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD04929820@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: [ldapext] draft-ietf-ldapext-locate thread-index: AcJEqGea3fZoAB1cSn2h+vy3HZ0lLQAAQkTA From: "Paul Leach" To: "Kurt D. Zeilenga" Cc: , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Michael Armijo" , "Levon Esibov" , , , X-OriginalArrivalTime: 15 Aug 2002 22:28:04.0741 (UTC) FILETIME=[05D00350:01C244AB] Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C24470.59124270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]=20 > Sent: Thursday, August 15, 2002 15:09 > To: Paul Leach > Cc: ned.freed@mrochek.com; Patrik F=E4ltstr=F6m; Michael Armijo;=20 > Levon Esibov; rlmorgan@washington.edu; ldapext@ietf.org;=20 > ietf-ldap@paf.se > Subject: RE: [ldapext] draft-ietf-ldapext-locate >=20 >=20 > At 02:10 PM 2002-08-15, Paul Leach wrote: >=20 >=20 > >> -----Original Message----- > >> From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] > >> Sent: Thursday, August 15, 2002 12:33 > >> To: Kurt D. Zeilenga > >> Cc: ned.freed@mrochek.com; Patrik F=E4ltstr=F6m; Michael Armijo;=20 > >> Paul Leach; Levon Esibov; rlmorgan@washington.edu;=20 > >> ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se > >> Subject: Re: [ldapext] draft-ietf-ldapext-locate > >>=20 > > > > > > > >>=20 > >> > My answer to this is, the mechanism should be=20 > implemented/used as > >> > detailed in the technical specification for the application (or=20 > >> > protocol) requiring its use. > >>=20 > >> That's a very reasonable answer. > >>=20 > >> > That is, I agree that implementations should not use=20 > this mechanism > >> > unless they implement a particular technical specification which=20 > >> > prescribes use of the mechanism. This should be clarified. > > > >I don't agree with this, because there are existing specs that don't=20 > >prescribe its use, where is was in fact the intent that this=20 > mechanism=20 > >be allowed to be used. >=20 > I have a problem with allowing use of locate whenever or=20 > whereever an implementation might choose to use it. For=20 > example, it would be not be appropriate for a server=20 > implementing draft-zeilenga-ldap-namedref (approved for=20 > publication) to replace an empty hostpart of a LDAP URLs of a=20 > referral object based on DNS SRV information when generating=20 > referrals and search references (writing the hostpart is not=20 > allowed by namedref). However, if the object was a dnsref=20 > instead, then the server should rewrite the empty hostpart=20 > because that's exactly what the technical specification=20 > (draft-zeilenga-ldap-dnsref, presently expired) prescribes. You're jumping the gun. I'm not saying that it should be able to be used anywhere an implementation wants to. I'm saying that for the two purposes listed below , implementations may use it. For other purposes and protocols (that don't yet exist), I'm agreeing with you -- the spec for those protocols should say that they MUST or MAY or SHOULD use this mechanism, as appropriate for the protocol or purpose. >=20 > >I propose that we say this about when it MAY be used: > > > >1. By clients wishing to locate an authoritative LDAP server for DNs=20 > >that contain DCs on the right side of a DN, when they have not been=20 > >configured with either implementation specific information to the=20 > >contrary, or when they are not using some other (future)=20 > standard for=20 > >locating said LDAP server. >=20 > I have problem with locate providing a specification of this > application of the mechanism. For example, this specification > would state whether it was appropriate or not for a client to=20 I just don't understand the preceding sentence. Gramatically, it is in the subjunctive case, or something like that. Are you trying to say what the spec should say, or what it will say if my proposal is accepted and that you don't like? > ignore explicit location information provided with a DN... or=20 > whether the client which obtained a DN from a server should=20 > ask that server for location information before using the=20 > locate mechanism. That's what I meant by "using some other future standard". If some standard says "thou shalt not ignore this explicit location information", then this item doesn't apply. AFAIK, there is currently no other standardized way to find LDAP servers. All existing mechanisms are therefore implementation specific. So, if a caller passes in a DNS name and a DN to an LDAP API that says "do a lookup on the LDAP server with this DNS name for this DN", do you want me to declare that legal or illegal? >=20 > >2. By servers wishing to generate referrals to Naming Contexts for=20 > >which it doesn't have any other way to return location information. >=20 > Should such a server publish "" as a value of namingContexts > or not? >=20 > >In addition, standards for other scenarios may require or=20 > allow its its=20 > >use in those scenarios. >=20 >=20 >=20 ------=_NextPart_000_0036_01C24470.59124270 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIipTCCA0Aw ggKpoAMCAQICECElZvdedYS4R497WbSp4hIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDAwOTIwMjEyNDQ1WhcNMDIwOTIwMjEzMzI4WjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxym3bBtJ93ep9YM9eFtrJSmFA8NG6OtxTKRL LyorXMYNUzLsdozvGWdSZwlzbvATakzrzriuqq7QgaBzJvS0Oq8yAzthqf0jBQysGvTH1LHieo3b mCFFOOUtGvfdJGbEMvTb8cT0yxAgPJ7Or0WZta77f/ARUNWWv6g7TNUUhe0CAwEAAaOCASEwggEd MBMGCSsGAQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBR3yXRpLDn+OGX0hwVYCM69upfaEDCBtgYDVR0fBIGuMIGrMIGooIGloIGihk5odHRwOi8v d2hpY2FzYXJvb3RjYS5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy MFJvb3QlMjBDQS5jcmyGUGZpbGU6Ly9cXHdoaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNv bVxDZXJ0RW5yb2xsXE5UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEA MA0GCSqGSIb3DQEBBQUAA4GBAAj54W8kzais9v83BJCkQFSgVejj3junPZCxUeCnGzzDmrxUuOPc ofoYlSwZ/11uLoVVc5qCkEZknWSmwRRViiizyf3dRuYsR9seP2ixJUtKHHwbqHeoQpUpZpOt+czy LOKJpPc9ihx917XumDCrNTF0Urn8pouG9wYyB3wUnmSdMIIFdzCCBTagAwIBAgIKbR8tRgADAAAB kjAJBgcqhkjOOAQDMGExCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsT BU50ZGV2MS4wLAYDVQQDEyVOVERFViBJbnRlcm1lZGlhdGUgU3Vib3JkaW5hdGUgV2hpY2EyMB4X DTAyMDEyOTAwMTYwMVoXDTAyMDkyMDIxMzMyOFowYjETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcG CgmSJomT8ixkARkWCW1pY3Jvc29mdDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRkwFwYDVQQDExBO VERFViBJc3N1ZTY0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCe7uH1+lUYtdzFSBiM LOSsVfDwSUU8V13PLZU4qYeC91SoFyZ2FLFxbMiqUpX0dmt5/WrJ4jerwBQlmheVkZ5i5E1zHyWh Im3xaScMBCJ4dj9Ax4sHIPCKiYPDfneDJbKbriZKqTwTvuoV+4H9AfcE88HQ+l52ecpW3I5A0DFk gQIDAQABo4IDjTCCA4kwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQULLYra2BeKCVgmpPpUKrc bxP2E8AwCwYDVR0PBAQDAgGGMBIGCSsGAQQBgjcVAQQFAgMFAAYwIwYJKwYBBAGCNxUCBBYEFFn6 2/e2PIGLWb3JaMwy6YMDvfPQMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaA FM/Fuhf/LccQgPW5DplKb/ScK/sZMIIBXAYDVR0fBIIBUzCCAU8wggFLoIIBR6CCAUOGgd9sZGFw Oi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoMSksQ049 d2hpY2EyLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D b25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hl9odHRwOi8v d2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMEludGVybWVkaWF0 ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDEpLmNybDCCAXMGCCsGAQUFBwEBBIIBZTCCAWEwgdUG CCsGAQUFBzAChoHIbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRl JTIwV2hpY2EyLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0 ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgYYGCCsGAQUFBzAChnpo dHRwOi8vd2hpY2EyLm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYTIubnRkZXYu bWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2Ey KDMpLmNydDAJBgcqhkjOOAQDAzAAMC0CFQCTJcIxIcR6X/F39s4eRbklukPqkAIUdbQr5+2UZc7a 841oHuICRpJxdbswggY/MIIF/6ADAgECAgp1n/n0AAIAAAFWMAkGByqGSM44BAMwYTELMAkGA1UE BhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVW IEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcNMDEwOTE0MDMxNjUwWhcNMDIwOTIw MjEzMzI4WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRl djEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6 kcw3SUnD1p7YhzbJkEgIKp4/YfpF7gHVGeT4oRO0XRLXmOrt5rmf/7PjcNr0KqO6c0lotPutfij0 0dQ3t4/loqVntpE/4ShPTAHnU4+yNkq4Vam1t0vs8RUcC45Ss46PJnQhNHjfa+pwn8vcCi5PK4K4 3v/WTD20wxGXl6vORQIDAQABo4IEbTCCBGkwEAYJKwYBBAGCNxUBBAMCAQEwIwYJKwYBBAGCNxUC BBYEFF0wmXse4uyanN+uhOOORXrSKJ9VMB0GA1UdDgQWBBTJRFZKkBN8qfMzBmve0Jm758jO6TAZ BgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAf BgNVHSMEGDAWgBTPxboX/y3HEID1uQ6ZSm/0nCv7GTCCAj4GA1UdHwSCAjUwggIxMIICLaCCAimg ggIlhoHfbGRhcDovLy9DTj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hp Y2EyKDEpLENOPXdoaWNhMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRp ZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu dIZfaHR0cDovL3doaWNhMi5udGRldi5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBJ bnRlcm1lZGlhdGUlMjBTdWJvcmRpbmF0ZSUyMFdoaWNhMigxKS5jcmyGgd9sZGFwOi8vL0NOPU5U REVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoMSksQ049d2hpY2EyLENO PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBcwYIKwYBBQUHAQEEggFl MIIBYTCB1QYIKwYBBQUHMAKGgchsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNl cnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBhgYIKwYB BQUHMAKGemh0dHA6Ly93aGljYTIubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNh Mi5udGRldi5taWNyb3NvZnQuY29tX05UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUl MjBXaGljYTIoMikuY3J0MAkGByqGSM44BAMDLwAwLAIUUx77g13BMwHgk+1QbyieLyToMN4CFHnb gTPU/Y/C05rO+kV3uJVgyD1oMIIGYjCCBcugAwIBAgIKKB26agABABleeTANBgkqhkiG9w0BAQUF ADBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYG A1UEAxMPTlRERVYgSVNTVUUzIENBMB4XDTAyMDcwODA4MjMwMloXDTAyMDkwNjA4MjMwMlowgccx EzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJ k/IsZAEZFgVudGRldjEQMA4GA1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQx ETAPBgNVBAsTCExvd1RDTy1FMRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxw YXVsbGVAd2luZG93cy5taWNyb3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDc Ifu483kq/hLla0LcvAFNw84N4YiXBNCSTmx3/RB1oOsXsH776cr43a0fP7LgQVMliao0OXU97xwZ 4NR+fUtqTk/FGNhx/gvlz+5D6BerfBMES7p5nnC/djXHDCKOdfbf9gPtWxY1DjBDVEtw3C8aSGAc TnQY6yril8FzBnWaNQIDAQABo4IDzjCCA8owCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+Bgkr BgEEAYI3FQcEMTAvBicrBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXEC AQIwEwYDVR0lBAwwCgYIKwYBBQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNV HREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxs ZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYDVR0OBBYEFHL72L3FksyRMphJsUK0PoYmyIQ9MB8G A1UdIwQYMBaAFMlEVkqQE3yp8zMGa97QmbvnyM7pMIIBJgYDVR0fBIIBHTCCARkwggEVoIIBEaCC AQ2GgcRsZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049V0hJQ0EzLENOPUNEUCxDTj1Q dWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50 ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29i amVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hkRodHRwOi8vd2hpY2EzLm50ZGV2Lm1pY3Jv c29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElTU1VFMyUyMENBLmNybDCCAUIGCCsGAQUFBwEB BIIBNDCCATAwgb0GCCsGAQUFBzAChoGwbGRhcDovLy9DTj1OVERFViUyMElTU1VFMyUyMENBLENO PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPW50ZGV2LERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVj dENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwbgYIKwYBBQUHMAKGYmh0dHA6Ly93aGljYTMu bnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL1dISUNBMy5udGRldi5taWNyb3NvZnQuY29t X05UREVWJTIwSVNTVUUzJTIwQ0EoMSkuY3J0MA0GCSqGSIb3DQEBBQUAA4GBAFf+QZur5gxtJiK7 QC75LGeLcLys77vN3Tr3ailS0rD+oXAY9oXYGFcAHaFUygfOAiQxDNinhuABsdyKfCCwHUUMkr7p jt/O9cEgnhGsM2okZGi6u9nrHDaN7d+EPM9hzreYIZz5lxOJ2aUFl3HuiszOUmV22rh1ClAnkKyn 1ZptMIIGjjCCBfegAwIBAgIKQPyrngAGABV2OjANBgkqhkiG9w0BAQUFADBiMRMwEQYKCZImiZPy LGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJbWljcm9zb2Z0MRUwEwYKCZImiZPyLGQBGRYFbnRk ZXYxGTAXBgNVBAMTEE5UREVWIElzc3VlNjQgQ0EwHhcNMDIwNzMxMDAwMjQyWhcNMDIwOTIwMjEz MzI4WjCBmjETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEV MBMGCgmSJomT8ixkARkWBW50ZGV2MRAwDgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5 TWFuYWdlZDERMA8GA1UECxMITG93VENPLUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAOU71leNXD/9bfcgs+tzFM6I8heI5sujO299Z/q++lwwFY0gR0ju C/72sc8MZ9TYQhxReqRTrwaDAQxl+7rjLP244jXFnzo+obpSDiIY9APSbJOMgJinbdBWRkGMBqy8 4qH3YOg9pTkkpITSFazLwXvr/IGqZLoW3IFq/HHR7OGdAgMBAAGjggQQMIIEDDALBgNVHQ8EBAMC B4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe 5oBUAgFxAgEDMBMGA1UdJQQMMAoGCCsGAQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDR iU6E15zDB4amhvscj9O/phUBgxEwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREE TDBKoCoGCisGAQQBgjcUAgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3 aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYDVR0OBBYEFCE8CMC/VepkzftXBD06OeKJdxp2MB8GA1Ud IwQYMBaAFCy2K2tgXiglYJqT6VCq3G8T9hPAMIIBewYDVR0fBIIBcjCCAW4wggFqoIIBZqCCAWKG gclsZGFwOi8vL0NOPU5UREVWJTIwSXNzdWU2NCUyMENBKDUpLENOPXdoaWNhNjQsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 bnRkZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/ b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGSWh0dHA6Ly93aGljYTY0Lm50ZGV2Lm1p Y3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElzc3VlNjQlMjBDQSg1KS5jcmyGSWh0dHA6 Ly93aGljYTY0Lm50ZGV2Lm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElzc3VlNjQl MjBDQSg1KS5jcmwwggFGBggrBgEFBQcBAQSCATgwggE0MIG+BggrBgEFBQcwAoaBsWxkYXA6Ly8v Q049TlRERVYlMjBJc3N1ZTY0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9bWljcm9zb2Z0LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBx BggrBgEFBQcwAoZlaHR0cDovL3doaWNhNjQubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L3doaWNhNjQubnRkZXYubWljcm9zb2Z0LmNvbV9OVERFViUyMElzc3VlNjQlMjBDQSg2KS5jcnQw DQYJKoZIhvcNAQEFBQADgYEAmxk1iyBSfJYeDZzKZYvd0fUJtCgb3XHlXXk5FSYIF9MhQIiNEqXr RCKqbZ04NAQ9GWNLd18TTKlCtyX58ExkQem0gopXqVz2vosiduGg3ClcNxft1VCuAsAeO3Ut+kCy roKF2c2Z1DXV2Xef0XTUopvr/GxnvETceAcFjhRr5xswgganMIIGEKADAgECAgoUXpdDAAAAAAAo MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNV BAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAxMTEwMTIwNTcxMVoXDTAy MDkyMDIxMzMyOFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwggG2 MIIBKwYHKoZIzjgEATCCAR4CgYEA+C8tsWT9/wRFSSpuX/EWDdw9JXBNItcNpQijM8iHGhCAvOLM MtYKSmNGeEfEQM4o/IUZMPHIl0+mreZoAx6O5Sd2j5hDrMcJ8ZDfIYWbOdITwbRhlbOgdYo1RGYh nU85Uy53iBXOjJOxxDL97D+0tSr1iQ5bPa60SWBZckwd+QECFQC6SuANG+2mus3kNWZDzwvYkXAo 3wKBgGe4TMedVC32vpClPeBaNRx93A3a0punW+cPKKsTiZI/fqmtt6fZJd3D3YqBrIQ0IxeCzvEf r0kTzP1BuYq+y5JBOror681wxhxdeguP2aDAHWR1O1BrbqB4SPdhpom5s15G4jFjcrw92IjNeD6v wWPURzVQvFdrblDXvmyde5ULA4GEAAKBgAZWBKiqZbwqp6gdR1nskDn0UOVCS7UkzRipC+jzwHG8 XVrDdSYg2piw8b5k12JvJFkrkZM0qqxj4rKTSAyzgJl0WO/bV+CFg/SKbFYRj/FOgu8nDc2aTTOm xLgUIAFVX30gWvfULKu4Eqz5JBQPBHopE6JcSjOXTjNNWdgRnaX5o4IDYTCCA10wEgYJKwYBBAGC NxUBBAUCAwEAAzAjBgkrBgEEAYI3FQIEFgQUGMUaNFgsr5GgGsVlgyKT+sb/FRUwHQYDVR0OBBYE FM/Fuhf/LccQgPW5DplKb/ScK/sZMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQE AwIBxjAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFHfJdGksOf44ZfSHBVgIzr26l9oQMIIB OgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgc5sZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290 JTIwQ0EsQ049d2hpY2FzYXJvb3RjYSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1taWNyb3NvZnQsREM9Y29t P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZOaHR0cDovL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5y b2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EuY3JsMIIBUwYIKwYBBQUHAQEEggFFMIIBQTCBwAYI KwYBBQUHMAKGgbNsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1 YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRk ZXYsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2Vy dGlmaWNhdGlvbkF1dGhvcml0eTB8BggrBgEFBQcwAoZwaHR0cDovL3doaWNhc2Fyb290Y2EubnRk ZXYubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYubWljcm9zb2Z0 LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBLmNydDAUBgNVHSABAf8ECjAIMAYGBFUdIAAwDQYJ KoZIhvcNAQEFBQADgYEAMWIlFJq094wxahPtYNIApwcYHwt5jJCEbVQN7EvgGQgeUHVcBzCJ+VW3 M/lB86vhikv30TNhE3dfcueigGjRSOTUiz7rr2SGLs8NEArFY29aNCQ0/GetHm66Cww7ZVzgZ5mr FY5nOTw8lSq5RrU8gi4livaGZDTVFeDif8a7op8xggK2MIICsgIBATBwMGIxEzARBgoJkiaJk/Is ZAEZFgNjb20xGTAXBgoJkiaJk/IsZAEZFgltaWNyb3NvZnQxFTATBgoJkiaJk/IsZAEZFgVudGRl djEZMBcGA1UEAxMQTlRERVYgSXNzdWU2NCBDQQIKQPyrngAGABV2OjAJBgUrDgMCGgUAoIIBnDAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA4MTUyMjI4MDRaMCMG CSqGSIb3DQEJBDEWBBSCyMN9lqIEosFLB7NIbnSqTPh6QTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgkrBgEEAYI3EAQxWzBZMEsxCzAJBgNVBAYTAlVT MRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NV RTMgQ0ECCigdumoAAQAZXnkwagYLKoZIhvcNAQkQAgsxW6BZMEsxCzAJBgNVBAYTAlVTMRIwEAYD VQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EC CigdumoAAQAZXnkwDQYJKoZIhvcNAQEBBQAEgYAM6p6RBplycwZeKZPn3k7ptwUjfb1zw2TiNU0a nI7zNx0b5SOtLWNS2U7MjTEuu1GAWa6ZcOB6ni+rX5m56X7cJigAAqNZZE1b0Lh0ljr+9OLY+7Jj yD6QWwIcvLOZJEaTDlqHQJgnsq0YrIlh5nLIAh+nTAO6dJoxutM9Z6Zf9gAAAAAAAA== ------=_NextPart_000_0036_01C24470.59124270-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 15 19:39:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20099 for ; Thu, 15 Aug 2002 19:39:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17744; Thu, 15 Aug 2002 19:36:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17713 for ; Thu, 15 Aug 2002 19:36:06 -0400 (EDT) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20008 for ; Thu, 15 Aug 2002 19:34:45 -0400 (EDT) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id g7FNa2kC025120; Thu, 15 Aug 2002 23:36:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020815160519.03935100@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 Aug 2002 16:35:45 -0700 To: "Paul Leach" From: "Kurt D. Zeilenga" Subject: RE: [ldapext] draft-ietf-ldapext-locate Cc: , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Michael Armijo" , "Levon Esibov" , , , In-Reply-To: <4AEE3169443CDD4796CA8A00B02191CD04929820@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org At 03:28 PM 2002-08-15, Paul Leach wrote: >> -----Original Message----- >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >> Sent: Thursday, August 15, 2002 15:09 >> To: Paul Leach >> Subject: RE: [ldapext] draft-ietf-ldapext-locate >> At 02:10 PM 2002-08-15, Paul Leach wrote: >> >> -----Original Message----- >> >> From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] >> >> Sent: Thursday, August 15, 2002 12:33 >> >> To: Kurt D. Zeilenga >> >> Subject: Re: [ldapext] draft-ietf-ldapext-locate >> > >> >> > My answer to this is, the mechanism should be >> implemented/used as >> >> > detailed in the technical specification for the application (or >> >> > protocol) requiring its use. >> >> That's a very reasonable answer. >> >> > That is, I agree that implementations should not use >> this mechanism >> >> > unless they implement a particular technical specification which >> >> > prescribes use of the mechanism. This should be clarified. >> > >> >I don't agree with this, because there are existing specs that don't >> >prescribe its use, where is was in fact the intent that this >> mechanism >> >be allowed to be used. >> >> I have a problem with allowing use of locate whenever or >> whereever an implementation might choose to use it. For >> example, it would be not be appropriate for a server >> implementing draft-zeilenga-ldap-namedref (approved for >> publication) to replace an empty hostpart of a LDAP URLs of a >> referral object based on DNS SRV information when generating >> referrals and search references (writing the hostpart is not >> allowed by namedref). However, if the object was a dnsref >> instead, then the server should rewrite the empty hostpart >> because that's exactly what the technical specification >> (draft-zeilenga-ldap-dnsref, presently expired) prescribes. > >You're jumping the gun. I'm not saying that it should be able to be used >anywhere an implementation wants to. >I'm saying that for the two purposes listed below , implementations may >use it. I'm saying that current specifications are inadequate to allow implementations to use it without further specification. >> >I propose that we say this about when it MAY be used: >> > >> >1. By clients wishing to locate an authoritative LDAP server for DNs >> >that contain DCs on the right side of a DN, when they have not been >> >configured with either implementation specific information to the >> >contrary, or when they are not using some other (future) >> standard for >> >locating said LDAP server. >> >> I have problem with locate providing a specification of this >> application of the mechanism. For example, this specification >> would state whether it was appropriate or not for a client to > >I just don't understand the preceding sentence. Sorry, I meant "I have NO problem with...". That is, I believe locate should provide a technical specification detailing this application of the locate mechanism. >> ignore explicit location information provided with a DN... or >> whether the client which obtained a DN from a server should >> ask that server for location information before using the >> locate mechanism. > >That's what I meant by "using some other future standard". If some >standard says "thou shalt not ignore this explicit location >information", then this item doesn't apply. In my opinion, we need to either say "Future specifications will prescribe where this mechanism can be used" or we need to prescribe where this mechanism can be used in current specifications (and allow future specifications to prescribe additional uses of the mechanism). >AFAIK, there is currently no other standardized way to find LDAP >servers. There is no standard mechanism for a client to determine its access point into the distributed information service. However, once the client has knowledge of an LDAP server, there is a standardized way for clients to find servers holding other DNs. (Unfornately, most servers don't have much knowledge to share.) When should an LDAP client use the DNS SRV locate mechanism instead of the native LDAP mechanism? Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Aug 16 03:17:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07934 for ; Fri, 16 Aug 2002 03:17:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14776; Fri, 16 Aug 2002 03:13:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15844 for ; Thu, 15 Aug 2002 18:57:01 -0400 (EDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19262 for ; Thu, 15 Aug 2002 18:55:41 -0400 (EDT) Received: from mailscan-out1.cac.washington.edu (mailscan-out1.cac.washington.edu [140.142.32.17]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.06) with SMTP id g7FMv1ej018847 for ; Thu, 15 Aug 2002 15:57:01 -0700 Received: FROM smtp.washington.edu BY mailscan-out1.cac.washington.edu ; Thu Aug 15 15:57:00 2002 -0700 Received: from D-140-142-21-15.dhcp2.washington.edu (D-140-142-21-15.dhcp2.washington.edu [140.142.21.15]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.06) with ESMTP id g7FMuxTb028593 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 15 Aug 2002 15:57:00 -0700 Date: Thu, 15 Aug 2002 15:57:05 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost.localdomain To: Chris Harding cc: IETF ldapext WG Subject: Re: [ldapext] Directory Best Practice Guide In-Reply-To: <5.1.0.14.1.20020815174302.00b06740@mailhome.rdg.opengroup.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org On Thu, 15 Aug 2002, Chris Harding wrote: > That's great! We need lots more volunteers, though. How about it, folks? Let me note that in the Internet2 Middleware Initiative we've developed some material along the lines of directory best practices, see: http://middleware.internet2.edu/core/directories.shtml and there is ongoing work: http://middleware.internet2.edu/dir/ Perhaps the closest to what folks seem to be talking about here is: http://www.georgetown.edu/giia/internet2/ldap-recipe/ Some of us have also spent time in the trenches working on generalized best practices docs, and while we bear the scars that Alexis hinted at, probably could contribute to some new wider effort. - RL "Bob" Morgan University of Washington _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Aug 16 06:28:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10564 for ; Fri, 16 Aug 2002 06:28:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22824; Fri, 16 Aug 2002 06:20:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22754 for ; Fri, 16 Aug 2002 06:20:22 -0400 (EDT) Received: from clmboh1-smtp3.columbus.rr.com (clmboh1-smtp3.columbus.rr.com [65.24.0.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10419 for ; Fri, 16 Aug 2002 06:19:01 -0400 (EDT) Received: from willeke.com (dhcp024-166-083-155.neo.rr.com [24.166.83.155]) by clmboh1-smtp3.columbus.rr.com (8.11.2/8.11.2) with ESMTP id g7GAK5c07528; Fri, 16 Aug 2002 06:20:09 -0400 (EDT) Message-ID: <3D5CD1BE.3050801@willeke.com> Date: Fri, 16 Aug 2002 06:19:42 -0400 From: Jim Willeke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020812 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Harding CC: christine.yoon@us.pwcglobal.com, ldapext@ietf.org, "'Liben, Michael \(GTS\)'" , dif-members@opengroup.org, michael.d.compton@us.pwcglobal.com, jamie.quick@us.pwcglobal.com, brian.jensen@us.pwcglobal.com Subject: Re: [ldapext] Directory Best Practice Guide References: <5.1.0.14.1.20020815174302.00b06740@mailhome.rdg.opengroup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8bit I'm In. -jim http://www.directory-info.com/ Chris Harding wrote: > Hi, Christine - > > That's great! We need lots more volunteers, though. How about it, folks? > > At 10:40 15/08/2002 -0400, christine.yoon@us.pwcglobal.com wrote: > >> Chris, >> >> We (PwC) have many years of experience in directory/security >> implementation for various clients including Fortune 500 companies. >> I would like to volunteer to author the Directory Best Practice Guide. >> >> >> -Christine Yoon >> PricewaterhouseCoopers >> (201)981-1172 - cell >> (732)706-3559 - office >> >> >> >> >> >> Chris Harding >> > >> up.org> cc: >> , "'Liben, Michael \(GTS\)'" >> , "'Patrik >> Sent by: Fältström'" >> , dif-members@opengroup.org >> ldapext-admin@ietf Subject: RE: >> [ldapext] draft-ietf-ldapext-locate >> .org >> 08/15/2002 06:20 >> AM >> >> >> >> >> >> >> >> >> >> >> Hi, Alexis - >> >> A Directory Best Practices Guide is something that is clearly needed. I >> believe that the Directory Interoperability Forum should support its >> creation and contribute to it. The DIF could for example provide >> publication or web page hosting facilities if needed, and could provide >> some review effort. However, I don't believe that the DIF could on >> its own >> provide the technical authoring and review effort needed to deliver an >> authoritative guide. >> >> Because there is (as you point out) a need for rapid evolution, a set of >> web pages would be far and away the best medium for such a guide. >> What we >> need is a set of contributors, a review group, and an editorial >> committee, >> working within the framework of an established review and publications >> procedure. This procedure must be public and must allow rapid turnaround >> from authoring to publication - I would say within 2 months at the >> outside. >> >> Perhaps it could be handled as a kind of Open Source project. >> >> I believe (the members make the decisions, I just support them) that the >> DIF would be interested in co-ordinating or participating in a >> project of >> this nature. >> >> At 16:00 14/08/2002 -0400, Alexis Bor wrote: >> >I proved to myself and others (while I was at Boeing doing R&D work in >> >Directory) back in 1992 that putting any meaning into a DN is not a >> good >> >practice. We took the example of a company of 100,000 and looked at the >> >different approaches for DN's - Geographic, Political, Hybrid and >> >others. >> > >> >It became clear that it would be a maintenance headache and cause lots >> >of stress on the overall infrastructure. It was very hard to convince >> >most people for a long time until some work that Jeff Hodges did at >> >Stanford got a lot of attention in the late 90's. >> > >> >A real hard piece of work to put forward is a best practices document. >> >The number of opinions will typically exceed the number of people >> >working on the document. What we learned in the mid 90's was that such >> >a document evolves faster than the review cycle (part of an EMA effort >> >to write a white paper on directory best practices), making it out of >> >date before you even finish the review of it. However, with all of the >> >experience that everyone is getting, it may be worth resurrecting the >> >idea again. >> > >> >Perhaps an industry group can step up to the challenge - any takers? >> > >> >-- Alexis >> > >> >Alexis Bor >> >Directory Works, Inc. >> >www.directoryworks.com >> > >> > >> >-----Original Message----- >> >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf >> >Of Liben, Michael (GTS) >> >Sent: Tuesday, August 13, 2002 5:32 PM >> >To: 'Patrik Fältström' >> >Cc: ldapext@ietf.org >> >Subject: RE: [ldapext] draft-ietf-ldapext-locate >> > >> >In general, divining any meaning from a distinguished name is not good >> >practice (my $.02). The implications are that your app will likely >> >break. The SHOULD NOT allows you impart meaning to your >> >distinguished name if you so choose. A MUST NOT would be an absolute >> >prohibition. >> > >> > >> > >> >-----Original Message----- >> >From: Patrik Fältström [mailto:paf@cisco.com] >> >Sent: Tuesday, August 13, 2002 5:54 AM >> >To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; >> >rlmorgan@washington.edu >> >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se >> >Subject: [ldapext] draft-ietf-ldapext-locate >> > >> >Comments from the IESG: >> >------- >> >The document says: >> > If there are no >> > matching SRV records available for the converted DN the client >> >SHOULD >> > NOT attempt to 'walk the tree' by removing the least significant >> > portion of the constructed fully qualified domain name. >> > >> >The meaning of "SHOULD NOT" is "don't do this unless you understand the >> >implications". Well, I don't know where to look to understand the >> >implications. >> >Thus I think it would be useful to either make it a MUST NOT, or >> explain >> >something about the implications of using shorter labels. >> > >> >Alternatively specify SHOULD NOT do this in general, but MUST NOT ever >> >use this with just one label (i.e. MUST NOT look for _ldap._tcp.) >> >or something similar. >> > >> >------- >> >The document is unclear (see next note) on: >> > >> >(a) When this is to be used (only when not having the foggiest clue >> >where a >> >record with a specific DN is, or every time a record is to be >> accessed?) >> > >> >(b) How to handle the case when one have a DN which have both dc and >> >non-dc >> >components. Example of this is when two records stored on two different >> >servers share the same dc components. IF those records per definition >> >(of >> >this document) have to be stored on the same server, or referrals have >> >to >> >be stored on them to point to the other, then this document has a scope >> >which is larger than at first glance. I.e. part from stating how to >> >locate >> >a record using DNS, it also has an implicit result that DC is _the_ >> >naming >> >convention for the Internet. Please explain. >> > >> >------- >> >This document define a conversion that is over-restrictive. >> > >> > The output domain name is initially empty. The DN is processed >> >in >> > right-to-left order (i.e., beginning with the first RDN in the >> > sequence of RDNs). An RDN is able to be converted if it (1) >> > consists of a single AttributeTypeAndValue; (2) the attribute >> >type >> > is "DC"; and (3) the attribute value is non-null. If it can be >> > converted, the attribute value is used as a domain name >> >component >> > (label). The first such value becomes the rightmost (i.e., >> most >> > significant) domain name component, and successive >> converted RDN >> > values extend to the left. If an RDN cannot be converted, >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > processing stops. If the output domain name is empty when >> > ^^^^^^^^^^^^^^^^^ >> > processing stops, the DN cannot be converted into a domain >> name. >> > >> >The underscored text should be removed and replaced with text that >> >states the non-DC RDN's are skipped over. So for example the DN: >> > >> > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, >> > dc=edu >> > >> >Can be unambiguously translated into: >> > >> > lees.mit.edu >> > >> >Yet the underscored words make this translation invalid. With the >> >Underscored rule in place this DN would convert to just 'mit.edu' >> >which is not the desired result. >> > >> >The additional flexibility offered will permit us to convert existing >> >PKI systems to make use of this feature without requiring all >> >certificates to be re-issued. It will also permit us to create DIT's >> >that can be delegated at more points rather then requiring all >> >structure to be at the very top where the DC components are, prior to >> >any non-DC component. >> > >> >For example if MIT had a DIT with a top level name of: >> > >> > o=MIT,c=US >> > >> >and a subordinate lab wanted to use this document, they could have a >> >delegated subtree like: >> > >> > ou=Lab for X,o=MIT,c=US >> > >> >and then add a DC component below this as: >> > >> > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US >> > >> >Under my more flexible approach this would work. Without the >> >flexibility they would be SOL until MIT redid its entire DIT to >> >be: >> > >> > o=MIT,c=US,dc=mit,dc=edu >> > >> >and then they would have to be jointed in as: >> > >> > o=MIT,c=US,dc=labx,dc=mit,dc=edu >> > >> >Ned: I have three concerns here: >> > >> >(0) It isn't clear when this approach is supposed to be used. DNs are an >> > integral part of *every* LDAP operation. Is it the intent that >> >an >> >LDAP >> > client check every DN it sees for DC fields and if it finds >> them >> >use >> > this approach. Or is it only appropriate in specific >> situations? >> > >> >(1) This document specifies two things: How to translate a DN to a DNS >> > name and how to use a DNS name to locate a corresponding LDAP >> >server. >> > The document seems to imply that the latter is only used when a >> >DNS >> > name is produced by the former. I wonder if this restriction is >> >a >> >good >> > idea: Isn't the ability to use SRV records to locate more >> >generally >> > useful than this limited context? >> > >> > The answer to this may be no, but if so, the rationale for >> that >> >answer >> > should be part of the specification. >> > >> >(2) I don't see any provision for fallback to A records if SRV records >> > don't exist. I can easily see this being a Bad Idea, if so, >> >there >> > should be an explicit prohibition of it in the document along >> >with >> > some explanation of why it is a bad idea. >> > >> > >> > >> >------- >> >References should be split in normative and non-normative. >> >------- >> >I wonder about the reference to RFC1700, which has been obsoleted >> >by RFC3232, and that RFC actuallt talks about a DB that contains >> >the info. So How should this doc refer to that? >> >------- >> >Needs better abstract; doesn't even use the word "SRV". (and the rfc >> >editor will surely complain when they get it...) >> > >> >Might be good to use SRV in the title as well, as opposed to just >> >"DNS". But this I'm less concerned about, as there are two steps, and >> >only the second step is SRV records. >> > >> >E.g., maybe change: >> > >> > Discovering LDAP Services with DNS >> > >> >To something like: >> > >> > Discovering LDAP Services with DNS SRV Resource Records >> > >> >However, the rfc editor probably won't like the abbreviation >> >"SRV". Unfortunately, I don't think the acronym expands into anything >> >useful. >> >------- >> >I have three concerns here: >> > >> >(0) It isn't clear when this approach is supposed to be used. DNs are an >> > integral part of *every* LDAP operation. Is it the intent that an >> >LDAP >> > client check every DN it sees for DC fields and if it finds >> them use >> > this approach. Or is it only appropriate in specific situations? >> > >> >(1) This document specifies two things: How to translate a DN to a DNS >> > name and how to use a DNS name to locate a corresponding LDAP >> >server. >> > The document seems to imply that the latter is only used when a DNS >> > name is produced by the former. I wonder if this restriction is a >> >good >> > idea: Isn't the ability to use SRV records to locate more >> generally >> > useful than this limited context? >> > >> > The answer to this may be no, but if so, the rationale for that >> >answer >> > should be part of the specification. >> > >> >(2) I don't see any provision for fallback to A records if SRV records >> > don't exist. I can easily see this being a Bad Idea, if so, there >> > should be an explicit prohibition of it in the document along with >> > some explanation of why it is a bad idea. >> > >> > >> > >> > >> > >> >_______________________________________________ >> >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 >> >> >> 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 >> ======================================================================== >> The Open Group Conference >> Boundaryless Information Flow: The Role of Open Source >> Cannes, France, 14-18th October >> http://www.opengroup.org/cannes2002 >> ======================================================================== >> >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www1.ietf.org/mailman/listinfo/ldapext >> >> >> >> >> _________________________________________________________________ >> The information transmitted is intended only for the person or >> entity to which it is addressed and may contain confidential >> and/or privileged material. Any review, retransmission, >> dissemination or other use of, or taking of any action in >> reliance >> upon, this information by persons or entities other than the >> intended recipient is prohibited. If you received this in >> error, >> please contact the sender and delete the material from any >> computer. >> >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www1.ietf.org/mailman/listinfo/ldapext > > > > 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 > ======================================================================== > The Open Group Conference > Boundaryless Information Flow: The Role of Open Source > Cannes, France, 14-18th October > http://www.opengroup.org/cannes2002 > ======================================================================== > > > _______________________________________________ > 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 Fri Aug 16 10:31:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16918 for ; Fri, 16 Aug 2002 10:31:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03896; Fri, 16 Aug 2002 10:27:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03864 for ; Fri, 16 Aug 2002 10:27:56 -0400 (EDT) Received: from uxtpaprx1.nam.pwcinternal.com (uxtpaprx1.pwcglobal.com [155.201.16.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16743 for ; Fri, 16 Aug 2002 10:26:34 -0400 (EDT) From: christine.yoon@us.pwcglobal.com Received: from us-amsmta005.nam.pwcinternal.com (us-amsmta005.nam.pwcinternal.com [10.26.104.89]) by uxtpaprx1.nam.pwcinternal.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7GERF302907; Fri, 16 Aug 2002 10:27:15 -0400 (EDT) Subject: [ldapext] Directory Best Practice Guide To: mark.wahl@sun.com, roland@catalogix.se Cc: ldapext@ietf.org, c.harding@opengroup.org, Michael Haines - Sun , alexis.bor@directoryworks.com, Michael.Haines@sun.com, hyc@highlandsun.com, jim@willeke.com, rlmorgan@washington.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 16 Aug 2002 10:27:02 -0400 X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.9 |November 16, 2001) at 08/16/2002 10:27:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Mark/Roland, It seems that we have enough people who want to work on Directory Best Practice. Can we do this work under ldapext? -Christine Yoon PricewaterhouseCoopers cell: (201)981-1172 office: (732)706-3559 _________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Aug 16 11:59:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20347 for ; Fri, 16 Aug 2002 11:59:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09013; Fri, 16 Aug 2002 11:55:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08982 for ; Fri, 16 Aug 2002 11:55:18 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19967 for ; Fri, 16 Aug 2002 11:53:56 -0400 (EDT) Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12589 for ; Fri, 16 Aug 2002 08:54:46 -0700 (PDT) Received: from sun.com (dhcp-uaus09-130-199 [129.153.130.199]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g7GFsj019155 for ; Fri, 16 Aug 2002 10:54:45 -0500 (CDT) Message-ID: <3D5D20E7.6FD81C14@sun.com> Date: Fri, 16 Aug 2002 10:57:27 -0500 From: Mark Wahl X-Mailer: Mozilla 4.77 [en]C-CCK-MCD NSCPCD477 (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: ldapext@ietf.org Subject: Re: [ldapext] Directory Best Practice Guide Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7bit christine.yoon@us.pwcglobal.com wrote: > > Mark/Roland, > > It seems that we have enough people who want to work on Directory Best > Practice. > Can we do this work under ldapext? Not in the LDAPEXT working group, because the LDAPEXT working group has shut down several meetings ago and so is not taking new work items. If you wish to have Directory Best Practice be a work item in the IETF, you would either want to find an active working group that would be willing to sponsor this, request to create a new working group for this purpose, or just start an discussion list for directory best practice to develop individual drafts and perhaps determine if there is sufficiently broad interest and sufficiently narrow problem scope to create a WG. Note that there have been attempts in the past to create a working group for this kind of problem area but these have not lasted, so the first or third approach is the one I would recommend. Mark Wahl Sun Microsystems Inc. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Aug 16 13:23:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24138 for ; Fri, 16 Aug 2002 13:23:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15723; Fri, 16 Aug 2002 13:06:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15698 for ; Fri, 16 Aug 2002 13:06:26 -0400 (EDT) Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23134 for ; Fri, 16 Aug 2002 13:05:04 -0400 (EDT) Received: from CHRIS-H.opengroup.org (dhcp192-153-166-32.rdg.opengroup.org [192.153.166.32]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id g7GH5pQ29468; Fri, 16 Aug 2002 18:05:51 +0100 Message-Id: <5.1.0.14.1.20020816180550.02ee0818@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 Aug 2002 18:09:35 +0100 To: Mark Wahl , ldapext@ietf.org From: Chris Harding Subject: Re: [ldapext] Directory Best Practice Guide In-Reply-To: <3D5D20E7.6FD81C14@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Hi - Sounds like the first practical step is to set up an IETF list to discuss what is needed and how to create it. I'm happy to volunteer to set up and maintain that list. What do I need to do to do this as an IETF list? At 10:57 16/08/2002 -0500, Mark Wahl wrote: >christine.yoon@us.pwcglobal.com wrote: > > > > Mark/Roland, > > > > It seems that we have enough people who want to work on Directory Best > > Practice. > > Can we do this work under ldapext? > >Not in the LDAPEXT working group, because the LDAPEXT working group has shut >down several meetings ago and so is not taking new work items. > >If you wish to have Directory Best Practice be a work item in the IETF, >you would either want to find an active working group that would be willing >to sponsor this, request to create a new working group for this purpose, or >just start an discussion list for directory best practice to develop >individual drafts and perhaps determine if there is sufficiently broad >interest and sufficiently narrow problem scope to create a WG. Note that >there have been attempts in the past to create a working group for this kind >of problem area but these have not lasted, so the first or third approach is >the one I would recommend. > >Mark Wahl >Sun Microsystems Inc. > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext 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 ======================================================================== The Open Group Conference Boundaryless Information Flow: The Role of Open Source Cannes, France, 14-18th October http://www.opengroup.org/cannes2002 ======================================================================== _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Aug 19 06:07:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26889 for ; Mon, 19 Aug 2002 06:07:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA09653; Mon, 19 Aug 2002 06:03:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08860 for ; Fri, 16 Aug 2002 11:51:51 -0400 (EDT) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19804 for ; Fri, 16 Aug 2002 11:50:28 -0400 (EDT) Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26469; Fri, 16 Aug 2002 09:51:39 -0600 (MDT) Received: from zetona.com (dhcp-uaus09-130-199 [129.153.130.199]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g7GFpZ018906; Fri, 16 Aug 2002 10:51:36 -0500 (CDT) Message-ID: <3D5D202A.A0B9D853@zetona.com> Date: Fri, 16 Aug 2002 10:54:18 -0500 From: Mark Wahl X-Mailer: Mozilla 4.77 [en]C-CCK-MCD NSCPCD477 (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: christine.yoon@us.pwcglobal.com CC: mark.wahl@sun.com, roland@catalogix.se, ldapext@ietf.org, c.harding@opengroup.org, Michael Haines - Sun , alexis.bor@directoryworks.com, hyc@highlandsun.com, jim@willeke.com, rlmorgan@washington.edu Subject: Re: [ldapext] Directory Best Practice Guide References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7bit christine.yoon@us.pwcglobal.com wrote: > > Mark/Roland, > > It seems that we have enough people who want to work on Directory Best > Practice. > Can we do this work under ldapext? Not in the LDAPEXT working group, because the LDAPEXT working group has shut down several meetings ago and so is not taking new work items. If you wish to have Directory Best Practice be a work item in the IETF, you would either want to find an active working group that would be willing to sponsor this, request to create a new working group for this purpose, or just start an discussion list for directory best practice to develop individual drafts and perhaps determine if there is sufficiently broad interest and sufficiently narrow problem scope to create a WG. Note that there have been attempts in the past to create a working group for this kind of problem area but these have not lasted, so the first or third approach is the one I would recommend. Mark Wahl Sun Microsystems Inc. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Aug 19 11:04:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04457 for ; Mon, 19 Aug 2002 11:04:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23593; Mon, 19 Aug 2002 11:00:12 -0400 (EDT) Received: from tyto.ciens.ucv.ve (tyto.ciens.ucv.ve [150.185.72.7]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23437 for ; Mon, 19 Aug 2002 10:58:00 -0400 (EDT) Received: from localhost (lcollado@localhost) by tyto.ciens.ucv.ve (8.11.6/8.11.6) with ESMTP id g7JECMl14963; Mon, 19 Aug 2002 10:12:26 -0400 Date: Mon, 19 Aug 2002 10:12:22 -0400 (VET) From: Collado T Luis E To: Mark Wahl cc: mark.wahl@sun.com, In-Reply-To: <3D5D202A.A0B9D853@zetona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Subject: [ldapext] groupofnames vs. groupuniquenames Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 8BIT hi, Mr. Wahl, i am a student of the UCV (Universidad Central de Venezuela). I want to know: what is the difference between the groupofnames and groupuniquenames objectclass? Thanks. *********************************** * Luis Eduardo Collado Tovar * * Estudiante de Lic. Computación * * Facultad de Ciencias * * Universidad Central de Venezuela * * Caracas.- Venezuela * ************************************ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Aug 19 12:28:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08217 for ; Mon, 19 Aug 2002 12:28:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29342; Mon, 19 Aug 2002 12:19:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29310 for ; Mon, 19 Aug 2002 12:19:35 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07713 for ; Mon, 19 Aug 2002 12:18:11 -0400 (EDT) Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25284; Mon, 19 Aug 2002 09:18:49 -0700 (PDT) Received: from sun.com (dhcp-uaus09-130-199 [129.153.130.199]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g7JGIj018009; Mon, 19 Aug 2002 11:18:46 -0500 (CDT) Message-ID: <3D611B1A.1A25EC61@sun.com> Date: Mon, 19 Aug 2002 11:21:46 -0500 From: Mark Wahl X-Mailer: Mozilla 4.77 [en]C-CCK-MCD NSCPCD477 (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Collado T Luis E CC: Mark Wahl , ldapext@ietf.org Subject: Re: [ldapext] groupofnames vs. groupuniquenames References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Content-Transfer-Encoding: 7bit Collado T Luis E wrote: > > I want to know: what is the difference between the groupofnames and > groupuniquenames objectclass? groupOfNames has the member attribute and groupOfUniqueNames has the uniqueMember attribute. This is defined in RFC 2256. The syntax of the member attribute is just a DN. The syntax of the uniqueMember attribute is a DN and an optional unique identifier. This is defined in RFC 2252. The unique identifier is a bit array, I believe. The uniqueMember comes from X.500(1993) which wanted to have a way to protect the group-based access control from a situation where an entry might be deleted and then another entry added with the same DN. If you want to ensure that the old group membership check does not permit the new entry, then you would use groupOfUniqueNames to form the group, and have a different uniqueIdentifier value in each instance over time of an entry. David Chadwick's book has a chapter on X.500 access control: http://www.isi.salford.ac.uk/staff/dwc/Version.Web/Chapter.8/Chapter8a.htm The member attribute is generally not as widely used as uniqueMember, as mMany non-X.500-based implementations of LDAP servers as well as LDAP clients tend to treat the uniqueMember attribute as being DN-valued and don't use the optional unique identifier. Hope this helps, Mark Wahl Sun Microsystems Inc. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Aug 19 15:35:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13796 for ; Mon, 19 Aug 2002 15:35:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11553; Mon, 19 Aug 2002 15:32:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11524 for ; Mon, 19 Aug 2002 15:32:07 -0400 (EDT) Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13743 for ; Mon, 19 Aug 2002 15:30:41 -0400 (EDT) Received: from CHRIS-H.opengroup.org (woodrising.demon.co.uk [193.237.13.31]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id g7JJVSQ13584; Mon, 19 Aug 2002 20:31:28 +0100 Message-Id: <5.1.0.14.1.20020819200955.00acbaf0@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 19 Aug 2002 20:32:34 +0100 To: ldapext@ietf.org, ietf-ldapbis@OpenLDAP.org, ietf-ldup@imc.org, ldap@umich.edu, dif-members@opengroup.org From: Chris Harding Cc: ldap-bpg@opengroup.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ldapext] Directory Best Practice Guide Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: LDAP Extension Working Group X-BeenThere: ldapext@ietf.org Hi - A discussion on the ldapext mail list last week came to the conclusion that a Guide to Directory Best Practice is very much needed. A number of volunteers then stepped forward to work on producing one, and The Open Group has provided a mail list ldap-bpg@opengroup.org to support their work. We don't yet have detailed terms of reference or working procedures. We have a belief in the value of this guide and the intention to produce a publicly available document with volunteer effort and using an open and public editing and review procedure. If you would like to participate in this effort, you can subscribe to the list via the web page at http://www.opengroup.org/sophocles/create_user.tpl?CALLER=show_users_archives.tpl (The page is a general one that allows subscription to a number of lists - don't forget to specify the ldap-bpg one!) I look forward to working with you on the Directory Best Practice Guide! 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 ======================================================================== The Open Group Conference Boundaryless Information Flow: The Role of Open Source Cannes, France, 14-18th October http://www.opengroup.org/cannes2002 ======================================================================== _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Aug 21 14:08:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19770 for ; Wed, 21 Aug 2002 14:08:27 -0400 (EDT) Received: from optimus (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LI8BW31679; Wed, 21 Aug 2002 14:08:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LI6VW31631 for ; Wed, 21 Aug 2002 14:06:31 -0400 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19670 for ; Wed, 21 Aug 2002 14:05:02 -0400 (EDT) Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09427 for ; Wed, 21 Aug 2002 12:06:26 -0600 (MDT) Received: from sun.com (dhcp-uaus09-130-199 [129.153.130.199]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g7LI6P019087 for ; Wed, 21 Aug 2002 13:06:25 -0500 (CDT) Message-ID: <3D63D756.C707A36C@sun.com> Date: Wed, 21 Aug 2002 13:09:26 -0500 From: Mark Wahl Reply-To: ldapext-admin@ietf.org X-Mailer: Mozilla 4.77 [en]C-CCK-MCD NSCPCD477 (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: ldapext@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ldapext] FYI mail outage 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: Mail Administrator Mail to the working groups housed at ietf.org may have been lost for the time between approx 1:00 pm EST on 20 Aug 2002 thru 12:30 pm EST on 21 Aug 2002. Mark Wahl Sun Microsystems Inc. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 22 03:27:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17399 for ; Thu, 22 Aug 2002 03:27:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M7RpW08516; Thu, 22 Aug 2002 03:27:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M7QlW08481 for ; Thu, 22 Aug 2002 03:26:47 -0400 Received: from lists.su.se (lists.su.se [130.237.162.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17369 for ; Thu, 22 Aug 2002 03:25:12 -0400 (EDT) Received: from it.su.se (klapautius.it.su.se [130.237.95.23]) by lists.su.se (8.11.6/8.11.6) with ESMTP id g7M7MxM21294; Thu, 22 Aug 2002 09:22:59 +0200 Message-ID: <3D649154.1010805@it.su.se> Date: Thu, 22 Aug 2002 09:23:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chadwick CC: Paul Leach , "Kurt D. Zeilenga" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Michael Armijo , Levon Esibov , rlmorgan@washington.edu, ldapext@ietf.org, Ned Freed , ietf-ldap@paf.se, roland@catalogix.se Subject: Re: [ldapext] draft-ietf-ldapext-locate References: <4AEE3169443CDD4796CA8A00B02191CD0492980F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <3D5B842E.70008@it.su.se> <3D62A609.F666854A@salford.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 David Chadwick wrote: > > Leif Johansson wrote: snip snip > > Leif is correct in saying that DNs in certs are used for two purposes, > but I dont see a problem in that, if the DN is a permanent DN that does > not change with time. > > regards > > David It is a problem if your ldap dn design is incompatible with the pki dn design which it often is! For instance the recently much debated situation where uid=u4711+cn=Joe Random,... is used in the pki dn whereas uid=u4711,... is used in your directory where multivalued rdn's suck. But I digress from the main topic of this thread. leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Aug 22 18:02:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11953 for ; Thu, 22 Aug 2002 18:02:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7MLtuo20995; Thu, 22 Aug 2002 17:55:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7LGdxW25760 for ; Wed, 21 Aug 2002 12:39:59 -0400 Received: from dns.caledonia.net (dns.caledonia.net [207.40.197.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14085 for ; Wed, 21 Aug 2002 11:46:28 -0400 (EDT) Received: from D7ST2111 (pool-141-158-54-111.phil.east.verizon.net [141.158.54.111]) by dns.caledonia.net; Wed, 21 Aug 2002 09:45:59 -0600 Reply-To: From: "Chris Apple" To: "'Jim Willeke'" , "'Chris Harding'" Cc: , , "'Liben, Michael \(GTS\)'" , , , , Subject: RE: [ldapext] Directory Best Practice Guide Date: Wed, 21 Aug 2002 11:45:07 -0400 Organization: DSI-Consulting, Inc. Message-ID: <000d01c24929$bad679a0$0300a8c0@D7ST2111> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3D5CD1BE.3050801@willeke.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id g7LGdxW25761 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: 8bit Ditto. I'm in. Chris Apple - Principal Architect DSI Consulting, Inc. http://www.dsi-consulting.com mailto:capple@dsi-consulting.net -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf Of Jim Willeke Sent: Friday, August 16, 2002 6:20 AM To: Chris Harding Cc: christine.yoon@us.pwcglobal.com; ldapext@ietf.org; 'Liben, Michael (GTS)'; dif-members@opengroup.org; michael.d.compton@us.pwcglobal.com; jamie.quick@us.pwcglobal.com; brian.jensen@us.pwcglobal.com Subject: Re: [ldapext] Directory Best Practice Guide I'm In. -jim http://www.directory-info.com/ Chris Harding wrote: > Hi, Christine - > > That's great! We need lots more volunteers, though. How about it, folks? > > At 10:40 15/08/2002 -0400, christine.yoon@us.pwcglobal.com wrote: > >> Chris, >> >> We (PwC) have many years of experience in directory/security >> implementation for various clients including Fortune 500 companies. >> I would like to volunteer to author the Directory Best Practice Guide. >> >> >> -Christine Yoon >> PricewaterhouseCoopers >> (201)981-1172 - cell >> (732)706-3559 - office >> >> >> >> >> >> Chris Harding >> > >> up.org> cc: >> , "'Liben, Michael \(GTS\)'" >> , "'Patrik >> Sent by: Fältström'" >> , dif-members@opengroup.org >> ldapext-admin@ietf Subject: RE: >> [ldapext] draft-ietf-ldapext-locate >> .org >> 08/15/2002 06:20 >> AM >> >> >> >> >> >> >> >> >> >> >> Hi, Alexis - >> >> A Directory Best Practices Guide is something that is clearly needed. I >> believe that the Directory Interoperability Forum should support its >> creation and contribute to it. The DIF could for example provide >> publication or web page hosting facilities if needed, and could provide >> some review effort. However, I don't believe that the DIF could on >> its own >> provide the technical authoring and review effort needed to deliver an >> authoritative guide. >> >> Because there is (as you point out) a need for rapid evolution, a set of >> web pages would be far and away the best medium for such a guide. >> What we >> need is a set of contributors, a review group, and an editorial >> committee, >> working within the framework of an established review and publications >> procedure. This procedure must be public and must allow rapid turnaround >> from authoring to publication - I would say within 2 months at the >> outside. >> >> Perhaps it could be handled as a kind of Open Source project. >> >> I believe (the members make the decisions, I just support them) that the >> DIF would be interested in co-ordinating or participating in a >> project of >> this nature. >> >> At 16:00 14/08/2002 -0400, Alexis Bor wrote: >> >I proved to myself and others (while I was at Boeing doing R&D work in >> >Directory) back in 1992 that putting any meaning into a DN is not a >> good >> >practice. We took the example of a company of 100,000 and looked at the >> >different approaches for DN's - Geographic, Political, Hybrid and >> >others. >> > >> >It became clear that it would be a maintenance headache and cause lots >> >of stress on the overall infrastructure. It was very hard to convince >> >most people for a long time until some work that Jeff Hodges did at >> >Stanford got a lot of attention in the late 90's. >> > >> >A real hard piece of work to put forward is a best practices document. >> >The number of opinions will typically exceed the number of people >> >working on the document. What we learned in the mid 90's was that such >> >a document evolves faster than the review cycle (part of an EMA effort >> >to write a white paper on directory best practices), making it out of >> >date before you even finish the review of it. However, with all of the >> >experience that everyone is getting, it may be worth resurrecting the >> >idea again. >> > >> >Perhaps an industry group can step up to the challenge - any takers? >> > >> >-- Alexis >> > >> >Alexis Bor >> >Directory Works, Inc. >> >www.directoryworks.com >> > >> > >> >-----Original Message----- >> >From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf >> >Of Liben, Michael (GTS) >> >Sent: Tuesday, August 13, 2002 5:32 PM >> >To: 'Patrik Fältström' >> >Cc: ldapext@ietf.org >> >Subject: RE: [ldapext] draft-ietf-ldapext-locate >> > >> >In general, divining any meaning from a distinguished name is not good >> >practice (my $.02). The implications are that your app will likely >> >break. The SHOULD NOT allows you impart meaning to your >> >distinguished name if you so choose. A MUST NOT would be an absolute >> >prohibition. >> > >> > >> > >> >-----Original Message----- >> >From: Patrik Fältström [mailto:paf@cisco.com] >> >Sent: Tuesday, August 13, 2002 5:54 AM >> >To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com; >> >rlmorgan@washington.edu >> >Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se >> >Subject: [ldapext] draft-ietf-ldapext-locate >> > >> >Comments from the IESG: >> >------- >> >The document says: >> > If there are no >> > matching SRV records available for the converted DN the client >> >SHOULD >> > NOT attempt to 'walk the tree' by removing the least significant >> > portion of the constructed fully qualified domain name. >> > >> >The meaning of "SHOULD NOT" is "don't do this unless you understand the >> >implications". Well, I don't know where to look to understand the >> >implications. >> >Thus I think it would be useful to either make it a MUST NOT, or >> explain >> >something about the implications of using shorter labels. >> > >> >Alternatively specify SHOULD NOT do this in general, but MUST NOT ever >> >use this with just one label (i.e. MUST NOT look for _ldap._tcp.) >> >or something similar. >> > >> >------- >> >The document is unclear (see next note) on: >> > >> >(a) When this is to be used (only when not having the foggiest clue >> >where a >> >record with a specific DN is, or every time a record is to be >> accessed?) >> > >> >(b) How to handle the case when one have a DN which have both dc and >> >non-dc >> >components. Example of this is when two records stored on two different >> >servers share the same dc components. IF those records per definition >> >(of >> >this document) have to be stored on the same server, or referrals have >> >to >> >be stored on them to point to the other, then this document has a scope >> >which is larger than at first glance. I.e. part from stating how to >> >locate >> >a record using DNS, it also has an implicit result that DC is _the_ >> >naming >> >convention for the Internet. Please explain. >> > >> >------- >> >This document define a conversion that is over-restrictive. >> > >> > The output domain name is initially empty. The DN is processed >> >in >> > right-to-left order (i.e., beginning with the first RDN in the >> > sequence of RDNs). An RDN is able to be converted if it (1) >> > consists of a single AttributeTypeAndValue; (2) the attribute >> >type >> > is "DC"; and (3) the attribute value is non-null. If it can be >> > converted, the attribute value is used as a domain name >> >component >> > (label). The first such value becomes the rightmost (i.e., >> most >> > significant) domain name component, and successive >> converted RDN >> > values extend to the left. If an RDN cannot be converted, >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > processing stops. If the output domain name is empty when >> > ^^^^^^^^^^^^^^^^^ >> > processing stops, the DN cannot be converted into a domain >> name. >> > >> >The underscored text should be removed and replaced with text that >> >states the non-DC RDN's are skipped over. So for example the DN: >> > >> > cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit, >> > dc=edu >> > >> >Can be unambiguously translated into: >> > >> > lees.mit.edu >> > >> >Yet the underscored words make this translation invalid. With the >> >Underscored rule in place this DN would convert to just 'mit.edu' >> >which is not the desired result. >> > >> >The additional flexibility offered will permit us to convert existing >> >PKI systems to make use of this feature without requiring all >> >certificates to be re-issued. It will also permit us to create DIT's >> >that can be delegated at more points rather then requiring all >> >structure to be at the very top where the DC components are, prior to >> >any non-DC component. >> > >> >For example if MIT had a DIT with a top level name of: >> > >> > o=MIT,c=US >> > >> >and a subordinate lab wanted to use this document, they could have a >> >delegated subtree like: >> > >> > ou=Lab for X,o=MIT,c=US >> > >> >and then add a DC component below this as: >> > >> > dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US >> > >> >Under my more flexible approach this would work. Without the >> >flexibility they would be SOL until MIT redid its entire DIT to >> >be: >> > >> > o=MIT,c=US,dc=mit,dc=edu >> > >> >and then they would have to be jointed in as: >> > >> > o=MIT,c=US,dc=labx,dc=mit,dc=edu >> > >> >Ned: I have three concerns here: >> > >> >(0) It isn't clear when this approach is supposed to be used. DNs are an >> > integral part of *every* LDAP operation. Is it the intent that >> >an >> >LDAP >> > client check every DN it sees for DC fields and if it finds >> them >> >use >> > this approach. Or is it only appropriate in specific >> situations? >> > >> >(1) This document specifies two things: How to translate a DN to a DNS >> > name and how to use a DNS name to locate a corresponding LDAP >> >server. >> > The document seems to imply that the latter is only used when a >> >DNS >> > name is produced by the former. I wonder if this restriction is >> >a >> >good >> > idea: Isn't the ability to use SRV records to locate more >> >generally >> > useful than this limited context? >> > >> > The answer to this may be no, but if so, the rationale for >> that >> >answer >> > should be part of the specification. >> > >> >(2) I don't see any provision for fallback to A records if SRV records >> > don't exist. I can easily see this being a Bad Idea, if so, >> >there >> > should be an explicit prohibition of it in the document along >> >with >> > some explanation of why it is a bad idea. >> > >> > >> > >> >------- >> >References should be split in normative and non-normative. >> >------- >> >I wonder about the reference to RFC1700, which has been obsoleted >> >by RFC3232, and that RFC actuallt talks about a DB that contains >> >the info. So How should this doc refer to that? >> >------- >> >Needs better abstract; doesn't even use the word "SRV". (and the rfc >> >editor will surely complain when they get it...) >> > >> >Might be good to use SRV in the title as well, as opposed to just >> >"DNS". But this I'm less concerned about, as there are two steps, and >> >only the second step is SRV records. >> > >> >E.g., maybe change: >> > >> > Discovering LDAP Services with DNS >> > >> >To something like: >> > >> > Discovering LDAP Services with DNS SRV Resource Records >> > >> >However, the rfc editor probably won't like the abbreviation >> >"SRV". Unfortunately, I don't think the acronym expands into anything >> >useful. >> >------- >> >I have three concerns here: >> > >> >(0) It isn't clear when this approach is supposed to be used. DNs are an >> > integral part of *every* LDAP operation. Is it the intent that an >> >LDAP >> > client check every DN it sees for DC fields and if it finds >> them use >> > this approach. Or is it only appropriate in specific situations? >> > >> >(1) This document specifies two things: How to translate a DN to a DNS >> > name and how to use a DNS name to locate a corresponding LDAP >> >server. >> > The document seems to imply that the latter is only used when a DNS >> > name is produced by the former. I wonder if this restriction is a >> >good >> > idea: Isn't the ability to use SRV records to locate more >> generally >> > useful than this limited context? >> > >> > The answer to this may be no, but if so, the rationale for that >> >answer >> > should be part of the specification. >> > >> >(2) I don't see any provision for fallback to A records if SRV records >> > don't exist. I can easily see this being a Bad Idea, if so, there >> > should be an explicit prohibition of it in the document along with >> > some explanation of why it is a bad idea. >> > >> > >> > >> > >> > >> >_______________________________________________ >> >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 >> >> >> 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 >> ======================================================================== >> The Open Group Conference >> Boundaryless Information Flow: The Role of Open Source >> Cannes, France, 14-18th October >> http://www.opengroup.org/cannes2002 >> ======================================================================== >> >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www1.ietf.org/mailman/listinfo/ldapext >> >> >> >> >> _________________________________________________________________ >> The information transmitted is intended only for the person or >> entity to which it is addressed and may contain confidential >> and/or privileged material. Any review, retransmission, >> dissemination or other use of, or taking of any action in >> reliance >> upon, this information by persons or entities other than the >> intended recipient is prohibited. If you received this in >> error, >> please contact the sender and delete the material from any >> computer. >> >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www1.ietf.org/mailman/listinfo/ldapext > > > > 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 > ======================================================================== > The Open Group Conference > Boundaryless Information Flow: The Role of Open Source > Cannes, France, 14-18th October > http://www.opengroup.org/cannes2002 > ======================================================================== > > > _______________________________________________ > 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 Tue Aug 27 17:25:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13314 for ; Tue, 27 Aug 2002 17:25:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RLPqo04402; Tue, 27 Aug 2002 17:25:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RJGfo28170 for ; Tue, 27 Aug 2002 15:16:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Date: Tue, 27 Aug 2002 14:44:44 -0400 Subject: [ldapext] Nomcom call for volunteers 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: , The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext