From mailman-admin@ietf.org Thu May 1 11:03:59 2003 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 LAA15652 for ; Thu, 1 May 2003 11:03:58 -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 h41FA3819552 for ; Thu, 1 May 2003 11:10:03 -0400 Date: Thu, 01 May 2003 11:10:03 -0400 Message-ID: <20030501151003.17986.35787.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ldapext-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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@www1.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%40lists.ietf.org From ldapext-admin@ietf.org Tue May 6 07:49:19 2003 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 HAA15622 for ; Tue, 6 May 2003 07:49:19 -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 h46BtV814735; Tue, 6 May 2003 07:55:31 -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 h46Bne814497 for ; Tue, 6 May 2003 07:49:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15092; Tue, 6 May 2003 07:40:41 -0400 (EDT) Message-Id: <200305061140.HAA15092@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 May 2003 07:40:41 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-t-f-05.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Absolute True and False Filters Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-t-f-05.txt Pages : 4 Date : 2003-5-5 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-05.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-05.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-05.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: <2003-5-5145720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-t-f-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-t-f-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-5145720.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 May 6 07:49:21 2003 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 HAA15636 for ; Tue, 6 May 2003 07:49:21 -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 h46BvW814829; Tue, 6 May 2003 07:57:32 -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 h46Bnj814501 for ; Tue, 6 May 2003 07:49:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15108; Tue, 6 May 2003 07:40:46 -0400 (EDT) Message-Id: <200305061140.HAA15108@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 May 2003 07:40:46 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-cancel-08.txt 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: , --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-08.txt Pages : 7 Date : 2003-5-5 This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation but like the X.511 Directory Access Protocol (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-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-zeilenga-ldap-cancel-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-zeilenga-ldap-cancel-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: <2003-5-5145732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-cancel-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-cancel-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-5145732.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 May 6 07:56:42 2003 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 HAA15966 for ; Tue, 6 May 2003 07:56: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 h46C4v815284; Tue, 6 May 2003 08:04:57 -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 h46BoO814543 for ; Tue, 6 May 2003 07:50:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15240; Tue, 6 May 2003 07:41:25 -0400 (EDT) Message-Id: <200305061141.HAA15240@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 May 2003 07:41:25 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-noop-01.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The LDAP No-Op Control Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-noop-01.txt Pages : 4 Date : 2003-5-5 This document defines the Lightweight Directory Access Protocol (LDAP) No-Op control which can be used to disable the normal effect of an operation. The control can be used to discover how a server might react to a particular update request without updating the directory. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-noop-01.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-noop-01.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-noop-01.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: <2003-5-5151105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-noop-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-noop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-5151105.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 May 6 08:27:30 2003 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 IAA17786 for ; Tue, 6 May 2003 08:27:29 -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 h46BqN814584; Tue, 6 May 2003 07:52:23 -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 h46Bn1814443 for ; Tue, 6 May 2003 07:49:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14932; Tue, 6 May 2003 07:40:02 -0400 (EDT) Message-Id: <200305061140.HAA14932@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 May 2003 07:40:02 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-grouping-06.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3: Grouping of Related Operations Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-grouping-06.txt Pages : 15 Date : 2003-5-5 This document provides a general mechanism for grouping related Lightweight Directory Access Protocol (LDAP) operations. Grouping of operations can be used to support replication, proxies, and transactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-grouping-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-grouping-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-grouping-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: <2003-5-5151528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-grouping-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-grouping-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-5151528.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 May 6 09:43:01 2003 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 JAA21147 for ; Tue, 6 May 2003 09:43:01 -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 h46Dou824321; Tue, 6 May 2003 09:50:57 -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 h46Dlj824211 for ; Tue, 6 May 2003 09:47:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21060; Tue, 6 May 2003 09:38:45 -0400 (EDT) Message-Id: <200305061338.JAA21060@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 May 2003 09:38:45 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-txn-06.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3 Transactions Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-txn-06.txt Pages : 7 Date : 2003-5-5 Lightweight Directory Access Protocol (LDAP) update operations acting upon entries have atomic, consistency, isolation, durability (ACID) properties. However, it is often desirable to update two or more entries as one unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning and information replication. This document defines an LDAP extension to support transactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-txn-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-txn-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-txn-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: <2003-5-5150945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-txn-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-txn-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-5150945.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 May 6 10:14:49 2003 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 KAA23405 for ; Tue, 6 May 2003 10:14:49 -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 h46EMx826856; Tue, 6 May 2003 10:22:59 -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 h46EKC826752 for ; Tue, 6 May 2003 10:20:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22930 for ; Tue, 6 May 2003 10:11:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D3C0-00078k-00 for ldapext@ietf.org; Tue, 06 May 2003 10:13:16 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19D3Bz-00078g-00 for ldapext@ietf.org; Tue, 06 May 2003 10:13:15 -0400 Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h46EE1c6009502 for ; Tue, 6 May 2003 14:14:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030506070118.02c19750@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 May 2003 07:11:32 -0700 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ldapext] LDAP Transactions 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: , I have revised my proposal for LDAP Transactions (draft-zeilenga-ldap-txn and draft-zeilenga-ldap-grouping) based upon IETF#56 discussions and believe that they are basically ready to progressed for publication. It's been suggested that Standard Track would be more appropriate than Experimental. Given that at least one vendor has implemented the proposal, I believe we now have enough operational experience to support a Standard Track recommendation. Hence, unless consensus is otherwise, I will recommend this work for the Standard Track. Additionally, based on off-list discussions, I believe it appropriate to return txnSpecifyOkay instead of success for operations specified as part of the transaction to avoid overloading success (or any other existing result code). Please review draft-zeilenga-ldap-txn and draft-zeilenga-ldap-grouping for suitability as Proposed Standards and post your comments before 21 May 2003. I intend to make a recommendation for publication by the end of the month. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 6 10:19:44 2003 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 KAA23721 for ; Tue, 6 May 2003 10:19:44 -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 h46ERt827152; Tue, 6 May 2003 10:27:55 -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 h46EPF826986 for ; Tue, 6 May 2003 10:25:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23606 for ; Tue, 6 May 2003 10:16:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D3Gt-0007D9-00 for ldapext@ietf.org; Tue, 06 May 2003 10:18:19 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19D3Gt-0007D6-00 for ldapext@ietf.org; Tue, 06 May 2003 10:18:19 -0400 Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h46EJ9c6009530 for ; Tue, 6 May 2003 14:19:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030506071238.02c3e8a8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 May 2003 07:16:39 -0700 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ldapext] draft-zeilenga-ldap-t-f-05 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: , I believe draft-zeilenga-ldap-t-f ready to be progressed to the IESG for consideration as a Proposed Standard. Please review and comment by 21 May 2003 as I intend to recommend publication of this work to the AD by the end of the month. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 6 10:21:43 2003 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 KAA23878 for ; Tue, 6 May 2003 10:21:43 -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 h46ETp827272; Tue, 6 May 2003 10:29:51 -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 h46ERY827138 for ; Tue, 6 May 2003 10:27:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23679 for ; Tue, 6 May 2003 10:18:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D3J8-0007EC-00 for ldapext@ietf.org; Tue, 06 May 2003 10:20:38 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19D3J7-0007E9-00 for ldapext@ietf.org; Tue, 06 May 2003 10:20:37 -0400 Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h46ELRc6009539 for ; Tue, 6 May 2003 14:21:28 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030506071722.02c532d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 May 2003 07:18:58 -0700 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ldapext] draft-zeilenga-ldap-noop-01.txt: ready to progress 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: , I believe draft-zeilenga-ldap-noop ready to be progressed to the IESG for consideration as a Proposed Standard. Please review and comment by 21 May 2003 as I intend to recommend publication of this work to the AD by the end of the month. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 6 14:43:52 2003 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 OAA02599 for ; Tue, 6 May 2003 14:43:52 -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 h46IqC817593; Tue, 6 May 2003 14:52:12 -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 h46Inf817481 for ; Tue, 6 May 2003 14:49:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02550 for ; Tue, 6 May 2003 14:40:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7Oi-0001Ih-00 for ldapext@ietf.org; Tue, 06 May 2003 14:42:40 -0400 Received: from smtp.avinci.de ([62.80.112.129]) by ietf-mx with esmtp (Exim 4.12) id 19D7Oh-0001IK-00 for ldapext@ietf.org; Tue, 06 May 2003 14:42:39 -0400 Received: from burgundy.dyndns.org (pD9520157.dip.t-dialin.net [217.82.1.87]) (authenticated bits=0) by smtp.avinci.de (8.12.7/8.12.7) with ESMTP id h46IgqDN002613 for ; Tue, 6 May 2003 20:42:55 +0200 Received: from localhost (localhost [127.0.0.1]) by burgundy.dyndns.org (Postfix) with ESMTP id DD513C2C1 for ; Tue, 6 May 2003 20:42:49 +0200 (CEST) Received: from [10.10.9.3] (trex.local [10.10.9.3]) by burgundy.dyndns.org (Postfix) with ESMTP id 783B7C25E for ; Tue, 6 May 2003 20:42:46 +0200 (CEST) Date: Tue, 06 May 2003 20:42:49 +0200 From: Norbert Klasen To: ldapext@ietf.org Message-ID: <94951432.1052253769@[10.10.9.3]> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12pre8 Content-Transfer-Encoding: 7bit Subject: [ldapext] I-D ACTION:draft-klasen-ldap-facs-tel-number-matching-00.txt 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 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3: matching rules for facsimile Telephone numbers Author(s) : N. Klasen Filename : draft-klasen-ldap-facs-tel-number-matching-00.txt Pages : 8 Date : 2003-5-5 This document defines an equality and substrings matching rule for the Facsimile Telephone Number syntax and updates the facsimileTelephoneNumber attribute type to use them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-klasen-ldap-facs-tel-number-match ing-00.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-klasen-ldap-facs-tel-number-matching-00.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-klasen-ldap-facs-tel-number-matching-00.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. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed May 7 07:22:39 2003 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 HAA24002 for ; Wed, 7 May 2003 07:22:39 -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 h47BVB805422; Wed, 7 May 2003 07:31:11 -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 h47BNv805057 for ; Wed, 7 May 2003 07:23:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23661; Wed, 7 May 2003 07:14:30 -0400 (EDT) Message-Id: <200305071114.HAA23661@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 May 2003 07:14:30 -0400 Subject: [ldapext] I-D ACTION:draft-apurva-ldap-query-containment-00.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Schema to Support Query Containment in LDAP Directories Author(s) : A. Kumar Filename : draft-apurva-ldap-query-containment-00.txt Pages : 23 Date : 2003-5-6 Lightweight Directory Access Protocol (LDAP) directories are being used at the backend of many internet and intranet web applications. LDAP servers that cache entries which are returned as search results for recently evaluated search requests, can use the semantic information associated with these requests, to answer subsequent search requests which are contained in them. This document describes LDAP schema for representing the semantic information and for supporting query containment of LDAP queries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-apurva-ldap-query-containment-00.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-apurva-ldap-query-containment-00.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-apurva-ldap-query-containment-00.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: <2003-5-6153314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-apurva-ldap-query-containment-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-apurva-ldap-query-containment-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-6153314.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon May 12 03:57:44 2003 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 DAA04667 for ; Mon, 12 May 2003 03:57:43 -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 h4C7MmB02366; Mon, 12 May 2003 03:22:48 -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 h4C7J7B02222 for ; Mon, 12 May 2003 03:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04646 for ; Mon, 12 May 2003 03:53:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19F89N-0005ti-00 for ldapext@ietf.org; Mon, 12 May 2003 03:55:09 -0400 Received: from moutng.kundenserver.de ([212.227.126.185]) by ietf-mx with esmtp (Exim 4.12) id 19F89M-0005te-00 for ldapext@ietf.org; Mon, 12 May 2003 03:55:08 -0400 Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19F8AI-0001Cz-00; Mon, 12 May 2003 09:56:06 +0200 Received: from [217.231.201.120] (helo=KeutelArbeit1) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 19F8AI-0000TP-00; Mon, 12 May 2003 09:56:06 +0200 From: "Jochen Keutel" To: "ldapext" , "ietf-ldapbis" Date: Mon, 12 May 2003 09:56:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4C7J7B02223 Subject: [ldapext] name form for inetOrgPerson with uid as naming attribute? 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 Hello, it's common practice to store objects of object class inetOrgPerson with uid as naming attribute in an LDAP directory. But - AFAIK - there is no name form allowing that; so LDAP servers which care about name forms (e.g. X.500 servers) reject this. It's quite boring to define this name form in each new directory project I have ... (and, additionally, it's always a new object identifier of the OID branch of the customer ...). Is it possible to define this name form in any of the LDAP standard documents? draft-zeilenga-ldap-user-schema-06.txt doesn't mention name forms. Neither do draft-ietf-ldapbis-user-schema-05.txt or RFC2798. Or is it outside the scope of LDAP to define name forms? Regards, Jochen Keutel. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon May 12 04:09:49 2003 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 EAA04877 for ; Mon, 12 May 2003 04:09:48 -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 h4C7YvB02907; Mon, 12 May 2003 03:34:57 -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 h4C7WbB02834 for ; Mon, 12 May 2003 03:32:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04856 for ; Mon, 12 May 2003 04:06:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19F8MR-0005wu-00 for ldapext@ietf.org; Mon, 12 May 2003 04:08:39 -0400 Received: from krl9-d9bb4eb6.pool.mediaways.net ([217.187.78.182] helo=nb2.stroeder.com) by ietf-mx with esmtp (Exim 4.12) id 19F8MQ-0005wn-00 for ldapext@ietf.org; Mon, 12 May 2003 04:08:38 -0400 Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id CB71910D6D; Mon, 12 May 2003 10:09:00 +0200 (CEST) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 09ABF10CF7; Mon, 12 May 2003 10:09:00 +0200 (CEST) Message-ID: <3EBF569B.5020500@stroeder.com> Date: Mon, 12 May 2003 10:08:59 +0200 From: =?ISO-8859-15?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jochen Keutel Cc: ldapext , ietf-ldapbis Subject: Re: [ldapext] name form for inetOrgPerson with uid as naming attribute? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 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 Jochen Keutel wrote: > it's common practice to store objects of object class > inetOrgPerson with uid as naming attribute in an LDAP directory. > But - AFAIK - there is no name form allowing that; so LDAP > servers which care about name forms (e.g. X.500 servers) reject this. > > It's quite boring to define this name form in each new directory > project I have ... (and, additionally, it's always a new > object identifier of the OID branch of the customer ...). > > Is it possible to define this name form in any of the LDAP > standard documents? IMHO it would be most appropriate to define a name form applicable for a certain object class in the document defining this object class. How about starting a new revision of RFC 2798, e.g. draft-[something]-ldap-RFC2798bis? BTW we could add other useful things needed by LDAP community... Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon May 12 09:55:01 2003 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 JAA12389 for ; Mon, 12 May 2003 09:55:01 -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 h4CDKAB28239; Mon, 12 May 2003 09:20:11 -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 h4CDHFB27987 for ; Mon, 12 May 2003 09:17:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12189 for ; Mon, 12 May 2003 09:51:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FDjq-0007nP-00 for ldapext@ietf.org; Mon, 12 May 2003 09:53:10 -0400 Received: from r2d2.aoltw.net ([64.236.137.26] helo=netscape.com) by ietf-mx with esmtp (Exim 4.12) id 19FDjp-0007n3-00 for ldapext@ietf.org; Mon, 12 May 2003 09:53:09 -0400 Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h4CDqOE14749 for ; Mon, 12 May 2003 06:52:24 -0700 (PDT) Received: from netscape.com ([10.169.192.48]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HES17F00.122; Mon, 12 May 2003 06:52:27 -0700 Message-ID: <3EBFA715.8090601@netscape.com> Date: Mon, 12 May 2003 09:52:21 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030428 Netscape/7.02+ X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= CC: Jochen Keutel , ldapext , ietf-ldapbis Subject: Re: [ldapext] name form for inetOrgPerson with uid as naming attribute? References: <3EBF569B.5020500@stroeder.com> In-Reply-To: <3EBF569B.5020500@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id h4CDqOE14749 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4CDHGB27988 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 Michael Ströder wrote: > > IMHO it would be most appropriate to define a name form applicable for a > certain object class in the document defining this object class. How > about starting a new revision of RFC 2798, e.g. > draft-[something]-ldap-RFC2798bis? > > BTW we could add other useful things needed by LDAP community... Years ago John Dale proposed two name forms for inclusion in the inetOrgPerson document but, at the time, it was too late to include them (debate had been going on long enough about the document and we were about to send it to the IESG). But revising 2798 seems like a good idea if there is sufficient interest. I'd be happy to take on the editing tasks again. For the record, here are the nameforms John proposed (I translated them to RFC 2252 syntax, so any syntax errors are mine): nameForms: ( 2.16.840.1.113678.640.7.8 NAME 'inetOrgPersonNameForm' OC inetOrgPerson MUST cn MAY ou ) nameForms: ( 2.16.840.1.113678.640.7.9 NAME 'inetOrgPersonNameForm' OC inetOrgPerson MUST uid MAY ( cn $ ou ) ) -Mark Smith Netscape _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 08:10:00 2003 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 IAA05863 for ; Tue, 13 May 2003 08:10:00 -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 h4DBZMB12694; Tue, 13 May 2003 07:35:22 -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 h4DBQLB12231 for ; Tue, 13 May 2003 07:26:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05183; Tue, 13 May 2003 07:59:50 -0400 (EDT) Message-Id: <200305131159.HAA05183@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, 13 May 2003 07:59:50 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-assert-00.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The LDAP Assertion Control Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-assert-00.txt Pages : 6 Date : 2003-5-12 This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control which allows a client to specify that a directory operation should only be processed if the assertion when applied to the target entry of the operation. It can be used to construct 'test and set' and 'test and clear' operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-assert-00.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-assert-00.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-assert-00.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: <2003-5-12152533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-assert-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-assert-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-12152533.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 May 13 08:11:34 2003 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 IAA05912 for ; Tue, 13 May 2003 08:11:34 -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 h4DBbIB13223; Tue, 13 May 2003 07:37:18 -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 h4DBQTB12239 for ; Tue, 13 May 2003 07:26:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05200; Tue, 13 May 2003 07:59:58 -0400 (EDT) Message-Id: <200305131159.HAA05200@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, 13 May 2003 07:59:57 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The LDAP entryUUID operational attribute Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-uuid-00.txt Pages : 7 Date : 2003-5-12 This document describes the LDAP/X.500 'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-uuid-00.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-uuid-00.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-uuid-00.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: <2003-5-12152543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-uuid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-uuid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-12152543.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 May 13 10:09:20 2003 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 KAA13355 for ; Tue, 13 May 2003 10:09:20 -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 h4DDYtB24736; Tue, 13 May 2003 09:34:55 -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 h4DDDuB23478 for ; Tue, 13 May 2003 09:13:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11970 for ; Tue, 13 May 2003 09:47:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fa9f-000456-00 for ldapext@ietf.org; Tue, 13 May 2003 09:49:19 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx with esmtp (Exim 4.12) id 19Fa9e-00044j-00 for ldapext@ietf.org; Tue, 13 May 2003 09:49:18 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4DDnrxr102452; Tue, 13 May 2003 09:49:53 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4DDnpQw156692; Tue, 13 May 2003 09:49:51 -0400 Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt To: ldapext@ietf.org, kurt@openldap.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Tue, 13 May 2003 08:49:49 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0.1CF1|March 04, 2003 =?GB2312?B?q6E/KSBhdCAwNS8xMy8yMDAzIDA4OjQ5OjUx?= MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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: , 2.3 'uuidOrderingMatch' Matching Rule Why do you define an ordering matching rule for UUIDs? John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 12:05:43 2003 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 MAA18315 for ; Tue, 13 May 2003 12:05:43 -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 h4DFVJB03518; Tue, 13 May 2003 11:31:19 -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 h4DFQ5B03123 for ; Tue, 13 May 2003 11:26:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17972 for ; Tue, 13 May 2003 11:59:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FcDW-0005NB-00 for ldapext@ietf.org; Tue, 13 May 2003 12:01:26 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19FcDV-0005N8-00 for ldapext@ietf.org; Tue, 13 May 2003 12:01:25 -0400 Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4DG1pc6079732; Tue, 13 May 2003 16:02:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030513085311.02a47980@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 13 May 2003 08:58:52 -0700 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt Cc: ldapext@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 06:49 AM 5/13/2003, John McMeeking wrote: >2.3 'uuidOrderingMatch' Matching Rule > >Why do you define an ordering matching rule for UUIDs? For completeness. UUID ordering was discussed in the DCE UUID specification. I wonder though if the ordering applies to non-DCE UUID forms allowed by my draft (I need to buy a copy of the ISO specification) and, even if so, whether a DSA can be reasonably expected to commit objects in UUID order. Anyways, I wanted some discussion before deciding whether or not to support UUID ordering matching here and that's easier to do with a specification for it. So, I ask, should UUID ordering support stay or be removed from this I-D? Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 12:54:00 2003 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 MAA19910 for ; Tue, 13 May 2003 12:54:00 -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 h4DGJcB08383; Tue, 13 May 2003 12:19:38 -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 h4DG55B06476 for ; Tue, 13 May 2003 12:05:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19487 for ; Tue, 13 May 2003 12:38:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FcpF-0005mD-00 for ldapext@ietf.org; Tue, 13 May 2003 12:40:25 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 19FcpE-0005m0-00 for ldapext@ietf.org; Tue, 13 May 2003 12:40:24 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4DGextd172020; Tue, 13 May 2003 12:40:59 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4DGevxT197480; Tue, 13 May 2003 12:40:57 -0400 Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt To: "Kurt D. Zeilenga" Cc: ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Tue, 13 May 2003 11:40:56 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0.1CF1|March 04, 2003 =?GB2312?B?q6E/KSBhdCAwNS8xMy8yMDAzIDExOjQwOjU4?= MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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: , I don't have a copy of the spec handy. An Internet Draft that Paul Leach wrote (I found a copy at http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt) is probably close enough for addressing this question. The DCE UUID spec allows for various algorithms for generating UUIDs, reflected by a set of variant/version bits in the UUID. Four variants are identified in the draft. One variant includes a timestamp, another uses random numbers, and I believe another uses a hash of the timestamp and adapter address to prevent folks from determining if UUIDs come from the same machine. The timestamp variant puts the bytes of the timestamp in reverse order -- "lo" bytes, "mid" bytes, then "hi" bytes. So ordering even within that variant probably doesn't make sense, and the fact that there are multiple variants suggests that ordering in general is not meaningful. John McMeeking "Kurt D. Zeilenga" To: John McMeeking/Rochester/IBM@IBMUS Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt 05/13/2003 10:58 AM At 06:49 AM 5/13/2003, John McMeeking wrote: >2.3 'uuidOrderingMatch' Matching Rule > >Why do you define an ordering matching rule for UUIDs? For completeness. UUID ordering was discussed in the DCE UUID specification. I wonder though if the ordering applies to non-DCE UUID forms allowed by my draft (I need to buy a copy of the ISO specification) and, even if so, whether a DSA can be reasonably expected to commit objects in UUID order. Anyways, I wanted some discussion before deciding whether or not to support UUID ordering matching here and that's easier to do with a specification for it. So, I ask, should UUID ordering support stay or be removed from this I-D? Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 13:01:55 2003 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 NAA20246 for ; Tue, 13 May 2003 13:01:55 -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 h4DGRnB08928; Tue, 13 May 2003 12:27:49 -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 h4DGKVB08459 for ; Tue, 13 May 2003 12:20:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19908 for ; Tue, 13 May 2003 12:53:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fd4B-0005t5-00 for ldapext@ietf.org; Tue, 13 May 2003 12:55:51 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Fd49-0005sx-00 for ldapext@ietf.org; Tue, 13 May 2003 12:55:50 -0400 Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4DGuic6080506; Tue, 13 May 2003 16:56:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030513095226.02a9bc40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 13 May 2003 09:53:55 -0700 To: John McMeeking From: "Kurt D. Zeilenga" Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt Cc: ldapext@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , I concur that this is a strong argument that the ordering matching rule should be removed from the draft. Does anyone have any counter arguments they would like to make? Kurt At 09:40 AM 5/13/2003, John McMeeking wrote: >I don't have a copy of the spec handy. An Internet Draft that Paul Leach >wrote (I found a copy at >http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt) > is probably close enough for addressing this question. > >The DCE UUID spec allows for various algorithms for generating UUIDs, >reflected by a set of variant/version bits in the UUID. Four variants are >identified in the draft. One variant includes a timestamp, another uses >random numbers, and I believe another uses a hash of the timestamp and >adapter address to prevent folks from determining if UUIDs come from the >same machine. The timestamp variant puts the bytes of the timestamp in >reverse order -- "lo" bytes, "mid" bytes, then "hi" bytes. So ordering >even within that variant probably doesn't make sense, and the fact that >there are multiple variants suggests that ordering in general is not >meaningful. > > >John McMeeking > > > > > "Kurt D. > Zeilenga" To: John McMeeking/Rochester/IBM@IBMUS > g> Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt > > 05/13/2003 10:58 > AM > > > > > > >At 06:49 AM 5/13/2003, John McMeeking wrote: >>2.3 'uuidOrderingMatch' Matching Rule >> >>Why do you define an ordering matching rule for UUIDs? > >For completeness. UUID ordering was discussed in the DCE >UUID specification. > >I wonder though if the ordering applies to non-DCE UUID >forms allowed by my draft (I need to buy a copy of the ISO >specification) and, even if so, whether a DSA can be >reasonably expected to commit objects in UUID order. > >Anyways, I wanted some discussion before deciding whether >or not to support UUID ordering matching here and that's >easier to do with a specification for it. > >So, I ask, should UUID ordering support stay or be removed >from this I-D? > >Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 13:04:01 2003 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 NAA20348 for ; Tue, 13 May 2003 13:04:01 -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 h4DGTlB09154; Tue, 13 May 2003 12:29:47 -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 h4DGRoB08936 for ; Tue, 13 May 2003 12:27:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20135 for ; Tue, 13 May 2003 13:01:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FdBF-0005xj-00 for ldapext@ietf.org; Tue, 13 May 2003 13:03:09 -0400 Received: from wstutil12b-v.ml.com ([209.65.19.70] helo=wstutil12b.ml.com) by ietf-mx with esmtp (Exim 4.12) id 19FdBE-0005xf-00 for ldapext@ietf.org; Tue, 13 May 2003 13:03:08 -0400 Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by wstutil12b.ml.com (8.12.9/8.12.5/wstutil12a-1.2) with ESMTP id h4DH4MEs024649; Tue, 13 May 2003 13:04:22 -0400 (EDT) Received: from ehudwt01.exchange.ml.com (ehudwt01.exchange.ml.com [199.201.37.22]) by telutil13a.ml.com (8.12.9/8.12.5/telutil13a-1.1) with SMTP id h4DH4MxQ005738; Tue, 13 May 2003 13:04:22 -0400 (EDT) Received: from 172.25.100.10 by ehudwt01.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 13 May 2003 13:04:13 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: by ewst10.exchange.ml.com with Internet Mail Service ( 5.5.2654.52) id ; Tue, 13 May 2003 13:04:13 -0400 Message-ID: <9BBE844AB2A8D511B57C00B0D049FD0C0711C374@ehope13.hew.us.ml.com> From: "Liben, Michael (IDS EaCS SvcMgmt)" To: "'Kurt D. Zeilenga'" , "John McMeeking" cc: ldapext@ietf.org Subject: RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt Date: Tue, 13 May 2003 13:04:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) X-WSS-ID: 12DFFA07349450-01-01 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-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 My vote is to remove. I can't conceive of a valid reason to order UUIDs. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, May 13, 2003 11:59 AM To: John McMeeking Cc: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt At 06:49 AM 5/13/2003, John McMeeking wrote: >2.3 'uuidOrderingMatch' Matching Rule > >Why do you define an ordering matching rule for UUIDs? For completeness. UUID ordering was discussed in the DCE UUID specification. I wonder though if the ordering applies to non-DCE UUID forms allowed by my draft (I need to buy a copy of the ISO specification) and, even if so, whether a DSA can be reasonably expected to commit objects in UUID order. Anyways, I wanted some discussion before deciding whether or not to support UUID ordering matching here and that's easier to do with a specification for it. So, I ask, should UUID ordering support stay or be removed from this I-D? Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 13:21:09 2003 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 NAA20991 for ; Tue, 13 May 2003 13:21:09 -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 h4DGl0B11204; Tue, 13 May 2003 12:47:00 -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 h4DGiqB11061 for ; Tue, 13 May 2003 12:44:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20823 for ; Tue, 13 May 2003 13:18:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FdRj-00066y-00 for ldapext@ietf.org; Tue, 13 May 2003 13:20:11 -0400 Received: from tempo.update.uu.se ([130.238.19.17]) by ietf-mx with esmtp (Exim 4.12) id 19FdRi-00066v-00 for ldapext@ietf.org; Tue, 13 May 2003 13:20:11 -0400 Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.8/8.12.8/Update-Iltempogigante) with ESMTP id h4DHLCvJ031496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 May 2003 19:21:12 +0200 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.8/8.12.8/Update-Iltempogigante-submit) id h4DHLCxv031493; Tue, 13 May 2003 19:21:12 +0200 X-Authentication-Warning: Tempo.Update.UU.SE: thorild set sender to thorild@Update.UU.SE using -f From: Thorild Selen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16065.10632.193105.605784@Tempo.Update.UU.SE> Date: Tue, 13 May 2003 19:21:12 +0200 To: ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt In-Reply-To: <5.2.0.9.0.20030513085311.02a47980@127.0.0.1> References: <5.2.0.9.0.20030513085311.02a47980@127.0.0.1> X-Mailer: VM 7.14 under Emacs 20.7.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4DGiqB11062 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 One possible use (if server side sorting is supported): Please give me all entries matching filter foo in subtree bar etc., please sort by UUID. Here you are: ... (Client looses connection with server after just having received entry baz. Client connects again, possibly to another server.) Please give me... etc., where UUID > baz, please sort by UUID. So the client doesn't have to see all those entries that it has already seen again, and will not again get an entry that it has already seen (even if entries are renamed during or between the searches). Generally, it's probably not worth it, but by supplying an ordering you make this an option for developers of LDAP clients, instead of deciding in advance that "you won't need this". Thorild Selén Datorföreningen Update / Update Computer Club, Uppsala, SE _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 13:37:59 2003 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 NAA21545 for ; Tue, 13 May 2003 13:37:59 -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 h4DH3pB12090; Tue, 13 May 2003 13:03:51 -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 h4DGoAB11371 for ; Tue, 13 May 2003 12:50:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21089 for ; Tue, 13 May 2003 13:23:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FdWr-00069Q-00 for ldapext@ietf.org; Tue, 13 May 2003 13:25:29 -0400 Received: from pheriche.sun.com ([192.18.98.34] helo=brmea-mail-3.sun.com) by ietf-mx with esmtp (Exim 4.12) id 19FdWq-00069N-00 for ldapext@ietf.org; Tue, 13 May 2003 13:25:28 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4DHQXRh012828; Tue, 13 May 2003 11:26:33 -0600 (MDT) Received: from Sun.com (bondi [129.157.192.47]) by odin.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h4DHQWX21952; Tue, 13 May 2003 19:26:32 +0200 (MEST) Message-ID: <3EC12AC8.9090901@Sun.com> Date: Tue, 13 May 2003 19:26:32 +0200 From: Ludovic Poitou Organization: Sun Microsystems Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: John McMeeking , ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt References: <5.2.0.9.0.20030513095226.02a9bc40@127.0.0.1> 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 Kurt D. Zeilenga wrote: >I concur that this is a strong argument that the ordering matching >rule should be removed from the draft. Does anyone have any >counter arguments they would like to make? > > No.. Please remove the ordering matching rule. Ludovic. >Kurt > >At 09:40 AM 5/13/2003, John McMeeking wrote: > > > > > > >>I don't have a copy of the spec handy. An Internet Draft that Paul Leach >>wrote (I found a copy at >>http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt) >>is probably close enough for addressing this question. >> >>The DCE UUID spec allows for various algorithms for generating UUIDs, >>reflected by a set of variant/version bits in the UUID. Four variants are >>identified in the draft. One variant includes a timestamp, another uses >>random numbers, and I believe another uses a hash of the timestamp and >>adapter address to prevent folks from determining if UUIDs come from the >>same machine. The timestamp variant puts the bytes of the timestamp in >>reverse order -- "lo" bytes, "mid" bytes, then "hi" bytes. So ordering >>even within that variant probably doesn't make sense, and the fact that >>there are multiple variants suggests that ordering in general is not >>meaningful. >> >> >>John McMeeking >> >> >> >> >> "Kurt D. >> Zeilenga" To: John McMeeking/Rochester/IBM@IBMUS >> > g> Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt >> >> 05/13/2003 10:58 >> AM >> >> >> >> >> >> >>At 06:49 AM 5/13/2003, John McMeeking wrote: >> >> >>>2.3 'uuidOrderingMatch' Matching Rule >>> >>>Why do you define an ordering matching rule for UUIDs? >>> >>> >>For completeness. UUID ordering was discussed in the DCE >>UUID specification. >> >>I wonder though if the ordering applies to non-DCE UUID >>forms allowed by my draft (I need to buy a copy of the ISO >>specification) and, even if so, whether a DSA can be >>reasonably expected to commit objects in UUID order. >> >>Anyways, I wanted some discussion before deciding whether >>or not to support UUID ordering matching here and that's >>easier to do with a specification for it. >> >>So, I ask, should UUID ordering support stay or be removed >> >> >>from this I-D? > > >>Kurt >> >> > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Sun Microsystems Inc. Sun ONE products - Directory Server Group - Grenoble - France _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 20:18:33 2003 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 UAA04860 for ; Tue, 13 May 2003 20:18:33 -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 h4DNiKB10526; Tue, 13 May 2003 19:44:20 -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 h4DNfwB10454 for ; Tue, 13 May 2003 19:41:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04811 for ; Tue, 13 May 2003 20:15:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FjxE-00010D-00 for ldapext@ietf.org; Tue, 13 May 2003 20:17:08 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 19FjxC-000102-00 for ldapext@ietf.org; Tue, 13 May 2003 20:17:07 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with MailMarshal (v5,0,3,91) id ; Wed, 14 May 2003 10:15:29 +1000 Received: (qmail 15483 invoked from network); 14 May 2003 00:17:40 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 14 May 2003 00:17:40 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" , "'John McMeeking'" Cc: Subject: RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt Date: Wed, 14 May 2003 10:17:39 +1000 Message-ID: <003501c319ae$3b2c51b0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <5.2.0.9.0.20030513095226.02a9bc40@127.0.0.1> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kurt, Kurt D. Zeilenga wrote: > I concur that this is a strong argument that the ordering matching > rule should be removed from the draft. Does anyone have any > counter arguments they would like to make? There is value in having an ordering relationship defined, even if it is completely arbitrary, just so that sorting and less-than and greater-than filter items are well-defined. A client can always impose a different ordering relationship by using an extensible match. Also, why are you defining new matching rules that are exactly the same as octetStringMatch and octetStringOrderingMatch ? Sections 5.1 and 5.2.19 of draft-ietf-ldapbis-syntaxes-05.txt allow octetStringMatch to be applied to the UUID syntax. By implication, so can octetStringOrderingMatch. Regards, Steven > > Kurt > > At 09:40 AM 5/13/2003, John McMeeking wrote: > > > > > >I don't have a copy of the spec handy. An Internet Draft > that Paul Leach > >wrote (I found a copy at > >http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/d > raft-l/draft-leach-uuids-guids-01.txt) > > is probably close enough for addressing this question. > > > >The DCE UUID spec allows for various algorithms for generating UUIDs, > >reflected by a set of variant/version bits in the UUID. > Four variants are > >identified in the draft. One variant includes a timestamp, > another uses > >random numbers, and I believe another uses a hash of the > timestamp and > >adapter address to prevent folks from determining if UUIDs > come from the > >same machine. The timestamp variant puts the bytes of the > timestamp in > >reverse order -- "lo" bytes, "mid" bytes, then "hi" bytes. > So ordering > >even within that variant probably doesn't make sense, and > the fact that > >there are multiple variants suggests that ordering in general is not > >meaningful. > > > > > >John McMeeking > > > > > > > > > > > "Kurt D. > > > Zeilenga" To: > John McMeeking/Rochester/IBM@IBMUS > > > ldapext@ietf.org > > > g> Subject: Re: > [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt > > > > > 05/13/2003 10:58 > > > AM > > > > > > > > > > > > > > > > >At 06:49 AM 5/13/2003, John McMeeking wrote: > >>2.3 'uuidOrderingMatch' Matching Rule > >> > >>Why do you define an ordering matching rule for UUIDs? > > > >For completeness. UUID ordering was discussed in the DCE > >UUID specification. > > > >I wonder though if the ordering applies to non-DCE UUID > >forms allowed by my draft (I need to buy a copy of the ISO > >specification) and, even if so, whether a DSA can be > >reasonably expected to commit objects in UUID order. > > > >Anyways, I wanted some discussion before deciding whether > >or not to support UUID ordering matching here and that's > >easier to do with a specification for it. > > > >So, I ask, should UUID ordering support stay or be removed > >from this I-D? > > > >Kurt > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 20:45:48 2003 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 UAA05412 for ; Tue, 13 May 2003 20:45:48 -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 h4E0BnB12570; Tue, 13 May 2003 20:11:49 -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 h4E09eB12494 for ; Tue, 13 May 2003 20:09:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05380 for ; Tue, 13 May 2003 20:42:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FkO1-00017q-00 for ldapext@ietf.org; Tue, 13 May 2003 20:44:49 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19FkO0-00017n-00 for ldapext@ietf.org; Tue, 13 May 2003 20:44:48 -0400 Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4E0jjc6084588; Wed, 14 May 2003 00:45:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030513172027.0276cb70@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 13 May 2003 17:43:08 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt Cc: "'John McMeeking'" , In-Reply-To: <003501c319ae$3b2c51b0$a518200a@osmium.mtwav.adacel.com.au> References: <5.2.0.9.0.20030513095226.02a9bc40@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-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 05:17 PM 5/13/2003, Steven Legg wrote: >Kurt D. Zeilenga wrote: >> I concur that this is a strong argument that the ordering matching >> rule should be removed from the draft. Does anyone have any >> counter arguments they would like to make? > >There is value in having an ordering relationship defined, even if it >is completely arbitrary, just so that sorting and less-than and >greater-than filter items are well-defined. A client can always impose >a different ordering relationship by using an extensible match. Noted. >Also, why are you defining new matching rules that are exactly the same >as octetStringMatch and octetStringOrderingMatch ? Because UUID syntax has its own LDAP-specific string encoding. >Sections 5.1 and 5.2.19 >of draft-ietf-ldapbis-syntaxes-05.txt allow octetStringMatch to be applied >to the UUID syntax. By implication, so can octetStringOrderingMatch. I think not. The UUID syntax differs from other OCTET STRING derived syntaxes, such as JPEG, in that it has a different LDAP-specific string encoding than that prescribed for OCTET STRINGs. That is, the octets of the UUID are not transferred "unconverted" like an OCTET STRING, converted to a string representation for transfer. >Regards, >Steven > >> >> Kurt >> >> At 09:40 AM 5/13/2003, John McMeeking wrote: >> >> >> >> >> >I don't have a copy of the spec handy. An Internet Draft >> that Paul Leach >> >wrote (I found a copy at >> >http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/d >> raft-l/draft-leach-uuids-guids-01.txt) >> > is probably close enough for addressing this question. >> > >> >The DCE UUID spec allows for various algorithms for generating UUIDs, >> >reflected by a set of variant/version bits in the UUID. >> Four variants are >> >identified in the draft. One variant includes a timestamp, >> another uses >> >random numbers, and I believe another uses a hash of the >> timestamp and >> >adapter address to prevent folks from determining if UUIDs >> come from the >> >same machine. The timestamp variant puts the bytes of the >> timestamp in >> >reverse order -- "lo" bytes, "mid" bytes, then "hi" bytes. >> So ordering >> >even within that variant probably doesn't make sense, and >> the fact that >> >there are multiple variants suggests that ordering in general is not >> >meaningful. >> > >> > >> >John McMeeking >> > >> > >> > >> > >> >> > "Kurt D. >> >> > Zeilenga" To: >> John McMeeking/Rochester/IBM@IBMUS >> >> > > ldapext@ietf.org >> >> > g> Subject: Re: >> [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt >> > >> >> > 05/13/2003 10:58 >> >> > AM >> >> > >> >> > >> >> > >> > >> > >> > >> >At 06:49 AM 5/13/2003, John McMeeking wrote: >> >>2.3 'uuidOrderingMatch' Matching Rule >> >> >> >>Why do you define an ordering matching rule for UUIDs? >> > >> >For completeness. UUID ordering was discussed in the DCE >> >UUID specification. >> > >> >I wonder though if the ordering applies to non-DCE UUID >> >forms allowed by my draft (I need to buy a copy of the ISO >> >specification) and, even if so, whether a DSA can be >> >reasonably expected to commit objects in UUID order. >> > >> >Anyways, I wanted some discussion before deciding whether >> >or not to support UUID ordering matching here and that's >> >easier to do with a specification for it. >> > >> >So, I ask, should UUID ordering support stay or be removed >> >from this I-D? >> > >> >Kurt >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www1.ietf.org/mailman/listinfo/ldapext >> _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 22:19:50 2003 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 WAA07379 for ; Tue, 13 May 2003 22:19:49 -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 h4E1jsB19389; Tue, 13 May 2003 21:45:54 -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 h4E1gxB19309 for ; Tue, 13 May 2003 21:42:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07313 for ; Tue, 13 May 2003 22:16:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FlqJ-0001i4-00 for ldapext@ietf.org; Tue, 13 May 2003 22:18:07 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 19FlqH-0001hs-00 for ldapext@ietf.org; Tue, 13 May 2003 22:18:06 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with MailMarshal (v5,0,3,91) id ; Wed, 14 May 2003 12:16:23 +1000 Received: (qmail 3760 invoked from network); 14 May 2003 02:18:35 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 14 May 2003 02:18:35 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt Date: Wed, 14 May 2003 12:18:33 +1000 Message-ID: <003901c319bf$1ec041b0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <5.2.0.9.0.20030513172027.0276cb70@127.0.0.1> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kurt, Kurt D. Zeilenga wrote: > At 05:17 PM 5/13/2003, Steven Legg wrote: > >Also, why are you defining new matching rules that are > exactly the same > >as octetStringMatch and octetStringOrderingMatch ? > > Because UUID syntax has its own LDAP-specific string encoding. Doesn't matter. Matching rules operate on the abstract value, not any particular encoding of the abstract value. > >Sections 5.1 and 5.2.19 > >of draft-ietf-ldapbis-syntaxes-05.txt allow octetStringMatch > to be applied > >to the UUID syntax. By implication, so can octetStringOrderingMatch. > > I think not. The UUID syntax differs from other OCTET STRING > derived syntaxes, such as JPEG, in that it has a different > LDAP-specific string encoding than that prescribed for OCTET > STRINGs. Doesn't matter. The underlying data type is still OCTET STRING, and as far as X.500 is concerned, they are all eligible to be matched by octetStringMatch. > That is, the octets of the UUID are not transferred > "unconverted" like an OCTET STRING, converted to a string > representation for transfer. An OCTET STRING is transfered differently depending on whether it is BER, GSER or XER encoded, but that doesn't preclude matching with octetStringMatch. A difference in encoding based on which LDAP syntax the OCTET STRING belongs to is equally unimportant for matching purposes. You've defined uuidMatch to be semantically the same as octetStringMatch so they must be interchangeable, by definition. If you think octetStringMatch is inadequate then the current definition of uuidMatch must also be inadequate. If you mean for the matching to be on the ISO 11578 string representation then you should be using a character string type for the syntax, not OCTET STRING. Regards, Steven > > > > > >Regards, > >Steven > > > >> > >> Kurt > >> > >> At 09:40 AM 5/13/2003, John McMeeking wrote: > >> > >> > >> > >> > >> >I don't have a copy of the spec handy. An Internet Draft > >> that Paul Leach > >> >wrote (I found a copy at > >> >http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/d > >> raft-l/draft-leach-uuids-guids-01.txt) > >> > is probably close enough for addressing this question. > >> > > >> >The DCE UUID spec allows for various algorithms for > generating UUIDs, > >> >reflected by a set of variant/version bits in the UUID. > >> Four variants are > >> >identified in the draft. One variant includes a timestamp, > >> another uses > >> >random numbers, and I believe another uses a hash of the > >> timestamp and > >> >adapter address to prevent folks from determining if UUIDs > >> come from the > >> >same machine. The timestamp variant puts the bytes of the > >> timestamp in > >> >reverse order -- "lo" bytes, "mid" bytes, then "hi" bytes. > >> So ordering > >> >even within that variant probably doesn't make sense, and > >> the fact that > >> >there are multiple variants suggests that ordering in > general is not > >> >meaningful. > >> > > >> > > >> >John McMeeking > >> > > >> > > >> > > >> > > >> > > >> > "Kurt D. > >> > > >> > Zeilenga" To: > >> John McMeeking/Rochester/IBM@IBMUS > >> > >> > >> ldapext@ietf.org > >> > >> > g> Subject: Re: > >> [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt > > >> > > >> > > >> > 05/13/2003 10:58 > >> > > >> > AM > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> >At 06:49 AM 5/13/2003, John McMeeking wrote: > >> >>2.3 'uuidOrderingMatch' Matching Rule > >> >> > >> >>Why do you define an ordering matching rule for UUIDs? > >> > > >> >For completeness. UUID ordering was discussed in the DCE > >> >UUID specification. > >> > > >> >I wonder though if the ordering applies to non-DCE UUID > >> >forms allowed by my draft (I need to buy a copy of the ISO > >> >specification) and, even if so, whether a DSA can be > >> >reasonably expected to commit objects in UUID order. > >> > > >> >Anyways, I wanted some discussion before deciding whether > >> >or not to support UUID ordering matching here and that's > >> >easier to do with a specification for it. > >> > > >> >So, I ask, should UUID ordering support stay or be removed > >> >from this I-D? > >> > > >> >Kurt > >> > >> _______________________________________________ > >> Ldapext mailing list > >> Ldapext@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ldapext > >> > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 22:37:57 2003 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 WAA07637 for ; Tue, 13 May 2003 22:37:57 -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 h4E242B20147; Tue, 13 May 2003 22:04:02 -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 h4E20vB20013 for ; Tue, 13 May 2003 22:01:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07600 for ; Tue, 13 May 2003 22:34:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fm7e-0001mZ-00 for ldapext@ietf.org; Tue, 13 May 2003 22:36:02 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Fm7c-0001mW-00 for ldapext@ietf.org; Tue, 13 May 2003 22:36:01 -0400 Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4E2axc6085308; Wed, 14 May 2003 02:36:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030513193109.02759a80@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 13 May 2003 19:34:22 -0700 To: From: "Kurt D. Zeilenga" Subject: RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt Cc: In-Reply-To: <003901c319bf$1ec041b0$a518200a@osmium.mtwav.adacel.com.au> References: <5.2.0.9.0.20030513172027.0276cb70@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-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , At 07:18 PM 5/13/2003, Steven Legg wrote: >Kurt D. Zeilenga wrote: >> At 05:17 PM 5/13/2003, Steven Legg wrote: >> >Also, why are you defining new matching rules that are >> exactly the same >> >as octetStringMatch and octetStringOrderingMatch ? >> >> Because UUID syntax has its own LDAP-specific string encoding. > >Doesn't matter. Matching rules operate on the abstract value, >not any particular encoding of the abstract value. While true, the OID of the matching rule identifies both the abstract type AND the LDAP string encoding to use. >> >Sections 5.1 and 5.2.19 >> >of draft-ietf-ldapbis-syntaxes-05.txt allow octetStringMatch >> to be applied >> >to the UUID syntax. By implication, so can octetStringOrderingMatch. >> >> I think not. The UUID syntax differs from other OCTET STRING >> derived syntaxes, such as JPEG, in that it has a different >> LDAP-specific string encoding than that prescribed for OCTET >> STRINGs. > >Doesn't matter. The underlying data type is still OCTET STRING, >and as far as X.500 is concerned, they are all eligible to be >matched by octetStringMatch. Problem is with LDAP. >> That is, the octets of the UUID are not transferred >> "unconverted" like an OCTET STRING, converted to a string >> representation for transfer. > >An OCTET STRING is transfered differently depending on whether >it is BER, GSER or XER encoded, but that doesn't preclude matching >with octetStringMatch. A difference in encoding based on which >LDAP syntax the OCTET STRING belongs to is equally unimportant >for matching purposes. > >You've defined uuidMatch to be semantically the same as octetStringMatch >so they must be interchangeable, by definition. If you think >octetStringMatch >is inadequate then the current definition of uuidMatch must also be >inadequate. >If you mean for the matching to be on the ISO 11578 string representation >then you should be using a character string type for the syntax, >not OCTET STRING. > >Regards, >Steven > >> >> >> >> >> >Regards, >> >Steven >> > >> >> >> >> Kurt >> >> >> >> At 09:40 AM 5/13/2003, John McMeeking wrote: >> >> >> >> >> >> >> >> >> >> >I don't have a copy of the spec handy. An Internet Draft >> >> that Paul Leach >> >> >wrote (I found a copy at >> >> >http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/d >> >> raft-l/draft-leach-uuids-guids-01.txt) >> >> > is probably close enough for addressing this question. >> >> > >> >> >The DCE UUID spec allows for various algorithms for >> generating UUIDs, >> >> >reflected by a set of variant/version bits in the UUID. >> >> Four variants are >> >> >identified in the draft. One variant includes a timestamp, >> >> another uses >> >> >random numbers, and I believe another uses a hash of the >> >> timestamp and >> >> >adapter address to prevent folks from determining if UUIDs >> >> come from the >> >> >same machine. The timestamp variant puts the bytes of the >> >> timestamp in >> >> >reverse order -- "lo" bytes, "mid" bytes, then "hi" bytes. >> >> So ordering >> >> >even within that variant probably doesn't make sense, and >> >> the fact that >> >> >there are multiple variants suggests that ordering in >> general is not >> >> >meaningful. >> >> > >> >> > >> >> >John McMeeking >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> > "Kurt D. >> >> >> >> >> > Zeilenga" To: >> >> John McMeeking/Rochester/IBM@IBMUS >> >> >> >> > > >> ldapext@ietf.org >> >> >> >> > g> Subject: Re: >> >> [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt >> >> >> > >> >> >> >> >> > 05/13/2003 10:58 >> >> >> >> >> > AM >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> >At 06:49 AM 5/13/2003, John McMeeking wrote: >> >> >>2.3 'uuidOrderingMatch' Matching Rule >> >> >> >> >> >>Why do you define an ordering matching rule for UUIDs? >> >> > >> >> >For completeness. UUID ordering was discussed in the DCE >> >> >UUID specification. >> >> > >> >> >I wonder though if the ordering applies to non-DCE UUID >> >> >forms allowed by my draft (I need to buy a copy of the ISO >> >> >specification) and, even if so, whether a DSA can be >> >> >reasonably expected to commit objects in UUID order. >> >> > >> >> >Anyways, I wanted some discussion before deciding whether >> >> >or not to support UUID ordering matching here and that's >> >> >easier to do with a specification for it. >> >> > >> >> >So, I ask, should UUID ordering support stay or be removed >> >> >from this I-D? >> >> > >> >> >Kurt >> >> >> >> _______________________________________________ >> >> Ldapext mailing list >> >> Ldapext@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/ldapext >> >> >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www1.ietf.org/mailman/listinfo/ldapext >> > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 23:16:43 2003 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 XAA08204 for ; Tue, 13 May 2003 23:16:43 -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 h4E2gqB23307; Tue, 13 May 2003 22:42: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 h4E2e2B23233 for ; Tue, 13 May 2003 22:40:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08157 for ; Tue, 13 May 2003 23:13:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FmjU-0001xC-00 for ldapext@ietf.org; Tue, 13 May 2003 23:15:08 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 19FmjT-0001x9-00 for ldapext@ietf.org; Tue, 13 May 2003 23:15:08 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with MailMarshal (v5,0,3,91) id ; Wed, 14 May 2003 13:13:30 +1000 Received: (qmail 12665 invoked from network); 14 May 2003 03:15:42 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 14 May 2003 03:15:42 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt Date: Wed, 14 May 2003 13:15:40 +1000 Message-ID: <003f01c319c7$19dc4c40$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <5.2.0.9.0.20030513193109.02759a80@127.0.0.1> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kurt, Kurt D. Zeilenga > >Doesn't matter. Matching rules operate on the abstract value, > >not any particular encoding of the abstract value. > > While true, the OID of the matching rule identifies both > the abstract type AND the LDAP string encoding to use. ... for the assertion value. Yes, okay, fair point. Regards, Steven _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 13 23:49:16 2003 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 XAA08621 for ; Tue, 13 May 2003 23:49:15 -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 h4E3EtB25126; Tue, 13 May 2003 23:14:55 -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 h4E3CIB25066 for ; Tue, 13 May 2003 23:12:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08575 for ; Tue, 13 May 2003 23:45:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FnEh-000241-00 for ldapext@ietf.org; Tue, 13 May 2003 23:47:23 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 19FnEg-00023v-00 for ldapext@ietf.org; Tue, 13 May 2003 23:47:22 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with MailMarshal (v5,0,3,91) id ; Wed, 14 May 2003 13:45:40 +1000 Received: (qmail 17706 invoked from network); 14 May 2003 03:47:53 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 14 May 2003 03:47:53 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt Date: Wed, 14 May 2003 13:47:51 +1000 Message-ID: <004001c319cb$98c552f0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <003f01c319c7$19dc4c40$a518200a@osmium.mtwav.adacel.com.au> Importance: Normal 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 Steven Legg wrote: > Kurt D. Zeilenga wrote: > > >Doesn't matter. Matching rules operate on the abstract value, > > >not any particular encoding of the abstract value. > > > > While true, the OID of the matching rule identifies both > > the abstract type AND the LDAP string encoding to use. > > ... for the assertion value. Yes, okay, fair point. More an observation than a suggestion for change: if the equality matching rule for the entryUUID attribute was allComponentsMatch and the LDAP-specific encoding for the UUID syntax was the GSER encoding then the UUIDs would appear as hexadecimal digit character strings in LDAP, in both the attribute values and assertion values, and they would be matched in the same way as octetStringMatch. I assume that the ISO 11578 string representation isn't anything special and that all you care about is that the UUIDs normally appear as displayable characters rather than raw octets. There isn't an allComponentsOrderingMatch though. Regards, Steven _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed May 14 09:09:58 2003 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 JAA16769 for ; Wed, 14 May 2003 09:09:58 -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 h4ECaEB10770; Wed, 14 May 2003 08:36:14 -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 h4ECXAB10617 for ; Wed, 14 May 2003 08:33:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16708 for ; Wed, 14 May 2003 09:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FvzI-0005h9-00 for ldapext@ietf.org; Wed, 14 May 2003 09:08:04 -0400 Received: from c3po.aoltw.net ([64.236.137.25] helo=netscape.com) by ietf-mx with esmtp (Exim 4.12) id 19FvzH-0005g8-00 for ldapext@ietf.org; Wed, 14 May 2003 09:08:03 -0400 Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id h4ED8Zn00888 for ; Wed, 14 May 2003 06:08:35 -0700 (PDT) Received: from netscape.com ([10.169.192.51]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HEVOIA01.7GE; Wed, 14 May 2003 06:08:34 -0700 Message-ID: <3EC23FD1.6020900@netscape.com> Date: Wed, 14 May 2003 09:08:33 -0400 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: English/United States [en-US],English [en] MIME-Version: 1.0 To: steven.legg@adacel.com.au CC: "'Kurt D. Zeilenga'" , ldapext@ietf.org Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt References: <004001c319cb$98c552f0$a518200a@osmium.mtwav.adacel.com.au> In-Reply-To: <004001c319cb$98c552f0$a518200a@osmium.mtwav.adacel.com.au> 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 Steven Legg wrote: > > More an observation than a suggestion for change: if the equality > matching rule for the entryUUID attribute was allComponentsMatch > and the LDAP-specific encoding for the UUID syntax was the GSER > encoding then the UUIDs would appear as hexadecimal digit character > strings in LDAP, in both the attribute values and assertion values, > and they would be matched in the same way as octetStringMatch. > I assume that the ISO 11578 string representation isn't anything > special and that all you care about is that the UUIDs normally appear > as displayable characters rather than raw octets. I suspect the ISO 11578 string representation is special to some people and some existing code. It seems wise to use it rather than something that will be directory specific. -- Mark Smith Netscape Directory Product Development My words are my own, not my employer's. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue May 27 16:25:21 2003 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 QAA00023 for ; Tue, 27 May 2003 16:25:21 -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 h4RKOaB18486; Tue, 27 May 2003 16:24:36 -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 h4RKLTB18421 for ; Tue, 27 May 2003 16:21:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29806 for ; Tue, 27 May 2003 16:21:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KkvI-0000qg-00 for ldapext@ietf.org; Tue, 27 May 2003 16:19:52 -0400 Received: from pat.uio.no ([129.240.130.16]) by ietf-mx with esmtp (Exim 4.12) id 19KkvH-0000qT-00 for ldapext@ietf.org; Tue, 27 May 2003 16:19:51 -0400 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19Kkwl-00006j-00 for ldapext@ietf.org; Tue, 27 May 2003 22:21:23 +0200 Received: from [129.240.201.2] (helo=goggins.uio.no) by mail-mx1.uio.no with esmtp (Exim 4.14) id 19Kkwh-0007WX-AW for ldapext@ietf.org; Tue, 27 May 2003 22:21:19 +0200 Received: from bombur.uio.no ([129.240.186.42]) by goggins.uio.no with esmtp (Exim 2.12 #7) id 19Kkwh-0000QN-00; Tue, 27 May 2003 22:21:19 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19Kkwg-0005kw-00; Tue, 27 May 2003 22:21:18 +0200 From: Hallvard B Furuseth Message-Id: To: ldapext@ietf.org In-Reply-To: <200305131159.HAA05200@ietf.org> References: <200305131159.HAA05200@ietf.org> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Tue, 27 May 2003 22:21:18 +0200 X-MailScanner-Information: Please contact postmaster@uio.no for more information X-UiO-MailScanner: Found to be clean Subject: [ldapext] Description of UUIDs? (draft-zeilenga-ldap-uuid-00) 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: , Kurt, can you add a description of UUIDs to the draft, for us who do not have ISO 11578? Or is the description too big? -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext