From sip-admin@ietf.org Tue Jul 1 09:10:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20414 for ; Tue, 1 Jul 2003 09:10:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XKtY-0003CV-Df for ldapext-archive@lists.ietf.org; Tue, 01 Jul 2003 09:10:04 -0400 Date: Tue, 01 Jul 2003 09:10:04 -0400 Message-ID: <20030701131004.18162.5878.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: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@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. 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 Wed Jul 2 06:53:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02202 for ; Wed, 2 Jul 2003 06:53:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfET-0002WN-15; Wed, 02 Jul 2003 06:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfEM-0002S0-Ls for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 06:52:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01996; Wed, 2 Jul 2003 06:52:48 -0400 (EDT) Message-Id: <200307021052.GAA01996@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, 02 Jul 2003 06:52:48 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-cancel-09.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-09.txt Pages : 7 Date : 2003-7-1 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-09.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-09.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-09.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-7-1134025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-cancel-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-cancel-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134025.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 06:55:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02642 for ; Wed, 2 Jul 2003 06:55:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfGO-0002dL-TR; Wed, 02 Jul 2003 06:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfFy-0002bX-O9 for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 06:54:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02434; Wed, 2 Jul 2003 06:54:30 -0400 (EDT) Message-Id: <200307021054.GAA02434@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, 02 Jul 2003 06:54:30 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-noop-02.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-02.txt Pages : 5 Date : 2003-7-1 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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-noop-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-noop-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-1134354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-noop-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-noop-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134354.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 09:16:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15414 for ; Wed, 2 Jul 2003 09:16:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhSr-0000Ee-EC; Wed, 02 Jul 2003 09:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhSm-0000EK-Jc for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 09:15: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 JAA15363 for ; Wed, 2 Jul 2003 09:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhSk-0005ZX-00 for ldapext@ietf.org; Wed, 02 Jul 2003 09:15:54 -0400 Received: from goose.ehsco.com ([207.65.203.98]) by ietf-mx with esmtp (Exim 4.12) id 19XhSk-0005ZQ-00 for ldapext@ietf.org; Wed, 02 Jul 2003 09:15:54 -0400 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 260301 for ldapext@ietf.org; Wed, 02 Jul 2003 08:15:34 -0500 Message-ID: <3F02DB05.5050000@ehsco.com> Date: Wed, 02 Jul 2003 08:15:49 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 To: ldapext@ietf.org Subject: Re: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-idn-00.txt] References: <3EFAE220.2010906@ehsco.com> In-Reply-To: <3EFAE220.2010906@ehsco.com> 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 Any comments on this? on 6/26/2003 7:08 AM Eric A. Hall wrote: > FYI. Feedback appreciated. > > I really believe that something like this is needed to fully accomodate > IDNs in LDAP. The use of client-side transformations are extremely fragile > and prone to errors (eg, copying the data from one LDAP application and > pasting it in with another). I also think that nobody here really wants to > see codec output embedded in the namespace for years to come, but that's > the only predictable outcome from using client transformations. We need to > have UTF-8 elements for IDNs in order for them to work reliably. > > The following issues in particular are still unresolved. > > 7. Open Issues > > Should a structured domain name sequence be formally defined, with > the inetDomainComponent and inetEmail attributes formally > incorporating that sequence? > > Should the inetEmail attribute be formally defined as structured, > with the appropriate ASN.1? > > Should there be extensible matching filters that accept non- > normalized input, normalize it, and then search for matching > elements and/or attributes? > > Thanks > > > > ------------------------------------------------------------------------ > > Subject: I-D ACTION:draft-hall-ldap-idn-00.txt > From: Internet-Drafts@ietf.org > Date: Wed, 25 Jun 2003 10:52:10 -0400 > To: IETF-Announce: ; > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : LDAP Schema Extensions for Internationalized Domain > Names > Author(s) : E. Hall > Filename : draft-hall-ldap-idn-00.txt > Pages : 16 > Date : 2003-6-24 > > This document defines schema and behavioral rules which are > necessary to fully accommodate the use of internationalized domain > names as UTF-8 sequences in LDAP. Specifically, this document > defines an internationalized domain component attribute, email > address attribute, URI syntax, and several related object classes, > and also discusses their usage considerations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hall-ldap-idn-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-hall-ldap-idn-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-hall-ldap-idn-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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 09:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19198 for ; Wed, 2 Jul 2003 09:53:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xi2f-0002Dc-Bt; Wed, 02 Jul 2003 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xi1y-0002D9-U2 for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 09:52: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 JAA19081 for ; Wed, 2 Jul 2003 09:52:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xi1w-00073F-00 for ldapext@ietf.org; Wed, 02 Jul 2003 09:52:16 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.103]) by ietf-mx with esmtp (Exim 4.12) id 19Xi1v-000723-00 for ldapext@ietf.org; Wed, 02 Jul 2003 09:52:15 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h62DpcXq137104; Wed, 2 Jul 2003 09:51:38 -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 h62Dpb41033434; Wed, 2 Jul 2003 09:51:37 -0400 Subject: Re: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-idn-00.txt] To: "Eric A. Hall" Cc: ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Wed, 2 Jul 2003 08:51:36 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/02/2003 08:51:36 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'm not too familiar with IDNs, but I'll offer some initial questions (I hesitate to call them informed comments). If we require storing UTF-8 IDNs, does this require that clients be able to convert the IDN to the ASCII compatible sequence? It seems like this could present problems, as it requires application changes, whereas the ASCII compatible sequence, while not "pretty" is at least usable without application changes (true?). We might allow, rather than require, UTF-8 IDNs; its pretty easy to tell that a string contains UTF-8 and process accordingly if necessary, but the argument used above suggests it might not be a good idea until the applications are ready. Also, I suspect that most applications would have to convert from UTF-8 to something else (local code page?) anyway, but some LDAP clients do that for all string data already. Converting from ASCII compatible to desired form should not be a problem. With respect to the schema, hmm... I'm not too fond of the idea of having a dual set of objectclasses and attributes that applications must use. But I recognize that changing an IA5 String attribute to Directory String may not be palletable to standards bodies, and requires work on the part of implementations (schema updates, at least, possibly data migration, other changes). idc/inetDomainComponent - Could we drop the alias? Aliases cause problems. Defining an alias, while at the same time saying that systems MUST NOT use the alias... seems a bit contradictory at best. John McMeeking "Eric A. Hall" To: ldapext@ietf.org Sent by: cc: ldapext-admin@iet Subject: Re: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-idn-00.txt] f.org 07/02/2003 08:15 AM Any comments on this? on 6/26/2003 7:08 AM Eric A. Hall wrote: > FYI. Feedback appreciated. > > I really believe that something like this is needed to fully accomodate > IDNs in LDAP. The use of client-side transformations are extremely fragile > and prone to errors (eg, copying the data from one LDAP application and > pasting it in with another). I also think that nobody here really wants to > see codec output embedded in the namespace for years to come, but that's > the only predictable outcome from using client transformations. We need to > have UTF-8 elements for IDNs in order for them to work reliably. > > The following issues in particular are still unresolved. > > 7. Open Issues > > Should a structured domain name sequence be formally defined, with > the inetDomainComponent and inetEmail attributes formally > incorporating that sequence? > > Should the inetEmail attribute be formally defined as structured, > with the appropriate ASN.1? > > Should there be extensible matching filters that accept non- > normalized input, normalize it, and then search for matching > elements and/or attributes? > > Thanks > > > > ------------------------------------------------------------------------ > > Subject: I-D ACTION:draft-hall-ldap-idn-00.txt > From: Internet-Drafts@ietf.org > Date: Wed, 25 Jun 2003 10:52:10 -0400 > To: IETF-Announce: ; > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : LDAP Schema Extensions for Internationalized Domain > Names > Author(s) : E. Hall > Filename : draft-hall-ldap-idn-00.txt > Pages : 16 > Date : 2003-6-24 > > This document defines schema and behavioral rules which are > necessary to fully accommodate the use of internationalized domain > names as UTF-8 sequences in LDAP. Specifically, this document > defines an internationalized domain component attribute, email > address attribute, URI syntax, and several related object classes, > and also discusses their usage considerations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hall-ldap-idn-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-hall-ldap-idn-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-hall-ldap-idn-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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 10:01:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20286 for ; Wed, 2 Jul 2003 10:01:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XiAO-0003CE-P2; Wed, 02 Jul 2003 10:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xi9r-0003Ay-Ox for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 10:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20181 for ; Wed, 2 Jul 2003 10:00:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xi9p-0007Sr-00 for ldapext@ietf.org; Wed, 02 Jul 2003 10:00:25 -0400 Received: from goose.ehsco.com ([207.65.203.98]) by ietf-mx with esmtp (Exim 4.12) id 19Xi9o-0007So-00 for ldapext@ietf.org; Wed, 02 Jul 2003 10:00:24 -0400 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 260330; Wed, 02 Jul 2003 09:00:06 -0500 Message-ID: <3F02E575.6000202@ehsco.com> Date: Wed, 02 Jul 2003 09:00:21 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 To: John McMeeking CC: ldapext@ietf.org Subject: Re: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-idn-00.txt] References: In-Reply-To: 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 on 7/2/2003 8:51 AM John McMeeking wrote: > If we require storing UTF-8 IDNs, does this require that clients be > able to convert the IDN to the ASCII compatible sequence? Only if the client does some kind of active DC<->DNS mapping. In practice, there are very few applications which do this right now (although more are coming, and it would be a good idea to specify the use of IDNs sooner rather than later). Of those few applications, most of them can be handled through some of the workarounds described in the draft (eg, using referrals to point the dc searchbase to an idc naming context). > With respect to the schema, hmm... I'm not too fond of the idea of > having a dual set of objectclasses and attributes that applications > must use. But I recognize that changing an IA5 String attribute to > Directory String may not be palletable to standards bodies, and > requires work on the part of implementations (schema updates, at least, > possibly data migration, other changes). I modelled after the domainComponent draft but I'm not married to it. > idc/inetDomainComponent - Could we drop the alias? Aliases cause > problems. Defining an alias, while at the same time saying that systems > MUST NOT use the alias... seems a bit contradictory at best. I was trying to be "complete" by allocating the long form of the name, but I'm not married to it. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 11:43:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27353 for ; Wed, 2 Jul 2003 11:43:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjl7-0007wH-W1; Wed, 02 Jul 2003 11:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjkr-0007vZ-6Y for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 11:42:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27291 for ; Wed, 2 Jul 2003 11:42:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xjkp-0002St-00 for ldapext@ietf.org; Wed, 02 Jul 2003 11:42:43 -0400 Received: from tempo.update.uu.se ([130.238.19.17]) by ietf-mx with esmtp (Exim 4.12) id 19Xjkn-0002SY-00 for ldapext@ietf.org; Wed, 02 Jul 2003 11:42:42 -0400 Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.9/8.12.9/Update-Iltempogigante) with ESMTP id h62FgPn4022849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jul 2003 17:42:25 +0200 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.9/8.12.9/Update-Iltempogigante-submit) id h62FgPKI022846; Wed, 2 Jul 2003 17:42:25 +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 Content-Transfer-Encoding: quoted-printable Message-ID: <16130.64865.214103.568864@Tempo.Update.UU.SE> Date: Wed, 2 Jul 2003 17:42:25 +0200 To: ldapext@ietf.org Subject: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-idn-00.txt] In-Reply-To: <3EFAE220.2010906@ehsco.com> References: <3EFAE220.2010906@ehsco.com> X-Mailer: VM 7.16 under Emacs 20.7.2 Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This won't allow explicit IPv6 addresses in URLs; RFC 2255 uses the hostport from RFC 1738. Perhaps RFC 2255 would need an update. Thorild Sel=E9n Datorf=F6reningen Update / Update Computer Club, Uppsala, SE _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 11:58:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28493 for ; Wed, 2 Jul 2003 11:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjze-0001bP-Cx; Wed, 02 Jul 2003 11:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XjzX-0001Zc-8a for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 11:57:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28439 for ; Wed, 2 Jul 2003 11:57:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XjzV-0002sD-00 for ldapext@ietf.org; Wed, 02 Jul 2003 11:57:54 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 19XjzV-0002s3-00 for ldapext@ietf.org; Wed, 02 Jul 2003 11:57:53 -0400 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19XjzN-00055H-00; Wed, 2 Jul 2003 17:57:45 +0200 Received: from [129.240.201.2] (helo=goggins.uio.no) by mail-mx1.uio.no with esmtp (Exim 4.14) id 19XjzD-0006MD-Sq; Wed, 02 Jul 2003 17:57:35 +0200 Received: from bombur.uio.no ([129.240.186.42]) by goggins.uio.no with esmtp (Exim 2.12 #7) id 19XjzD-0001by-00; Wed, 2 Jul 2003 17:57:35 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19XjzC-000592-00; Wed, 2 Jul 2003 17:57:34 +0200 From: Hallvard B Furuseth Message-Id: To: Thorild Selen Cc: ldapext@ietf.org Subject: Re: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-idn-00.txt] In-Reply-To: <16130.64865.214103.568864@Tempo.Update.UU.SE> References: <3EFAE220.2010906@ehsco.com> <16130.64865.214103.568864@Tempo.Update.UU.SE> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 2 Jul 2003 17:57:34 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: , Thorild Selen writes: > This won't allow explicit IPv6 addresses in URLs; RFC 2255 uses the > hostport from RFC 1738. Perhaps RFC 2255 would need an update. Use draft-ietf-ldapbis-url-03.txt, when that is published. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 16:17:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11551 for ; Wed, 2 Jul 2003 16:17:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo2H-0001Dz-D7; Wed, 02 Jul 2003 16:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo1Y-00016f-6p for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 16:16:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11217; Wed, 2 Jul 2003 16:16:11 -0400 (EDT) Message-Id: <200307022016.QAA11217@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, 02 Jul 2003 16:16:10 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-ext-04.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 : Considerations for LDAP Extensions Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-ext-04.txt Pages : 13 Date : 2003-7-2 The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schema. This document discusses considerations for designers of LDAP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-ext-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-ext-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-ext-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-ext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161014.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 16:18:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11628 for ; Wed, 2 Jul 2003 16:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo3E-0001MV-DA; Wed, 02 Jul 2003 16:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo2H-0001EK-Of for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 16:17: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 QAA11472; Wed, 2 Jul 2003 16:16:56 -0400 (EDT) Message-Id: <200307022016.QAA11472@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, 02 Jul 2003 16:16:56 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-t-f-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 : LDAP Absolute True and False Filters Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-t-f-06.txt Pages : 5 Date : 2003-7-2 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-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-t-f-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-t-f-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-7-2161152.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-t-f-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-t-f-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161152.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 16:18:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11634 for ; Wed, 2 Jul 2003 16:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo3E-0001NH-Nn; Wed, 02 Jul 2003 16:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo2M-0001FK-Hg for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 16:17:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11488; Wed, 2 Jul 2003 16:17:01 -0400 (EDT) Message-Id: <200307022017.QAA11488@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, 02 Jul 2003 16:17:01 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-adlist-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 : LDAPv3: Requesting Attributes by Object Class Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-adlist-05.txt Pages : 5 Date : 2003-7-2 The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, or attributes selected by their description. This document extends LDAP to provide a mechanism for LDAP clients to request the return of all attributes of an object class. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-adlist-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-adlist-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-adlist-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-7-2161202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-adlist-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-adlist-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161202.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 2 16:32:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12703 for ; Wed, 2 Jul 2003 16:32:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoGn-0002UU-1P; Wed, 02 Jul 2003 16:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoG3-0002Ll-Pw for ldapext@optimus.ietf.org; Wed, 02 Jul 2003 16:31:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12382; Wed, 2 Jul 2003 16:31:10 -0400 (EDT) Message-Id: <200307022031.QAA12382@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, 02 Jul 2003 16:31:10 -0400 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-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 entryUUID operational attribute Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-uuid-01.txt Pages : 7 Date : 2003-7-2 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-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-uuid-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-uuid-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-7-2161323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-uuid-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-uuid-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161323.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Jul 3 11:30:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16230 for ; Thu, 3 Jul 2003 11:30:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y627-00017F-Go; Thu, 03 Jul 2003 11:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y61z-000145-Fp for ldapext@optimus.ietf.org; Thu, 03 Jul 2003 11:29:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15917; Thu, 3 Jul 2003 11:29:53 -0400 (EDT) Message-Id: <200307031529.LAA15917@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: Thu, 03 Jul 2003 11:29:52 -0400 Subject: [ldapext] I-D ACTION:draft-apurva-ldap-query-containment-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 : Schema to Support Query Containment in LDAP Directories Author(s) : A. Kumar Filename : draft-apurva-ldap-query-containment-01.txt Pages : 23 Date : 2003-7-3 Lightweight Directory Access Protocol (LDAP) directories are being used at the backend of many internet and intranet applications. LDAP servers that cache entries which are returned as search results (queries) 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-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-apurva-ldap-query-containment-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-apurva-ldap-query-containment-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-7-3111652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-apurva-ldap-query-containment-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-apurva-ldap-query-containment-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3111652.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From mailman-admin@ietf.org Thu Jul 3 18:51:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17218 for ; Thu, 3 Jul 2003 18:49:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YCeS-0006DA-C5 for ldapext-archive@lists.ietf.org; Thu, 03 Jul 2003 18:34:04 -0400 Date: Thu, 03 Jul 2003 18:34:04 -0400 Message-ID: <20030703223404.4508.87616.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 There was an error in the last monthly reminder, in that the NOTE WELL statement (below) was not included. Therefore, the reminder is being sent out again. 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 Mon Jul 7 22:10:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24484 for ; Mon, 7 Jul 2003 22:10:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zhvd-0004Kq-Ms; Mon, 07 Jul 2003 22:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zhv5-0004K6-CT for ldapext@optimus.ietf.org; Mon, 07 Jul 2003 22:09: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 WAA24463 for ; Mon, 7 Jul 2003 22:09:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zhv2-0005Ky-00 for ldapext@ietf.org; Mon, 07 Jul 2003 22:09:24 -0400 Received: from [155.35.248.106] (helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 19Zhv1-0005K5-00 for ldapext@ietf.org; Mon, 07 Jul 2003 22:09:23 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 12:08:51 +1000 content-class: urn:content-classes:message Subject: RE: [ldapext] UUIDs should be case-insensitive MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Jul 2003 12:08:51 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <1395B4B334FCC143B36AF788E68B63814658F7@ausyms21.ca.com> Thread-Topic: [ldapext] UUIDs should be case-insensitive Thread-Index: AcM9pJQN53iaTt3wRLeU9Y5TPKku3wHUOcrg From: "Ramsay, Ron" To: "Hallvard B Furuseth" , "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 08 Jul 2003 02:08:51.0320 (UTC) FILETIME=[E00E0F80:01C344F5] Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable How can this be? If the value is supplied as ascii, octetStringMatch = would apply to the ascii. If you mean that the match should apply to the = semantic value then, surely, this would require the definition of a = specific matching rule? -----Original Message----- From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Sunday, 29 June 2003 04:38 To: Kurt D. Zeilenga Cc: ldapext@ietf.org Subject: Re: [ldapext] UUIDs should be case-insensitive > Note that comparison is between UUIDs, not the string representations > of the UUIDs, hence octetStringMatch is the correct rule. Whoops. Good point. --=20 Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Jul 10 12:50:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11785 for ; Thu, 10 Jul 2003 12:50:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aecL-00018L-9R; Thu, 10 Jul 2003 12:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aebm-00017b-9J for ldapext@optimus.ietf.org; Thu, 10 Jul 2003 12:49:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11758 for ; Thu, 10 Jul 2003 12:49:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aebk-00055Q-00 for ldapext@ietf.org; Thu, 10 Jul 2003 12:49:24 -0400 Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx with esmtp (Exim 4.12) id 19aebj-00055I-00 for ldapext@ietf.org; Thu, 10 Jul 2003 12:49:23 -0400 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 2.12 #7) id 19aebY-0003lN-00; Thu, 10 Jul 2003 18:49:12 +0200 Received: from [129.240.130.19] (helo=miss.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.14) id 19aebV-0006g6-Rt; Thu, 10 Jul 2003 18:49:09 +0200 Received: from bombur.uio.no ([129.240.186.42]) by miss.uio.no with esmtp (Exim 2.12 #7) id 19aebV-0007As-00; Thu, 10 Jul 2003 18:49:09 +0200 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 19aebU-0001n1-00; Thu, 10 Jul 2003 18:49:08 +0200 From: Hallvard B Furuseth Message-Id: To: "Ramsay, Ron" Cc: "Kurt D. Zeilenga" , ldapext@ietf.org Subject: RE: [ldapext] UUIDs should be case-insensitive In-Reply-To: <1395B4B334FCC143B36AF788E68B63814658F7@ausyms21.ca.com> References: <1395B4B334FCC143B36AF788E68B63814658F7@ausyms21.ca.com> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Thu, 10 Jul 2003 18:49:08 +0200 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning. X-UiO-MailScanner: No virus found 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: , Ramsay, Ron writes: > If you mean that the match should apply to the semantic value then, > surely, this would require the definition of a specific matching rule? The draft does define a specific uuid matching rule and a specific syntax. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Jul 14 10:06:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21913 for ; Mon, 14 Jul 2003 10:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3xo-0006n3-Nb; Mon, 14 Jul 2003 10:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3xT-0006mn-R0 for ldapext@optimus.ietf.org; Mon, 14 Jul 2003 10:05:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21813 for ; Mon, 14 Jul 2003 10:05:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3xR-000094-00 for ldapext@ietf.org; Mon, 14 Jul 2003 10:05:37 -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 19c3xQ-000090-00 for ldapext@ietf.org; Mon, 14 Jul 2003 10:05:36 -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 h6EE5Kc6082969 for ; Mon, 14 Jul 2003 14:05:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030714155603.01c72d20@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 14 Jul 2003 16:02:10 +0200 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ldapext] LDAP "atomic" operations Bar BOF 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: , Those interested in chatting about the following LDAP extensions: LDAP Assertion Control (draft-zeilenga-ldap-assert) LDAP Modify/Increment LDAP Subtree Locking LDAP Read Entry Controls (draft-zeilenga-ldap-readentry) LDAP Transactions (draft-zeilenga-ldap-txn) and related topics are welcomed to gather at the message board at 8pm this evening and we'll then wonder down to a bar. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Jul 14 14:00:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09283 for ; Mon, 14 Jul 2003 14:00:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7cH-0005dt-06; Mon, 14 Jul 2003 14:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7bK-0005aX-Az for ldapext@optimus.ietf.org; Mon, 14 Jul 2003 13:59: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 NAA09202 for ; Mon, 14 Jul 2003 13:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7bG-0004CU-00 for ldapext@ietf.org; Mon, 14 Jul 2003 13:58:58 -0400 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 19c7bF-0004CG-00 for ldapext@ietf.org; Mon, 14 Jul 2003 13:58:57 -0400 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 14 Jul 2003 11:58:26 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Mon, 14 Jul 2003 11:56:24 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] LDAP "atomic" operations Bar BOF Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part732D53D8.0__=" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part732D53D8.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit A few of us (Chadwick, Prasad, I) are in the terminal room just wrapping a few things up. Will be there soon. >>> "Kurt D. Zeilenga" 7/14/03 4:02:10 PM >>> Those interested in chatting about the following LDAP extensions: LDAP Assertion Control (draft-zeilenga-ldap-assert) LDAP Modify/Increment LDAP Subtree Locking LDAP Read Entry Controls (draft-zeilenga-ldap-readentry) LDAP Transactions (draft-zeilenga-ldap-txn) and related topics are welcomed to gather at the message board at 8pm this evening and we'll then wonder down to a bar. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part732D53D8.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit A few of us (Chadwick, Prasad, I) are in the terminal room just wrapping a few things up. Will be there soon.

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 7/14/03 4:02:10 PM >>>
Those interested in chatting about the following LDAP
extensions:
LDAP Assertion Control (draft-zeilenga-ldap-assert)
LDAP Modify/Increment
LDAP Subtree Locking
LDAP Read Entry Controls (draft-zeilenga-ldap-readentry)
LDAP Transactions (draft-zeilenga-ldap-txn)

and related topics are welcomed to gather at the message
board at 8pm this evening and we'll then wonder down to a
bar.

Kurt


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
--=__Part732D53D8.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Jul 17 05:19:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25240 for ; Thu, 17 Jul 2003 05:19:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4uj-0000vr-4G; Thu, 17 Jul 2003 05:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4u4-0000vF-T2 for ldapext@optimus.ietf.org; Thu, 17 Jul 2003 05:18:20 -0400 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25144 for ; Thu, 17 Jul 2003 05:18:15 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 17 Jul 2003 03:17:47 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 17 Jul 2003 03:15:31 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part0B552F23.0__=" Subject: [ldapext] draft-legg-ldap-transfer-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: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part0B552F23.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I'm worried that using SearchRequest.attributes to specify transfer encodings is going to cause problems. The draft uses an attribute description option to allow one to request a search return attribute to be encoded in a particular way (;transfer-). It goes further to allow "all user attrs transferred as..." (*;transfer-). Other specification s have proposed and are proposing other tricks with attribute description options (+ specifies "all operational attrs"), (+country specifies "all user attributes allowed by the country object class"). The problem is that we have a single mechanism (attribute description option) to specify disparate features. The way in which these disparate features work together (I fear) will be overlooked and under specified. For example, as soon as one sees that *;transfer-ber is available, they want to use +;transfer-ber, or +country;transfer-ber. We can either address this by adding some more statements to the extensions considerations document, or just stop using attribute description options and start using controls. Jim --=__Part0B552F23.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
I'm worried that using SearchRequest.attributes to specify transfer encodings is going to cause problems.
 
The draft uses an attribute description option to allow one to request a search return attribute to be encoded in a particular way (<attr>;transfer-<xferopt>). It goes further to allow "all user attrs transferred as..." (*;transfer-<xferopt>). Other specification s have proposed and are proposing other tricks with attribute description options (+ specifies "all operational attrs"), (+country specifies "all user attributes allowed by the country object class").
 
The problem is that we have a single mechanism (attribute description option) to specify disparate features. The way in which these disparate features work together (I fear) will be overlooked and under specified. For example, as soon as one sees that *;transfer-ber is available, they want to use +;transfer-ber, or +country;transfer-ber.
 
We can either address this by adding some more statements to the extensions considerations document, or just stop using attribute description options and start using controls.
 
Jim
--=__Part0B552F23.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Jul 17 05:29:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26097 for ; Thu, 17 Jul 2003 05:29:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d54P-0001Zg-MA; Thu, 17 Jul 2003 05:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d53W-0001Yn-Bb for ldapext@optimus.ietf.org; Thu, 17 Jul 2003 05:28:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26013 for ; Thu, 17 Jul 2003 05:28:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d53T-0003oo-00 for ldapext@ietf.org; Thu, 17 Jul 2003 05:28:03 -0400 Received: from [155.35.248.106] (helo=ausyms50.ca.com) by ietf-mx with esmtp (Exim 4.12) id 19d53I-0003o5-00 for ldapext@ietf.org; Thu, 17 Jul 2003 05:27:52 -0400 Received: from ausyms21.ca.com ([155.35.201.5]) by ausyms50.ca.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 19:27:06 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34C45.967BCB9E" Subject: RE: [ldapext] draft-legg-ldap-transfer-00 Date: Thu, 17 Jul 2003 19:27:05 +1000 Message-ID: <1395B4B334FCC143B36AF788E68B63814DFBB4@ausyms21.ca.com> Thread-Topic: [ldapext] draft-legg-ldap-transfer-00 Thread-Index: AcNMRJo1YyY56FDjRmGiFID84xXnsgAAHBsw From: "Ramsay, Ron" To: "Jim Sermersheim" , X-OriginalArrivalTime: 17 Jul 2003 09:27:06.0046 (UTC) FILETIME=[96A695E0:01C34C45] Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C34C45.967BCB9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We should stop using attribute descriptions for this purpose. =20 You rtaised this issue some time ago and the problem seemed to be that = RFC 2251 allowed '*' to appear in an attribute description (contrary to = the semantics). Kurt introduced '+' and continues to expand it. =20 The statement one would like to make is that none of these uses are = appropriate. But RFC 2251 already argues against this. =20 So, ... where do you draw the line? =20 Ron -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Thursday, 17 July 2003 19:16 To: ldapext@ietf.org Subject: [ldapext] draft-legg-ldap-transfer-00 I'm worried that using SearchRequest.attributes to specify transfer = encodings is going to cause problems. =20 The draft uses an attribute description option to allow one to request a = search return attribute to be encoded in a particular way = (;transfer-). It goes further to allow "all user attrs = transferred as..." (*;transfer-). Other specification s have = proposed and are proposing other tricks with attribute description = options (+ specifies "all operational attrs"), (+country specifies "all = user attributes allowed by the country object class"). =20 The problem is that we have a single mechanism (attribute description = option) to specify disparate features. The way in which these disparate = features work together (I fear) will be overlooked and under specified. = For example, as soon as one sees that *;transfer-ber is available, they = want to use +;transfer-ber, or +country;transfer-ber. =20 We can either address this by adding some more statements to the = extensions considerations document, or just stop using attribute = description options and start using controls. =20 Jim ------_=_NextPart_001_01C34C45.967BCB9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We should stop using attribute = descriptions=20 for this purpose.
 
You rtaised this issue some time = ago and the=20 problem seemed to be that RFC 2251 allowed '*' to appear in an attribute = description (contrary to the semantics). Kurt introduced '+' and = continues to=20 expand it.
 
The statement one would like to = make is that=20 none of these uses are appropriate. But RFC 2251 already argues against=20 this.
 
So, ... where do you draw the=20 line?
 
Ron
-----Original Message-----
From: Jim = Sermersheim=20 [mailto:jimse@novell.com]
Sent: Thursday, 17 July 2003=20 19:16
To: ldapext@ietf.org
Subject: [ldapext]=20 draft-legg-ldap-transfer-00

I'm = worried that=20 using SearchRequest.attributes to specify transfer encodings is going = to cause=20 problems.
 
The = draft uses an=20 attribute description option to allow one to request a search return = attribute=20 to be encoded in a particular way = (<attr>;transfer-<xferopt>). It=20 goes further to allow "all user attrs transferred as..."=20 (*;transfer-<xferopt>). Other specification s have proposed and = are=20 proposing other tricks with attribute description options (+ specifies = "all=20 operational attrs"), (+country specifies "all user attributes allowed = by the=20 country object class").
 
The = problem is=20 that we have a single mechanism (attribute description option) = to specify=20 disparate features. The way in which these disparate features work = together (I=20 fear) will be overlooked and under specified. For example, as soon as = one sees=20 that *;transfer-ber is available, they want to use +;transfer-ber, or=20 +country;transfer-ber.
 
We can = either=20 address this by adding some more statements to the extensions = considerations=20 document, or just stop using attribute description options and start = using=20 controls.
 
Jim
------_=_NextPart_001_01C34C45.967BCB9E-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Jul 22 10:32:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15549 for ; Tue, 22 Jul 2003 10:32:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eyBN-0000ox-Sp; Tue, 22 Jul 2003 10:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ewXP-0005Uv-FK for ldapext@optimus.ietf.org; Tue, 22 Jul 2003 08:46: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 IAA11444 for ; Tue, 22 Jul 2003 08:46:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ewXO-0004Dj-00 for ldapext@ietf.org; Tue, 22 Jul 2003 08:46:38 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19ewXD-0004DN-00 for ldapext@ietf.org; Tue, 22 Jul 2003 08:46:27 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6MCjwbj003232; Tue, 22 Jul 2003 06:45:59 -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 h6MCjve20611; Tue, 22 Jul 2003 14:45:57 +0200 (MEST) Message-ID: <3F1D3205.3090905@Sun.com> Date: Tue, 22 Jul 2003 14:45:57 +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: ldapext@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ldapext] Assert I-D. 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 Hi Kurt, I have some questions regarding the Assertion Control. I'm not sure the Assertion as defined presently can be applied to "Add" operations. The section 3 says that "For Add, Compare, and ModifyDN the target is indicated by the entry field in the request.". For an add operation, the entry field is the entry being added. Applying assertion on the data that is part of the add operation itself doesn't give much added-value. Can you explain why you want to support Assert on the Add operation ? Also, the text should be less ambiguous on when the assertion is to be checked. The draft says that the Assertion and the Operation shall be done as an atomic operation. But it doesn't say if the assertion is to be applied BEFORE the target entry contains the changes or AFTER. For example, if I assert that foo=bar but replace the attribute foo with the foobar value, the assertion is true before I apply the change and not after. Ludovic. -- 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 Jul 22 15:32:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24528 for ; Tue, 22 Jul 2003 15:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2rh-0005Lb-0j; Tue, 22 Jul 2003 15:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2qr-0005LA-Ot for ldapext@optimus.ietf.org; Tue, 22 Jul 2003 15:31:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24498 for ; Tue, 22 Jul 2003 15:31:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2qq-0006t0-00 for ldapext@ietf.org; Tue, 22 Jul 2003 15:31:08 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 19f2qd-0006sM-00 for ldapext@ietf.org; Tue, 22 Jul 2003 15:30:56 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6MJPf128869; Tue, 22 Jul 2003 21:25:43 +0200 Message-ID: <3F1D8FB4.4090902@it.su.se> Date: Tue, 22 Jul 2003 21:25:40 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludovic Poitou CC: "Kurt D. Zeilenga" , ldapext@ietf.org Subject: Re: [ldapext] Assert I-D. References: <3F1D3205.3090905@Sun.com> In-Reply-To: <3F1D3205.3090905@Sun.com> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; 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 Ludovic Poitou wrote: > Hi Kurt, > > Can you explain why you want to support Assert on the Add operation ? I guess you could assert the parent... MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 01:44:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06249 for ; Wed, 23 Jul 2003 01:44:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fCPx-00085n-BC; Wed, 23 Jul 2003 01:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fCPg-00085c-Ed for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 01:43:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06244 for ; Wed, 23 Jul 2003 01:43:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fCPd-0001vG-00 for ldapext@ietf.org; Wed, 23 Jul 2003 01:43:41 -0400 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 19fCPS-0001ux-00 for ldapext@ietf.org; Wed, 23 Jul 2003 01:43:30 -0400 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 22 Jul 2003 23:42:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Tue, 22 Jul 2003 23:40:28 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part8AD4A6DC.0__=" Subject: [ldapext] draft-zeilenga-ldap-ext-04.txt: Controls Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part8AD4A6DC.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In Section 3.1 It would be useful to note that designers of controls should consider defining a response control regardless of whether there is a need for payload. This helps clients that wish to mark a request control as non-critical, yet still want to receive acknowlegment of whether or not the server supported the control. Jim --=__Part8AD4A6DC.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
In Section 3.1 It would be useful to note that designers of controls should consider defining a response control regardless of whether there is a need for payload. This helps clients that wish to mark a request control as non-critical, yet still want to receive acknowlegment of whether or not the server supported the control.
 
<Also, there's an extra "unless" in the second paragraph.>
 
Jim
--=__Part8AD4A6DC.0__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 03:17:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04287 for ; Wed, 23 Jul 2003 03:17:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDry-0004sH-3A; Wed, 23 Jul 2003 03:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDrO-0004rR-7v for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 03:16:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04266 for ; Wed, 23 Jul 2003 03:16:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fDrM-0002Ym-00 for ldapext@ietf.org; Wed, 23 Jul 2003 03:16:24 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 19fDrA-0002YQ-00 for ldapext@ietf.org; Wed, 23 Jul 2003 03:16:13 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6N7Bx117789; Wed, 23 Jul 2003 09:12:00 +0200 Message-ID: <3F1E353F.8030905@it.su.se> Date: Wed, 23 Jul 2003 09:11:59 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludovic Poitou CC: "Kurt D. Zeilenga" , ldapext@ietf.org Subject: Re: [ldapext] Assert I-D. References: <3F1D3205.3090905@Sun.com> <3F1D8FB4.4090902@it.su.se> <3F1E33E7.7050104@Sun.com> In-Reply-To: <3F1E33E7.7050104@Sun.com> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; 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 Ludovic Poitou wrote: > I agree, but this is not explicit in the Assert draft. and it's in > contradiction with the text that specify that the Assertion is done on > the Target entry. For an Add, the target is the entry to add, not the > parent. > > Ludovic. > > Oh yes. I was just offering up a useful (?) semantic. Clearly the text has to change if this is how the control is to be used for add-operations. MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 04:01:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05250 for ; Wed, 23 Jul 2003 04:01:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fEYY-0006ii-5T; Wed, 23 Jul 2003 04:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fEXp-0006hv-OR for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 04:00:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05194 for ; Wed, 23 Jul 2003 04:00:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fEXn-0002sC-00 for ldapext@ietf.org; Wed, 23 Jul 2003 04:00:15 -0400 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 19fEXc-0002rF-00 for ldapext@ietf.org; Wed, 23 Jul 2003 04:00:04 -0400 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 23 Jul 2003 01:59:14 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Wed, 23 Jul 2003 01:58:55 -0600 From: "Vithalprasad Gaitonde" To: Subject: Re: [ldapext] Assert I-D. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 But that would mean we have to lock the parent (another entry) in this operation. All the other update operations required that only the entry being acted upon is locked. I guess it has certain implications for server implementors. Prasad >>> Leif Johansson 7/23/2003 12:41:59 PM >>> Ludovic Poitou wrote: > I agree, but this is not explicit in the Assert draft. and it's in > contradiction with the text that specify that the Assertion is done on > the Target entry. For an Add, the target is the entry to add, not the > parent. > > Ludovic. > > Oh yes. I was just offering up a useful (?) semantic. Clearly the text has to change if this is how the control is to be used for add-operations. MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 04:10:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05407 for ; Wed, 23 Jul 2003 04:10:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fEhF-0007Ks-Kz; Wed, 23 Jul 2003 04:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fEge-0007JW-Ql for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 04:09:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05391 for ; Wed, 23 Jul 2003 04:09:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fEgc-0002xA-00 for ldapext@ietf.org; Wed, 23 Jul 2003 04:09:22 -0400 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 19fEgR-0002wg-00 for ldapext@ietf.org; Wed, 23 Jul 2003 04:09:11 -0400 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 23 Jul 2003 02:08:37 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Wed, 23 Jul 2003 02:08:20 -0600 From: "Vithalprasad Gaitonde" To: Subject: Re: [ldapext] Assert I-D. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 "Also, the text should be less ambiguous on when the assertion is to be checked. The draft says that the Assertion and the Operation shall be done as an atomic operation. But it doesn't say if the assertion is to be applied BEFORE the target entry contains the changes or AFTER. For example, if I assert that foo=bar but replace the attribute foo with the foobar value, the assertion is true before I apply the change and not after." I wonder when you would need to assert after the update operation. If the intention of the assert after the update is to check if a value got set, the server sending a success result code in response to an operation would mean that the update is successful. So assert in that case isn't meaningful. Assert after an update may only make sense with the increment modify operation that Kurt was describing - so we could check for a particular value after the increment. Prasad _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 06:41:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07954 for ; Wed, 23 Jul 2003 06:41:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH3N-0003z6-Rc; Wed, 23 Jul 2003 06:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fH2f-0003yq-JF for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 06:40:17 -0400 Received: from klapautius.it.su.se (as13-3-2.rny.s.bonet.se [217.215.166.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07940 for ; Wed, 23 Jul 2003 06:40:11 -0400 (EDT) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6NAat117919; Wed, 23 Jul 2003 12:36:56 +0200 Message-ID: <3F1E6547.6060107@it.su.se> Date: Wed, 23 Jul 2003 12:36:55 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vithalprasad Gaitonde CC: ldapext@ietf.org Subject: Re: [ldapext] Assert I-D. References: In-Reply-To: X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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 Vithalprasad Gaitonde wrote: >But that would mean we have to lock the parent (another entry) in this >operation. All the other update operations required that only the entry >being acted upon is locked. >I guess it has certain implications for server implementors. > > > Yes you are right. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 09:43:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12558 for ; Wed, 23 Jul 2003 09:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJtU-00025Z-No; Wed, 23 Jul 2003 09:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJtB-00025L-3q for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 09:42: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 JAA12536 for ; Wed, 23 Jul 2003 09:42:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJt9-0004lN-00 for ldapext@ietf.org; Wed, 23 Jul 2003 09:42:39 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19fJsy-0004l8-00 for ldapext@ietf.org; Wed, 23 Jul 2003 09:42:28 -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 h6NDfuc6082692; Wed, 23 Jul 2003 13:41:57 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030723153600.01b94600@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 23 Jul 2003 15:38:39 +0200 To: Ludovic Poitou From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Assert I-D. Cc: ldapext@ietf.org In-Reply-To: <3F1D3205.3090905@Sun.com> 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 02:45 PM 7/22/2003, Ludovic Poitou wrote: >Hi Kurt, > >I have some questions regarding the Assertion Control. > >I'm not sure the Assertion as defined presently can be applied to "Add" operations. I think that the control should not be applicable to Add. I'll update the next revision to reflect this. >The section 3 says that "For Add, Compare, and ModifyDN the target is indicated by the entry field in the request.". For an add operation, the entry field is the entry being added. Applying assertion on the data that is part of the add operation itself doesn't give much added-value. >Can you explain why you want to support Assert on the Add operation ? > >Also, the text should be less ambiguous on when the assertion is to be checked. The draft says that the Assertion and the Operation shall be done as an atomic operation. But it doesn't say if the assertion is to be applied BEFORE the target entry contains the changes or AFTER. >For example, if I assert that foo=bar but replace the attribute foo with the foobar value, the assertion is true before I apply the change and not after. BEFORE. Will clarify. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 09:56:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12908 for ; Wed, 23 Jul 2003 09:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fK65-0002j8-O4; Wed, 23 Jul 2003 09:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fK5r-0002is-7W for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 09:55:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12871 for ; Wed, 23 Jul 2003 09:55:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fK5p-0004r2-00 for ldapext@ietf.org; Wed, 23 Jul 2003 09:55:45 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 19fK5d-0004qm-00 for ldapext@ietf.org; Wed, 23 Jul 2003 09:55:34 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6NDpZ118115; Wed, 23 Jul 2003 15:51:41 +0200 Message-ID: <3F1E92E7.5060007@it.su.se> Date: Wed, 23 Jul 2003 15:51:35 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Ludovic Poitou , ldapext@ietf.org Subject: Re: [ldapext] Assert I-D. References: <5.2.0.9.0.20030723153600.01b94600@127.0.0.1> In-Reply-To: <5.2.0.9.0.20030723153600.01b94600@127.0.0.1> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; 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 think that the control should not be applicable to Add. >I'll update the next revision to reflect this. > > Hmm, actually it might make sense if you have attributes which are generated when the entry is added but are not part of the entry sent from the client. MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 10:42:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15464 for ; Wed, 23 Jul 2003 10:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKob-00056d-HM; Wed, 23 Jul 2003 10:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKoV-00054G-LO for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 10:41:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15441 for ; Wed, 23 Jul 2003 10:41:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKoT-00057O-00 for ldapext@ietf.org; Wed, 23 Jul 2003 10:41:53 -0400 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 19fKoI-000579-00 for ldapext@ietf.org; Wed, 23 Jul 2003 10:41:42 -0400 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 23 Jul 2003 08:40:50 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Wed, 23 Jul 2003 08:36:18 -0600 From: "Vithalprasad Gaitonde" To: Subject: Re: [ldapext] Assert I-D. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 But then assert has to be after the add but Kurt says its BEFORE. >>> Leif Johansson 7/23/2003 7:21:35 PM >>> Kurt D. Zeilenga wrote: > > >I think that the control should not be applicable to Add. >I'll update the next revision to reflect this. > > Hmm, actually it might make sense if you have attributes which are generated when the entry is added but are not part of the entry sent from the client. MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 10:52:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15854 for ; Wed, 23 Jul 2003 10:52:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKyH-0005bh-IF; Wed, 23 Jul 2003 10:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKyF-0005bD-Ku for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 10:51: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 KAA15831 for ; Wed, 23 Jul 2003 10:51:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKyD-0005D6-00 for ldapext@ietf.org; Wed, 23 Jul 2003 10:51:57 -0400 Received: from as13-3-2.rny.s.bonet.se ([217.215.166.49] helo=klapautius.it.su.se) by ietf-mx with esmtp (Exim 4.12) id 19fKy1-0005D1-00 for ldapext@ietf.org; Wed, 23 Jul 2003 10:51:46 -0400 Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h6NElZ118150; Wed, 23 Jul 2003 16:47:37 +0200 Message-ID: <3F1EA007.1050308@it.su.se> Date: Wed, 23 Jul 2003 16:47:35 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ludovic Poitou CC: "Kurt D. Zeilenga" , ldapext@ietf.org Subject: Re: [ldapext] Assert I-D. References: <5.2.0.9.0.20030723153600.01b94600@127.0.0.1> <3F1E92E7.5060007@it.su.se> <3F1E96D6.7080200@Sun.com> In-Reply-To: <3F1E96D6.7080200@Sun.com> X-Enigmail-Version: 0.76.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; 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 Ludovic Poitou wrote: > > > Leif Johansson wrote: > >> Kurt D. Zeilenga wrote: >> >>> >>> >>> I think that the control should not be applicable to Add. >>> I'll update the next revision to reflect this. >>> >>> >> >> Hmm, actually it might make sense if you have attributes which are >> generated when the entry is added but are not part of the entry sent >> from the client. > > > In that case, you may want to retrieve these attributes, not to assert > on them. Yea you might - I only want to add this entry if the uuid I get is an even number of 1's :-) MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Jul 23 11:06:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16202 for ; Wed, 23 Jul 2003 11:06:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLBq-00063N-6W; Wed, 23 Jul 2003 11:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fF99-0000Bh-Jk for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 04:38:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06006 for ; Wed, 23 Jul 2003 04:38:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fF96-0003Bn-00 for ldapext@ietf.org; Wed, 23 Jul 2003 04:38:48 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19fF8v-0003Bi-00 for ldapext@ietf.org; Wed, 23 Jul 2003 04:38:37 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6N8cWFt022488; Wed, 23 Jul 2003 02:38: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 h6N8cWe17132; Wed, 23 Jul 2003 10:38:32 +0200 (MEST) Message-ID: <3F1E4987.9060108@Sun.com> Date: Wed, 23 Jul 2003 10:38:31 +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: Vithalprasad Gaitonde CC: ldapext@ietf.org Subject: Re: [ldapext] Assert I-D. References: 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 Vithalprasad Gaitonde wrote: >"Also, the text should be less ambiguous on when the assertion is to be > >checked. The draft says that the Assertion and the Operation shall be >done as an atomic operation. But it doesn't say if the assertion is to > >be applied BEFORE the target entry contains the changes or AFTER. >For example, if I assert that foo=bar but replace the attribute foo >with >the foobar value, the assertion is true before I apply the change and >not after." > >I wonder when you would need to assert after the update operation. If >the intention of the assert after the update is to check if a value got >set, the server sending a success result code in response to an >operation would mean that the update is successful. So assert in that >case isn't meaningful. > >Assert after an update may only make sense with the increment modify >operation that Kurt was describing - so we could check for a particular >value after the increment. > > Agree... Or if the Assert is on Operational Attributes... Ludovic. >Prasad > >_______________________________________________ >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 > > -- 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 Wed Jul 23 11:06:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16218 for ; Wed, 23 Jul 2003 11:06:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLBp-00063D-TA; Wed, 23 Jul 2003 11:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDic-0004Gm-Ni for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 03:07:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04018 for ; Wed, 23 Jul 2003 03:07:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fDiY-0002Ta-00 for ldapext@ietf.org; Wed, 23 Jul 2003 03:07:18 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19fDiO-0002TN-00 for ldapext@ietf.org; Wed, 23 Jul 2003 03:07:08 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6N76GDZ017851; Wed, 23 Jul 2003 00:06:17 -0700 (PDT) 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 h6N76Ge12058; Wed, 23 Jul 2003 09:06:16 +0200 (MEST) Message-ID: <3F1E33E7.7050104@Sun.com> Date: Wed, 23 Jul 2003 09:06:15 +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: Leif Johansson CC: "Kurt D. Zeilenga" , ldapext@ietf.org Subject: Re: [ldapext] Assert I-D. References: <3F1D3205.3090905@Sun.com> <3F1D8FB4.4090902@it.su.se> 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 Leif Johansson wrote: > Ludovic Poitou wrote: > >> Hi Kurt, > > > > >> >> Can you explain why you want to support Assert on the Add operation ? > > > > I guess you could assert the parent... > > MVH leifj I agree, but this is not explicit in the Assert draft. and it's in contradiction with the text that specify that the Assertion is done on the Target entry. For an Add, the target is the entry to add, not the parent. Ludovic. -- 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 Wed Jul 23 11:53:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16220 for ; Wed, 23 Jul 2003 11:06:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLBq-00064D-Fw; Wed, 23 Jul 2003 11:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKIt-0003dc-Ke for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 10:09: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 KAA13865 for ; Wed, 23 Jul 2003 10:09:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKIr-0004wi-00 for ldapext@ietf.org; Wed, 23 Jul 2003 10:09:13 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19fKIg-0004wD-00 for ldapext@ietf.org; Wed, 23 Jul 2003 10:09:02 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6NE8Nxk026236; Wed, 23 Jul 2003 07:08:23 -0700 (PDT) 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 h6NE8Me17266; Wed, 23 Jul 2003 16:08:22 +0200 (MEST) Message-ID: <3F1E96D6.7080200@Sun.com> Date: Wed, 23 Jul 2003 16:08:22 +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: Leif Johansson CC: "Kurt D. Zeilenga" , ldapext@ietf.org Subject: Re: [ldapext] Assert I-D. References: <5.2.0.9.0.20030723153600.01b94600@127.0.0.1> <3F1E92E7.5060007@it.su.se> 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 Leif Johansson wrote: > Kurt D. Zeilenga wrote: > >> >> >> I think that the control should not be applicable to Add. >> I'll update the next revision to reflect this. >> >> > > Hmm, actually it might make sense if you have attributes which are > generated when the entry is added but are not part of the entry sent > from the client. In that case, you may want to retrieve these attributes, not to assert on them. Ludovic > > MVH leifj > -- 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 Wed Jul 23 15:46:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28731 for ; Wed, 23 Jul 2003 15:46:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPYn-0002t4-MH; Wed, 23 Jul 2003 15:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPYi-0002sf-4W for ldapext@optimus.ietf.org; Wed, 23 Jul 2003 15:45: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 PAA28702 for ; Wed, 23 Jul 2003 15:45:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fPYg-0007iF-00 for ldapext@ietf.org; Wed, 23 Jul 2003 15:45:54 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19fPYV-0007hC-00 for ldapext@ietf.org; Wed, 23 Jul 2003 15:45:43 -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 h6NJihc6085495; Wed, 23 Jul 2003 19:44:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030723213424.01d56cc0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 23 Jul 2003 21:41:26 +0200 To: "Vithalprasad Gaitonde" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Assert I-D. Cc: 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 04:36 PM 7/23/2003, Vithalprasad Gaitonde wrote: >But then assert has to be after the add but Kurt says its BEFORE. I concur. The server is free to incorporate generated attributes (e.g., createTimestamp) before, after, or during the addition of the user-specified attributes. Exactly when is a local matter, the server just has to do the addition as part of the DIT modification. The assertion is to be applied prior to, but atomically with, the DIT modification. Kurt >Hmm, actually it might make sense if you have attributes which are >generated when the entry is added but are not part of the entry sent >from the client. > > MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Jul 24 03:49:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27774 for ; Thu, 24 Jul 2003 03:49:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fapU-00024h-NY; Thu, 24 Jul 2003 03:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19faoe-00023r-G6 for ldapext@optimus.ietf.org; Thu, 24 Jul 2003 03:47:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27720 for ; Thu, 24 Jul 2003 03:47:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19faoc-00043S-00 for ldapext@ietf.org; Thu, 24 Jul 2003 03:47:06 -0400 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 19faoR-00043J-00 for ldapext@ietf.org; Thu, 24 Jul 2003 03:46:55 -0400 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 24 Jul 2003 01:46:21 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Thu, 24 Jul 2003 01:46:07 -0600 From: "Vithalprasad Gaitonde" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [ldapext] LDAP Increment via Modify operation 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 Hi Kurt, Has this draft been submitted which we disucussed in the bar BOF meeting. I couldn't find it on the site. BTW, does it allow doing "append" for string/text attributes just increment for integer attributes. I was thinking an append could make sense for some attributes. Thanks, Prasad _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Jul 25 02:42:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25967 for ; Fri, 25 Jul 2003 02:42:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fwGD-00045l-Bd; Fri, 25 Jul 2003 02:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fwFP-00044t-GF for ldapext@optimus.ietf.org; Fri, 25 Jul 2003 02:40:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25917 for ; Fri, 25 Jul 2003 02:40:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fwFJ-0005jY-00 for ldapext@ietf.org; Fri, 25 Jul 2003 02:40:05 -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 19fwF8-0005jR-00 for ldapext@ietf.org; Fri, 25 Jul 2003 02:39:54 -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 h6P6dRc6099658; Fri, 25 Jul 2003 06:39:29 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030725083227.01d56f60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 25 Jul 2003 08:36:10 +0200 To: "Vithalprasad Gaitonde" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] LDAP Increment via Modify operation Cc: 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 09:46 AM 7/24/2003, Vithalprasad Gaitonde wrote: > Has this draft been submitted which we disucussed in the bar BOF >meeting. I couldn't find it on the site. I have not yet submitted this. >BTW, does it allow doing >"append" for string/text attributes just increment for integer >attributes. No. It is modeled after the DAP modify/increment capability which is defined only for attribute types of syntax INTEGER and REAL. >I was thinking an append could make sense for some attributes. I rather leave "append" to another document. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext