From sip-admin@ietf.org Fri Nov 1 10:08:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15353 for ; Fri, 1 Nov 2002 10:08:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1FAiv21118 for ; Fri, 1 Nov 2002 10:10:44 -0500 Date: Fri, 01 Nov 2002 10:10:44 -0500 Message-ID: <20021101151044.25483.4059.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. *************************************************************************** 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 Fri Nov 1 18:57:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09380 for ; Fri, 1 Nov 2002 18:57:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1NwCv14149; Fri, 1 Nov 2002 18:58:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1Nuwv14085 for ; Fri, 1 Nov 2002 18:56:58 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09274 for ; Fri, 1 Nov 2002 18:54:26 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 01 Nov 2002 16:56:51 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Fri, 01 Nov 2002 16:56:28 -0700 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] VLV: additional questions? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA1Nuwv14086 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit >>>> "Kurt D. Zeilenga" 09/26/02 12:46AM >>> >VLV: >>Note that it is possible that no entry satisfies these conditions, >>in which case there is no target entry. > >What does the server return when there is no target entry? This condition is indicated by the server returning the special value contentCount + 1 in the target position field >-- > >Under what circumstances would the server return targetPosition = 0 ? I don't know. We should probably set the min to 1. >-- > >In byoffset: Is offset > contentCount > 0 an error condition? protocolError? Should error, I'll add language. >-- > >If 0 > sizelimit > (beforeCount + afterCount + 1), is >sizeLimitExceeded returned? Not unless the size limit is exceeded. If sizelimit = 50, offset = 1, beforeCount = 100, afterCount = 10, you will get back 11 entries. >-- > >> Si = Sc * (Ci / Cc) > >What if this equation evaluates to zero? How would that happen? Jim > >Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Nov 1 20:26:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11516 for ; Fri, 1 Nov 2002 20:26:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA21SAv19245; Fri, 1 Nov 2002 20:28:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA21RLv19208 for ; Fri, 1 Nov 2002 20:27:21 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11455 for ; Fri, 1 Nov 2002 20:24:48 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 01 Nov 2002 18:27:13 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Fri, 01 Nov 2002 18:27:06 -0700 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] VLV: Cc/Ci special cases Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA21RLv19209 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I agree. >>> "Kurt D. Zeilenga" 09/25/02 10:32PM >>> > The following special cases exist when the client is specifying the > offset and content count: > - an offset of one and a content count of non-one (Ci = 1, Cc != 1) > indicates that the target is the first entry in the list. > - equivalent values (Ci = Cc) indicate that the target is the last > entry in the list. > - a content count of zero, and a non-zero offset (Cc = 0, Ci != 0) > means the client has no idea what the content count is, the server > MUST use its own content count estimate in place of the client's. >From this, (Ci = 0, Cc = 0) indicates the target is the last entry but what does (Ci = 0, Cc != 0) indicate? It may be appropriate to eliminate Ci = 0 as valid. That is, change byoffset to: byoffset [0] SEQUENCE { offset INTEGER (1 .. maxInt), contentCount INTEGER (0 .. maxInt) }, Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Nov 1 22:25:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14953 for ; Fri, 1 Nov 2002 22:25:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA23ONv25256; Fri, 1 Nov 2002 22:24:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA23NQv25237 for ; Fri, 1 Nov 2002 22:23:26 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14923 for ; Fri, 1 Nov 2002 22:20:53 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 01 Nov 2002 20:23:17 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Fri, 01 Nov 2002 20:22:18 -0700 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] VLV: MUST Sort Control Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA23NQv25238 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I'm revising the draft to capture what I believe consensus currently is. What I have not done yet is to address this issue, and some of the error handling issues. The latter should be trivial, but the former will require a quite a number of edits and I need to gauge consensus before proceeding. So... I don't mind rewording the draft such that SSS is optional but recommended. The current incarnation of typedown will not work if SSS is not provided, but I think we can just make that statement. We would also add that some server implementations don't support VLV in the absence of SSS, and they will make use of the sortControlMissing virtualListViewResult value. Is there a strong opposition in going this route? In the meantime, I will publish what's been done so far. Jim >>> "Kurt D. Zeilenga" 09/25/02 11:58AM >>> I believe that VLV should be designed such that a client need not request sorting of entries. Just as one can page through unsorted results using Simple Page control [RFC2696], one should be able to VLV through unsorted results. All that is necessary is for the server to provide some repeatable ordering of the entries involved. In many servers, the server maintains all entries in this fashion. In other servers, the server may need to maintain the order in some context specific way. The contextID feature allows for this. And, in servers which only care to support VLV where a sort control has been provided, the server can return an appropriate error (which has been defined in the I-D). I suggest VLV only RECOMMEND implementation of RFC 2891 and that VLV not require the sort control be provided. With this change, the VLV operation would provide all the functionality of the Simple Page control. This would allow the RFC 2696 (Informational) to be obsoleted in favor of a Standard Track approach. Otherwise, it will likely be necessary to revise RFC 2696 for publication on the Standard Track. Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Nov 1 23:10:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16158 for ; Fri, 1 Nov 2002 23:10:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA24C5v27634; Fri, 1 Nov 2002 23:12:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA24B4v27596 for ; Fri, 1 Nov 2002 23:11:04 -0500 Received: from blackbear.mtbrook.boreham.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16134 for ; Fri, 1 Nov 2002 23:08:31 -0500 (EST) Received: from racoon ([192.168.10.34]) by blackbear.mtbrook.boreham.org with Microsoft SMTPSVC(5.0.2195.5329); Fri, 1 Nov 2002 20:12:09 -0800 Message-ID: <0c9401c28225$fef22c80$220aa8c0@mtbrook.boreham.org> From: "David Boreham" To: References: Subject: Re: [ldapext] VLV: MUST Sort Control Date: Fri, 1 Nov 2002 20:12:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 02 Nov 2002 04:12:09.0141 (UTC) FILETIME=[030DF650:01C28226] 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 > Is there a strong opposition in going this route? It works for me. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Nov 4 07:44:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10888 for ; Mon, 4 Nov 2002 07:44:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Cjlv23425; Mon, 4 Nov 2002 07:45:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Ci7v23362 for ; Mon, 4 Nov 2002 07:44:07 -0500 Received: from e1.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10837; Mon, 4 Nov 2002 07:41:38 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA4Ci4bM146436; Mon, 4 Nov 2002 07:44:04 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA4Ci2t0072698; Mon, 4 Nov 2002 07:44:02 -0500 Subject: Re: [ldapext] VLV: MUST Sort Control Cc: ldapext@ietf.org, ldapext-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: John McMeeking Date: Mon, 4 Nov 2002 06:44:01 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0|September 26, 2002) at 11/04/2002 06:44:03 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: , Optional sort control works for me. John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Nov 4 17:08:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09754 for ; Mon, 4 Nov 2002 17:08:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4M9Hv09737; Mon, 4 Nov 2002 17:09:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4M8jv09715 for ; Mon, 4 Nov 2002 17:08:45 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09656 for ; Mon, 4 Nov 2002 17:06:11 -0500 (EST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.5/8.12.5) with ESMTP id gA4M8bDH098637; Mon, 4 Nov 2002 22:08:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021104140722.02932830@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Nov 2002 14:07:58 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] VLV: additional questions? 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 03:56 PM 2002-11-01, Jim Sermersheim wrote: >>-- >> >>> Si = Sc * (Ci / Cc) >> >>What if this equation evaluates to zero? > >How would that happen? Let Sc be zero. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Nov 4 18:01:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12985 for ; Mon, 4 Nov 2002 18:01:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4N2Gv12944; Mon, 4 Nov 2002 18:02:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4N1nv12896 for ; Mon, 4 Nov 2002 18:01:49 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12917 for ; Mon, 4 Nov 2002 17:59:14 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 04 Nov 2002 16:01:42 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Mon, 04 Nov 2002 16:01:23 -0700 From: "Jim Sermersheim" To: Cc: Subject: Re: [ldapext] VLV: additional questions? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA4N1nv12897 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit If Sc is zero, then no entries will be returned anyway. >>> "Kurt D. Zeilenga" 11/04/02 03:07PM >>> At 03:56 PM 2002-11-01, Jim Sermersheim wrote: >>-- >> >>> Si = Sc * (Ci / Cc) >> >>What if this equation evaluates to zero? > >How would that happen? Let Sc be zero. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Nov 5 06:14:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11629 for ; Tue, 5 Nov 2002 06:14:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5BF7v01221; Tue, 5 Nov 2002 06:15:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5B9Mv00806 for ; Tue, 5 Nov 2002 06:09:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10392; Tue, 5 Nov 2002 06:06:51 -0500 (EST) Message-Id: <200211051106.GAA10392@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Nov 2002 06:06:51 -0500 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-adlist-03.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-03.txt Pages : 5 Date : 2002-11-4 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-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-adlist-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-adlist-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-4171648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-adlist-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-adlist-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171648.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Nov 5 06:14:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11645 for ; Tue, 5 Nov 2002 06:14:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5BF5v01198; Tue, 5 Nov 2002 06:15:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5B9Hv00796 for ; Tue, 5 Nov 2002 06:09:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10380; Tue, 5 Nov 2002 06:06:46 -0500 (EST) Message-Id: <200211051106.GAA10380@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Nov 2002 06:06:46 -0500 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-authzid-08.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP 'Who am I?' Operation Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-authzid-08.txt Pages : 7 Date : 2002-11-4 This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity which the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP 'Who am I?' operation A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-authzid-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zeilenga-ldap-authzid-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-authzid-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-4171638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-authzid-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-authzid-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171638.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Nov 5 06:14:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11668 for ; Tue, 5 Nov 2002 06:14:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5BF1v01167; Tue, 5 Nov 2002 06:15:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5B9Cv00788 for ; Tue, 5 Nov 2002 06:09:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10354; Tue, 5 Nov 2002 06:06:42 -0500 (EST) Message-Id: <200211051106.GAA10354@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Nov 2002 06:06:41 -0500 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-rfc2596-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 : Language Tags and Ranges in LDAP Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-rfc2596-02.txt Pages : 15 Date : 2002-11-4 It is often desirable to to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-rfc2596-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-rfc2596-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-rfc2596-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: <2002-11-4171624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-rfc2596-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-rfc2596-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171624.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 Nov 6 06:39:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13350 for ; Wed, 6 Nov 2002 06:39:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BeRv04998; Wed, 6 Nov 2002 06:40:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BX7v03946 for ; Wed, 6 Nov 2002 06:33:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12438; Wed, 6 Nov 2002 06:30:35 -0500 (EST) Message-Id: <200211061130.GAA12438@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, 06 Nov 2002 06:30:35 -0500 Subject: [ldapext] I-D ACTION:draft-ietf-ldapext-ldapv3-vlv-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. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : LDAP Extensions for Scrolling View Browsing of Search Result Author(s) : D. Boreham, J. Sermersheim, A. Kashi Filename : draft-ietf-ldapext-ldapv3-vlv-09.txt Pages : 13 Date : 2002-11-5 This document describes a Virtual List View extension for the Lightweight Directory Access Protocol (LDAP) Search operation. This extension is designed to allow the 'virtual list box' feature, common in existing commercial e-mail address book applications, to be supported efficiently by LDAP servers. LDAP servers' inability to support this client feature is a significant impediment to LDAP replacing proprietary protocols in commercial e-mail systems. The extension allows a client to specify that the server return, for a given LDAP search with associated sort keys, a contiguous subset of the search result set. This subset is specified in terms of offsets into the ordered list, or in terms of a greater than or equal comparison value. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-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-ietf-ldapext-ldapv3-vlv-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-ietf-ldapext-ldapv3-vlv-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: <2002-11-5193338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldapv3-vlv-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193338.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Nov 8 02:24:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08882 for ; Fri, 8 Nov 2002 02:24:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA87Pgv00669; Fri, 8 Nov 2002 02:25:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KZ3v15459 for ; Thu, 7 Nov 2002 15:35:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: [ldapext] Note Well Statement 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: , >From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== 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. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Nov 13 01:55:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29297 for ; Wed, 13 Nov 2002 01:55:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD6ukv31056; Wed, 13 Nov 2002 01:56:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD6tHv30999 for ; Wed, 13 Nov 2002 01:55:17 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29275 for ; Wed, 13 Nov 2002 01:52:34 -0500 (EST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gAD6t6F3048665 for ; Wed, 13 Nov 2002 06:55:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021112225422.035409f8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 22:54:34 -0800 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ldapext] Call for comments: Language Tags and Ranges in LDAP (RFC2596bis) Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , I have prepared: Language Tags and Ranges in LDAP draft-zeilenga-ldap-rfc2596-02.txt To ensure that this Individual submission is ready for IESG consideration for publication as a Proposed Standard (obsoleting RFC 2596), please review and comment before the end of the month. Please send technical comments to this list. Please send editorial comments directly to me. Thanks, Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Nov 13 12:09:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08815 for ; Wed, 13 Nov 2002 12:09:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADH9Nv14083; Wed, 13 Nov 2002 12:09:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADH87v14001 for ; Wed, 13 Nov 2002 12:08:07 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08663 for ; Wed, 13 Nov 2002 12:05:27 -0500 (EST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gADH81F3051923 for ; Wed, 13 Nov 2002 17:08:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021113084928.035fdc18@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Nov 2002 09:07:28 -0800 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Call for comments: Language Tags and Ranges in LDAP (RFC2596bis) In-Reply-To: <5.1.0.14.0.20021112225422.035409f8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , It's come to my attention that three paragraphs got mangled in this revision. The remainder of the document are as intended. As only background information was affected, please continue to review and comment on the I-D, but with changes noted below. The first paragraph of Section 1.1 should read: Section 2 of BCP 47 [RFC3066] describes the language tag format which is used in LDAP. Briefly, it is a string of ASCII letters and hyphens. Examples include "fr", "en-US" and "ja-JP". Language tags are case insensitive. For example, the language tag "en-us" is the same as "EN-US". The second paragraph of Section 1.2 should read: A language range matches a language tag if it is exactly equal to the tag, or if it is exactly equal to a prefix of the tag such that the first character following the prefix is "-". The special tag "*" matches all tags. The third paragraph of Section 1.3 should read: An attribute with one or more tagging options is a direct subtype of each attribute of the same with all but one of the tagging options. If the attribute's type is a direct subtype of some other type, then the attribute is also a direct subtype of the attribute whose description consists of the supertype and all of the tagging options. That is, "CN;x-bar;x-foo" is a direct subtype of "CN;x-bar", "CN;x-foo", and "name;x-bar;x-foo". Note that "CN" is a subtype of "name". At 10:54 PM 2002-11-12, Kurt D. Zeilenga wrote: >I have prepared: > Language Tags and Ranges in LDAP > draft-zeilenga-ldap-rfc2596-02.txt > >To ensure that this Individual submission is ready for IESG >consideration for publication as a Proposed Standard >(obsoleting RFC 2596), please review and comment before the >end of the month. > >Please send technical comments to this list. >Please send editorial comments directly to me. > >Thanks, Kurt > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Nov 13 12:23:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09400 for ; Wed, 13 Nov 2002 12:23:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHO5v15039; Wed, 13 Nov 2002 12:24:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHNZv14996 for ; Wed, 13 Nov 2002 12:23:35 -0500 Received: from mons.uio.no (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09330 for ; Wed, 13 Nov 2002 12:20:56 -0500 (EST) Received: from bombur.uio.no ([129.240.186.42]) by mons.uio.no with esmtp (Exim 2.12 #7) id 18C1Ee-0001gW-00; Wed, 13 Nov 2002 18:23:28 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18C1Ed-0004lZ-00; Wed, 13 Nov 2002 18:23:27 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ldapext@ietf.org Subject: Re: [ldapext] Call for comments: Language Tags and Ranges in LDAP (RFC2596bis) In-Reply-To: <5.1.0.14.0.20021113084928.035fdc18@127.0.0.1> References: <5.1.0.14.0.20021112225422.035409f8@127.0.0.1> <5.1.0.14.0.20021113084928.035fdc18@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 13 Nov 2002 18:23:27 +0100 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 writes: > The second paragraph of Section 1.2 should read: > A language range matches a language tag if it is exactly equal to > the tag, or if it is exactly equal to a prefix of the tag such that > the first character following the prefix is "-". The special tag > "*" matches all tags. "*" does not match in RFC2251 section 4.1.5 (Attribute Description): ::= ASCII-equivalent letters, numbers and hyphen Also, if "*" matches all tags and not just all language tags, that belongs in an RFC about tags in general (i.e. with a more general title than language tags). If you just meant to match all language tags, "lang-" is enough. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Nov 13 12:35:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09649 for ; Wed, 13 Nov 2002 12:35:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHX3v15382; Wed, 13 Nov 2002 12:33:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHWtv15363 for ; Wed, 13 Nov 2002 12:32:55 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09567 for ; Wed, 13 Nov 2002 12:30:15 -0500 (EST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gADHWlF3052148; Wed, 13 Nov 2002 17:32:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20021113092441.035fdad0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Nov 2002 09:32:06 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Call for comments: Language Tags and Ranges in LDAP (RFC2596bis) Cc: ldapext@ietf.org In-Reply-To: References: <5.1.0.14.0.20021113084928.035fdc18@127.0.0.1> <5.1.0.14.0.20021112225422.035409f8@127.0.0.1> <5.1.0.14.0.20021113084928.035fdc18@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Hallvard, I think you are taking this paragraph out of context. The paragraph is providing an overview of language ranges as described in BCP 47. Please reread all of Section 1.2 with the second paragraph replaced as indicated. Kurt At 09:23 AM 2002-11-13, Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: >> The second paragraph of Section 1.2 should read: >> A language range matches a language tag if it is exactly equal to >> the tag, or if it is exactly equal to a prefix of the tag such that >> the first character following the prefix is "-". The special tag >> "*" matches all tags. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Nov 13 12:38:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09799 for ; Wed, 13 Nov 2002 12:38:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHd8v16171; Wed, 13 Nov 2002 12:39:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHcev16145 for ; Wed, 13 Nov 2002 12:38:40 -0500 Received: from pat.uio.no (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09667 for ; Wed, 13 Nov 2002 12:36:00 -0500 (EST) Received: from bombur.uio.no ([129.240.186.42]) by pat.uio.no with esmtp (Exim 2.12 #7) id 18C1TA-0000Xe-00; Wed, 13 Nov 2002 18:38:28 +0100 Received: from hbf by bombur.uio.no with local (Exim 2.12 #7) id 18C1T9-0004oZ-00; Wed, 13 Nov 2002 18:38:27 +0100 From: Hallvard B Furuseth Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kurt D. Zeilenga" Cc: ldapext@ietf.org Subject: Re: [ldapext] Call for comments: Language Tags and Ranges in LDAP (RFC2596bis) In-Reply-To: <5.1.0.14.0.20021113092441.035fdad0@127.0.0.1> References: <5.1.0.14.0.20021113084928.035fdc18@127.0.0.1> <5.1.0.14.0.20021112225422.035409f8@127.0.0.1> <5.1.0.14.0.20021113092441.035fdad0@127.0.0.1> X-Mailer: VM 6.37 under Emacs 19.34.1 Date: Wed, 13 Nov 2002 18:38:27 +0100 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 writes: > The paragraph is providing an overview of language ranges as > described in BCP 47. Oh. I commented on the wrong error. > The second paragraph of Section 1.2 should read: > A language range matches a language tag if it is exactly equal to > the tag, or if it is exactly equal to a prefix of the tag such that > the first character following the prefix is "-". The special tag ^^^^ should be "range" > "*" matches all tags. Though I suggest you add to the paragraph: ", but is written as "lang-" in LDAP." -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Nov 20 13:15:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26433 for ; Wed, 20 Nov 2002 13:15:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKIG2v02232; Wed, 20 Nov 2002 13:16:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKI5bv01184 for ; Wed, 20 Nov 2002 13:05:37 -0500 Received: from SOTTMXS01.entrust.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26178 for ; Wed, 20 Nov 2002 13:02:53 -0500 (EST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Wed, 20 Nov 2002 13:05:32 -0500 Message-ID: <59EA87B07385D611A32D00D0B76953972419D0@scygmxs01.cygnacom.com> From: Shari Galitzer To: "'ldapext@ietf.org'" Date: Wed, 20 Nov 2002 12:57:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C290BE.3E8980E0" Subject: [ldapext] information on access control Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C290BE.3E8980E0 Content-Type: text/plain; charset="iso-8859-1" Hi, I'm trying to find some information on current efforts to specify standards for access control for LDAP directories. I see access control is an area being worked on but cannot find any information. Can you point me to some information? Thanks a lot, Shari Galitzer Principal Security Engineer Phone: 608-251-6414 Fax: 608-663-6332 Entrust/CygnaCom ------_=_NextPart_001_01C290BE.3E8980E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable information on access control

Hi,

I'm trying to find some information on = current efforts to specify standards for access control for LDAP = directories.  I see access control is an area being worked on but = cannot find any information.  Can you point me to some = information?

Thanks a lot,
Shari Galitzer
Principal Security Engineer
Phone: 608-251-6414
Fax: 608-663-6332
Entrust/CygnaCom

------_=_NextPart_001_01C290BE.3E8980E0-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Nov 20 13:45:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27064 for ; Wed, 20 Nov 2002 13:45:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKIk5v04241; Wed, 20 Nov 2002 13:46:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKIh6v04120 for ; Wed, 20 Nov 2002 13:43:06 -0500 Received: from klapautius.it.su.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26978 for ; Wed, 20 Nov 2002 13:40:21 -0500 (EST) Received: from it.su.se (localhost [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id gAKIgtP23713; Wed, 20 Nov 2002 19:42:56 +0100 Message-ID: <3DDBD7AF.50409@it.su.se> Date: Wed, 20 Nov 2002 19:42:55 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shari Galitzer CC: "'ldapext@ietf.org'" Subject: Re: [ldapext] information on access control References: <59EA87B07385D611A32D00D0B76953972419D0@scygmxs01.cygnacom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-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 Shari Galitzer wrote: > Hi, > > I'm trying to find some information on current efforts to specify > standards for access control for LDAP directories. I see access control > is an area being worked on but cannot find any information. Can you > point me to some information? > There is only one individual draft submission from Steven Legg on use of X.500 acl. Other than that, no work is beeing done (to my knowledge). draft-legg-ldap-acm-admin-01.txt draft-legg-ldap-acm-bac-01.txt draft-legg-ldap-admin-00.txt MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Nov 20 18:21:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04543 for ; Wed, 20 Nov 2002 18:21:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKNMGv23869; Wed, 20 Nov 2002 18:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKNJsv23758 for ; Wed, 20 Nov 2002 18:19:54 -0500 Received: from clmboh1-smtp5.columbus.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04473 for ; Wed, 20 Nov 2002 18:16:37 -0500 (EST) Received: from willeke.com (dhcp024-166-083-155.neo.rr.com [24.166.83.155]) by clmboh1-smtp5.columbus.rr.com (8.11.2/8.11.2) with ESMTP id gAKNJ8H26941; Wed, 20 Nov 2002 18:19:09 -0500 (EST) Message-ID: <3DDC1857.3080500@willeke.com> Date: Wed, 20 Nov 2002 18:18:47 -0500 From: Jim Willeke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shari Galitzer , "'ldapext@ietf.org'" Subject: Re: [ldapext] information on access control References: <59EA87B07385D611A32D00D0B76953972419D0@scygmxs01.cygnacom.com> In-Reply-To: <59EA87B07385D611A32D00D0B76953972419D0@scygmxs01.cygnacom.com> 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 There was some work going on in the LDUP groups related to replication. The last draft I could find was 08 and it has expired. http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-08.txt I see Chris Apple has an Article at: http://article.gmane.org/gmane.ietf.ldup/112 -jim Shari Galitzer wrote: > Hi, > > I'm trying to find some information on current efforts to specify > standards for access control for LDAP directories. I see access > control is an area being worked on but cannot find any information. > Can you point me to some information? > > Thanks a lot, > *Shari Galitzer* > Principal Security Engineer > Phone: 608-251-6414 > Fax: 608-663-6332 > > Entrust/CygnaCom > _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Nov 21 04:51:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26820 for ; Thu, 21 Nov 2002 04:51:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL9q4v02643; Thu, 21 Nov 2002 04:52:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL9mRv02539 for ; Thu, 21 Nov 2002 04:48:27 -0500 Received: from npscomgftp.netpro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26759 for ; Thu, 21 Nov 2002 04:45:21 -0500 (EST) Received: from npntmail.home.netpro.com ([10.1.20.13]) by npscomgftp.netpro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 02:52:16 -0700 Received: by NPNTMAIL with Internet Mail Service (5.5.2656.59) id ; Thu, 21 Nov 2002 02:44:32 -0700 Message-ID: From: Gil Kirkpatrick To: "'Leif Johansson'" , Shari Galitzer Cc: "'ldapext@ietf.org'" Subject: RE: [ldapext] information on access control Date: Thu, 21 Nov 2002 02:44:24 -0700 X-Mailer: Internet Mail Service (5.5.2656.59) X-OriginalArrivalTime: 21 Nov 2002 09:52:16.0548 (UTC) FILETIME=[ACAA6640:01C29143] 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: , You might check into the SAML (Security Assertion Markup Language) at oasis-open.org. LDAP vendors seem to be gravitating to DSML and SAML. -gil -----Original Message----- From: Leif Johansson [mailto:leifj@it.su.se] Sent: Wednesday, November 20, 2002 11:43 AM To: Shari Galitzer Cc: 'ldapext@ietf.org' Subject: Re: [ldapext] information on access control Shari Galitzer wrote: > Hi, > > I'm trying to find some information on current efforts to specify > standards for access control for LDAP directories. I see access control > is an area being worked on but cannot find any information. Can you > point me to some information? > There is only one individual draft submission from Steven Legg on use of X.500 acl. Other than that, no work is beeing done (to my knowledge). draft-legg-ldap-acm-admin-01.txt draft-legg-ldap-acm-bac-01.txt draft-legg-ldap-admin-00.txt 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 Thu Nov 21 08:56:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02178 for ; Thu, 21 Nov 2002 08:56:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALDvNv16019; Thu, 21 Nov 2002 08:57:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL9kCv02477 for ; Thu, 21 Nov 2002 04:46:12 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26700 for ; Thu, 21 Nov 2002 04:42:50 -0500 (EST) Received: from odin.France.Sun.COM ([129.157.174.8]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23022; Thu, 21 Nov 2002 01:45:28 -0800 (PST) Received: from sun.com (hamble [129.157.192.53]) by odin.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id gAL9jRv09851; Thu, 21 Nov 2002 10:45:27 +0100 (MET) Message-ID: <3DDCAA1F.41BD8D41@sun.com> Date: Thu, 21 Nov 2002 10:40:47 +0100 From: Rob Byrne - Sun Microsystems Reply-To: robert.byrne@sun.com X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shari Galitzer CC: "'ldapext@ietf.org'" Subject: Re: [ldapext] information on access control References: <59EA87B07385D611A32D00D0B76953972419D0@scygmxs01.cygnacom.com> Content-Type: multipart/alternative; boundary="------------37F0D07290C3122CFC28F3B5" 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: , --------------37F0D07290C3122CFC28F3B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shari, I'm sure others will point you to any recent documents issued on this (LDUP, Stephens's x.500 acl usage etc.). The Open group also appears to be dabbling in this area.... However to give you some perspective as a directory vendor...we feel that the opportunity has been missed for standard LDAP acl and that the level of inter-vendor integration/synchronization implied by a standard acl model (and repl model) will more realistically be achived by meta directory/directory proxy type solutions. You will find discussions on this on this list's archive (eg. subject: moving access control discussion to LDUP) or on the LDUP archive. Rob. Shari Galitzer wrote: > > > Hi, > > I'm trying to find some information on current efforts to specify > standards for access control for LDAP directories. I see access > control is an area being worked on but cannot find any information. > Can you point me to some information? > > Thanks a lot, > Shari Galitzer > Principal Security Engineer > Phone: 608-251-6414 > Fax: 608-663-6332 > > Entrust/CygnaCom --------------37F0D07290C3122CFC28F3B5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Shari,

I'm sure others will point you to any recent documents issued on this (LDUP, Stephens's x.500 acl usage etc.).  The Open group also appears to be dabbling in this area....

However to give you some perspective as a directory vendor...we feel that the opportunity has been missed for standard LDAP acl and that the level of inter-vendor integration/synchronization implied by a standard acl model (and repl model) will more realistically be achived by meta directory/directory proxy type solutions.

You will find discussions on this on this list's archive (eg. subject: moving access control discussion to LDUP) or on the LDUP archive.

Rob.

Shari Galitzer wrote:

 

Hi,

I'm trying to find some information on current efforts to specify standards for access control for LDAP directories.  I see access control is an area being worked on but cannot find any information.  Can you point me to some information?

Thanks a lot,
Shari Galitzer
Principal Security Engineer
Phone: 608-251-6414
Fax: 608-663-6332

Entrust/CygnaCom

--------------37F0D07290C3122CFC28F3B5-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Nov 21 08:58:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02241 for ; Thu, 21 Nov 2002 08:58:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALDxav16136; Thu, 21 Nov 2002 08:59:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALB0Fv06068 for ; Thu, 21 Nov 2002 06:00:15 -0500 Received: from softerra.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27814 for ; Thu, 21 Nov 2002 05:56:54 -0500 (EST) Received: from diana (diana.softerra.int [192.168.100.252]) by softerra.com (8.11.0/8.11.0) with SMTP id gALB10Q18227 for ; Thu, 21 Nov 2002 13:01:01 +0200 From: "Diana" To: Date: Thu, 21 Nov 2002 12:59:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [ldapext] LDAP Administrator - free LDAP Client for Win 32 Platform enables you to view, edit and navigate through LDAP directories 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 Dear Sir, Dear Madam, I am excited to announce the Release of LDAP Administrator 2.4, the new "Explorer-like" LDAP Client, which enables you to view, edit, analyse and navigate through LDAP Directories easily and effectively. LDAP Administrator is free LDAP Client made for Win 32 Platform presents full connection and support to modern LDAP v2 and v3 Server such as Active Directory, Novell Directory Services or Netscape/iPlanet. LDAP Browser being a lightweight version of LDAP Administrator, has a limitated functionality and not allow its users to modify LDAP Directories. Unlike the commercially distributed LDAP Administrator, LDAP Browser is a freeware. Evaluate LDAP Administrator/LDAP Browser 2.4 for free at: http://www.ldapadministrator.com/download/download.php To get more information about how to manage your LDAP Directories successfully, visit http://www.ldapadministrator.com/prodinfo/prodinfo.php or contact me any time. With the warm and kind reguards, Diana Pusik Softerra LLC Kharkov, UA mailto:dpusik@softerra.com http://www.softerra.com _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Nov 21 12:48:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12295 for ; Thu, 21 Nov 2002 12:48:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALHnKv01757; Thu, 21 Nov 2002 12:49:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALHkiv01583 for ; Thu, 21 Nov 2002 12:46:44 -0500 Received: from e6.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12092 for ; Thu, 21 Nov 2002 12:43:44 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gALHkMqJ201522; Thu, 21 Nov 2002 12:46:22 -0500 Received: from d03nm143.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gALHkKFP058738; Thu, 21 Nov 2002 12:46:20 -0500 Importance: Normal Subject: Re: [ldapext] information on access control To: robert.byrne@sun.com Cc: Shari Galitzer , "'ldapext@ietf.org'" From: George Robert Blakley III Date: Thu, 21 Nov 2002 11:49:26 -0600 Message-ID: X-MIMETrack: Serialize by Router on D03NM143/03/M/IBM(Release 6.0 [IBM]|November 8, 2002) at 11/21/2002 10:46:22 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gALHkiv01584 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Shari, Here's the complete list of access control standards I've personally been involved in. Open Group aznAPI (you can view HTML free but have to pay for .PDF): http://www.opengroup.org/publications/catalog/c908.htm OMG CORBAsecurity (contains access control interfaces; for a better description buy my book "CORBA Security"): http://www.omg.org/cgi-bin/doc?formal/2002-03-11 OMG RAD (Resource Access Decision) http://www.omg.org/cgi-bin/doc?formal/2001-04-01 OASIS SAML (Security Assertions Markup Language); this isn't an access control specification per se but allows an authorization decision service to consume standard subject attribute descriptions and produce standard tokens stating its decision: http://www.oasis-open.org/committees/security/ ======================= The Grand-daddy of access control specifications is the ISO Access Control Framework; no one with an interest in access control should be without a copy of this (even though you have to pay for it): http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=18199&ICS1=35&ICS2=100&ICS3=1 You may also want to look at X.500 Access Control (though I think this model has lots of problems; I can elaborate off-list if you're interested); David Chadwick is my favorite source of information on this topic http://www.isi.salford.ac.uk/staff/dwc/Version.Web/Chapter.8/Chapter8a.htm The actual specification is here: http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.500-200102-I Novell's NDS has an extremely powerful and flexible access control model; Ed Reed (who often contributes to this list) is a good source of information about it; I don't have a link to a good description online. Finally, you might want to take a look at the WebDAV access control model: http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-09.txt --bob Bob Blakley (email: blakley@us.ibm.com phone: +1 512 286-2240 fax: +1 512 286-2057) Chief Scientist, Security and Privacy, IBM Tivoli Software Rob Byrne - Sun Microsystems @ietf.org on 11/21/2002 03:40:47 AM Please respond to robert.byrne@sun.com Sent by: ldapext-admin@ietf.org To: Shari Galitzer cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] information on access control Shari, I'm sure others will point you to any recent documents issued on this (LDUP, Stephens's x.500 acl usage etc.).  The Open group also appears to be dabbling in this area.... However to give you some perspective as a directory vendor...we feel that the opportunity has been missed for standard LDAP acl and that the level of inter-vendor integration/synchronization implied by a standard acl model (and repl model) will more realistically be achived by meta directory/directory proxy type solutions. You will find discussions on this on this list's archive (eg. subject: moving access control discussion to LDUP) or on the LDUP archive. Rob. Shari Galitzer wrote: Hi, I'm trying to find some information on current efforts to specify standards for access control for LDAP directories.  I see access control is an area being worked on but cannot find any information.  Can you point me to some information? Thanks a lot, Shari Galitzer Principal Security Engineer Phone: 608-251-6414 Fax: 608-663-6332 Entrust/CygnaCom _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Nov 22 14:27:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02038 for ; Fri, 22 Nov 2002 14:27:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMJRsv03821; Fri, 22 Nov 2002 14:27:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMJHkv03424 for ; Fri, 22 Nov 2002 14:17:46 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01705 for ; Fri, 22 Nov 2002 14:15:00 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 22 Nov 2002 12:17:31 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Beta Date: Fri, 22 Nov 2002 10:16:08 -0700 From: "Jim Sermersheim" To: Cc: , , "Alan Clark" , "Hal Henderson" , , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAMJIkv03475 Subject: [ldapext] Re: Password policy state attributes Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit A group of people interested in progressing the password policy draft has been growing and exchanging emails off list. We're moving discussion here so we have a list and a wider audience. The current topic has to do with storing password policy state information for objects. What is needed is a way to store values that represent state information on an object. There is the need to associate the state information with a password. This is because it's desirable to allow multiple passwords per object, and it to be allowed that policy can be described and executed separately for each password. Thus, we need a way of associating each bit of password policy state information with the password it applies to. For example. There is an attribute called pwdExpirationWarned. This holds the timestamp of when the client was first warned that the password would expire soon, thus it is single-valued. Now, let's say the object that is subject to password policy makes use of three password attributes due to there being three different hard access interfaces: atmPassword, telePassword, and webPassword (think bank account access). When the pwdExpirationWarned attribute is updated (due to an impending password expiration), there needs to be some way of associating the warning with the password that will expire (let's say it's webPassword). Our first attempt was to use attribute descriptions with a new tagging option called "pwd-". In the example above, pwdExpirationWarned;pwd-webPassword would be used to store/retrieve the warning time for the webPassword. The problem that was brought up with this approach (as I remember it) was that since the descr form of attribute types is not canonical, we cannot use it in the attribute option. It would lead to interoperability problems. Quickly, it was suggested to just use the oid form of the attribute type, like pwdExpirationWarned;pwd-1.2.3.4. While this would solve the problem above, it is an illegal encoding. Attribute options are defined as consisting of ALPHA, DIGIT, and DASH characters. Then the suggestion of moving the attribute association inside the value was put forth say something like "webPassword#200210240212Z". This requires new syntaxes which some implementors don't like, but worse: 1) It doesn't allow the attributes to be defined as single-value. 2) It doesn't allow the server to enforce uniqueness among the values. 3) It doesn't allow the replace operation (where replace would work with single-valued attributes). None of these limitations are desirable. I would now like to suggest returning to the first or second suggestion. The first has limitations in a distributed environment, and maybe something can be done about it, but I'm not sure what. The second would be modified to fit the required syntax by replacing dots with dashes. Thus the example would change to: pwdExpirationWarned;pwd-1-2-3-4 Jim p.s. I can provide a set of recent previous discussions on this and other issues to anyone that wants them. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Nov 22 14:51:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02767 for ; Fri, 22 Nov 2002 14:51:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMJq6v05546; Fri, 22 Nov 2002 14:52:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMJhFv05219 for ; Fri, 22 Nov 2002 14:43:15 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02485 for ; Fri, 22 Nov 2002 14:40:27 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 22 Nov 2002 12:42:58 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Beta Date: Fri, 22 Nov 2002 12:43:01 -0700 From: "Ed Reed" To: , "Jim Sermersheim" Cc: , , "Alan Clark" , "Hal Henderson" , , Subject: [ldapext] Re: Password policy state attributes Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_D18D3FD2.D0B1F18B" 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. --=_D18D3FD2.D0B1F18B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable At the risk of sounding like a crackpot... =20 You may need to consider something like the X.509 certificate object class = discussed in PKIX - an entry with all the policy associated with the = particular credential - in this case a password associated with an = authentication identity. =20 The X.500 object model used in LDAP simply doesn't make it easy to = associate different policy values in one attribute with specific attribute = values in another. =20 Better to think of it this way - =20 Each password and its policy is really a user identity with some refinement= s. That can be "security equivalent" to a particular user, or perhaps = more correctly, the user entry can be "security equivalent" to the = password used to log in. The logic to support such a thing would not be = all that different from a login mechanism that allowed a user to select, = from a list of allowed roles, those roles the user wanted to assume for a = particular login session. =20 It's messy, and fundamentally changes the way people think about identities= and their credentials, but in a world where the same identity may use one = of several credentials to authenticate, and if it's beneficial to = associate different authorization rights with the individual based on = which credential they used, it may be a necessary change to consider. =20 Ed >>> "Jim Sermersheim" 11/22/02 12:16PM >>> A group of people interested in progressing the password policy draft has = been growing and exchanging emails off list. We're moving discussion here = so we have a list and a wider audience. The current topic has to do with storing password policy state information = for objects. What is needed is a way to store values that represent state = information on an object. There is the need to associate the state = information with a password. This is because it's desirable to allow = multiple passwords per object, and it to be allowed that policy can be = described and executed separately for each password. Thus, we need a way = of associating each bit of password policy state information with the = password it applies to. For example. There is an attribute called pwdExpirationWarned. This holds = the timestamp of when the client was first warned that the password would = expire soon, thus it is single-valued. Now, let's say the object that is = subject to password policy makes use of three password attributes due to = there being three different hard access interfaces: atmPassword, telePasswo= rd, and webPassword (think bank account access). When the pwdExpirationWarn= ed attribute is updated (due to an impending password expiration), there = needs to be some way of associating the warning with the password that = will expire (let's say it's webPassword). Our first attempt was to use attribute descriptions with a new tagging = option called "pwd-". In the example above, pwdExpirationWarned;pwd-webPas= sword would be used to store/retrieve the warning time for the webPassword.= The problem that was brought up with this approach (as I remember it) was = that since the descr form of attribute types is not canonical, we cannot = use it in the attribute option. It would lead to interoperability = problems. Quickly, it was suggested to just use the oid form of the attribute type, = like pwdExpirationWarned;pwd-1.2.3.4. While this would solve the problem = above, it is an illegal encoding. Attribute options are defined as = consisting of ALPHA, DIGIT, and DASH characters. Then the suggestion of moving the attribute association inside the value = was put forth say something like "webPassword#200210240212Z". This = requires new syntaxes which some implementors don't like, but worse: 1) It = doesn't allow the attributes to be defined as single-value. 2) It doesn't = allow the server to enforce uniqueness among the values. 3) It doesn't = allow the replace operation (where replace would work with single-valued = attributes). None of these limitations are desirable. I would now like to suggest returning to the first or second suggestion. = The first has limitations in a distributed environment, and maybe = something can be done about it, but I'm not sure what. The second would be = modified to fit the required syntax by replacing dots with dashes. Thus = the example would change to: pwdExpirationWarned;pwd-1-2-3-4 Jim p.s. I can provide a set of recent previous discussions on this and other = issues to anyone that wants them. _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 --=_D18D3FD2.D0B1F18B Content-Type: text/html; charset=ISO-8859-1; name="TEXT.htm" Content-Transfer-Encoding: quoted-printable
At the risk of sounding like a crackpot...
=
 
You may need to consider something like the X.509 = certificate=20 object class discussed in PKIX - an entry with all the policy associated = with=20 the particular credential - in this case a password associated with an=20 authentication identity.
 
The X.500 object model used in LDAP simply doesn't = make it=20 easy to associate different policy values in one attribute with specific=20= attribute values in another.
 
Better to think of it this way -
 
Each password and its policy is really a user identity = with=20 some refinements.  That can be "security equivalent" to a particular = user,=20 or perhaps more correctly, the user entry can be "security equivalent" to = the=20 password used to log in.  The logic to support such a thing would not = be=20 all that different from a login mechanism that allowed a user to select, = from a=20 list of allowed roles, those roles the user wanted to assume for a = particular=20 login session.
 
It's messy, and fundamentally changes the way people = think=20 about identities and their credentials, but in a world where the same = identity=20 may use one of several credentials to authenticate, and if it's beneficial = to=20 associate different authorization rights with the individual based on = which=20 credential they used, it may be a necessary change to consider.
 
Ed


>>> "Jim Sermersheim" <jimse@novell.com> = 11/22/02=20 12:16PM >>>
A group of people interested in progressing the = password=20 policy draft has been growing and exchanging emails off list. We're = moving=20 discussion here so we have a list and a wider audience.

The current = topic=20 has to do with storing password policy state information for objects. What = is=20 needed is a way to store values that represent state information on an = object.=20 There is the need to associate the state information with a password. This = is=20 because it's desirable to allow multiple passwords per object, and it to = be=20 allowed that policy can be described and executed separately for each = password.=20 Thus, we need a way of associating each bit of password policy state = information=20 with the password it applies to.

For example. There is an = attribute=20 called pwdExpirationWarned. This holds the timestamp of when the client = was=20 first warned that the password would expire soon, thus it is single-valued.= Now,=20 let's say the object that is subject to password policy makes use of = three=20 password attributes due to there being three different hard access = interfaces:=20 atmPassword, telePassword, and webPassword (think bank account access). = When the=20 pwdExpirationWarned attribute is updated (due to an impending  = password=20 expiration), there needs to be some way of associating the warning with = the=20 password that will expire (let's say it's webPassword).

Our first = attempt=20 was to use attribute descriptions with a new tagging option  called = "pwd-".=20 In the example above, pwdExpirationWarned;pwd-webPassword would be used = to=20 store/retrieve the warning time for the webPassword. The problem that = was=20 brought up with this approach (as I remember it) was that since the descr = form=20 of attribute types is not canonical, we cannot use it in the attribute = option.=20 It would lead to interoperability problems.

Quickly, it was = suggested to=20 just use the oid form of the attribute type, like=20 pwdExpirationWarned;pwd-1.2.3.4. While this would solve the problem above, = it is=20 an illegal encoding. Attribute options are defined as consisting of = ALPHA,=20 DIGIT, and DASH characters.

Then the suggestion of moving the = attribute=20 association inside the value was put forth say something like=20 "webPassword#200210240212Z". This requires new syntaxes which some = implementors=20 don't like, but worse: 1) It doesn't allow the attributes to be defined = as=20 single-value. 2) It doesn't allow the server to enforce uniqueness among = the=20 values. 3) It doesn't allow the replace operation (where replace would = work with=20 single-valued attributes). None of these limitations are desirable.

= I=20 would now like to suggest returning to the first or second suggestion. The = first=20 has limitations in a distributed environment, and maybe something can be = done=20 about it, but I'm not sure what. The second would be modified to fit = the=20 required syntax by replacing dots with dashes. Thus the example would = change to:=20 pwdExpirationWarned;pwd-1-2-3-4

Jim

p.s. I can provide a set = of=20 recent previous discussions on this and other issues to anyone that = wants=20 them.

_______________________________________________
Ldapext = mailing=20 list
Ldapext@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ldapext
--=_D18D3FD2.D0B1F18B-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Nov 22 16:51:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05027 for ; Fri, 22 Nov 2002 16:51:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMLqIv11549; Fri, 22 Nov 2002 16:52:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMLowv11528 for ; Fri, 22 Nov 2002 16:50:58 -0500 Received: from junker.stroeder.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04996 for ; Fri, 22 Nov 2002 16:47:52 -0500 (EST) Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 5689D1573CC; Fri, 22 Nov 2002 22:50:24 +0100 (CET) Message-ID: <3DDEA69F.80805@stroeder.com> Date: Fri, 22 Nov 2002 22:50:23 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Ed Reed Cc: ldapext@ietf.org, andrews@adacel.com.au, bcheckley@epresence.com, Alan Clark , Hal Henderson , ludovic.poitou@sun.com, Andrew_Marshall@TD.COM Subject: Re: [ldapext] Re: Password policy state attributes References: X-Enigmail-Version: 0.65.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 Ed Reed wrote: > At the risk of sounding like a crackpot... > > You may need to consider something like the X.509 certificate object > class discussed in PKIX - an entry with all the policy associated with > the particular credential - in this case a password associated with an > authentication identity. It was also my first impression that this topic is very much the same sort of discussion like storing X.509 certificates in separate subordinate entries vs. certificate matching rules. Maybe I missed something but how does the authentication mechanisms distinguish which password to use for authentication in a specific application? If you have really several applications with different passwords then I'd suggest to simply put the application-specific credentials in different (subordinate) entries (with different application-specific object class assigned to them). Anyway IMHO one objective of LDAP deployment was getting rid of many passwords. At least that's what I read in most "whitepapers"... ;-) Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Nov 25 11:24:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06618 for ; Mon, 25 Nov 2002 11:24:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAPGPPv11230; Mon, 25 Nov 2002 11:25:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAPGLGv11093 for ; Mon, 25 Nov 2002 11:21:16 -0500 Received: from netscape.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06310 for ; Mon, 25 Nov 2002 11:18:24 -0500 (EST) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by netscape.com (8.10.0/8.10.0) with ESMTP id gAPGL7517978 for ; Mon, 25 Nov 2002 08:21:07 -0800 (PST) Received: from netscape.com ([10.169.192.93]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H6543602.IAP; Mon, 25 Nov 2002 08:21:06 -0800 Message-ID: <3DE24DF2.8010302@netscape.com> Date: Mon, 25 Nov 2002 11:21:06 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Sermersheim CC: ldapext@ietf.org, andrews@adacel.com.au, bcheckley@epresence.com, Alan Clark , Hal Henderson , ludovic.poitou@sun.com, Andrew_Marshall@TD.COM Subject: Re: [ldapext] Re: Password policy state attributes 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 How common is the "multiple passwords" scenario in real world deployments? My impression is that it is very rare. If so, I am opposed to doing extensive engineering and adding complexity for implementors and users in order to support it. I think most people will be happy with a password policy specification that only supports one password attribute. But if we really need support for more than one, I vote for the: pwdExpirationWarned;pwd-userPassword pwdExpirationWarned;pwd-webPassword approach. If we require that all attribute types used in conjunction with password policy be registered with IANA, I don't think there will be any serious interoperability problems with this approach. -Mark Smith Netscape Jim Sermersheim wrote: > A group of people interested in progressing the password policy draft has been growing and exchanging emails off list. We're moving discussion here so we have a list and a wider audience. > > The current topic has to do with storing password policy state information for objects. What is needed is a way to store values that represent state information on an object. There is the need to associate the state information with a password. This is because it's desirable to allow multiple passwords per object, and it to be allowed that policy can be described and executed separately for each password. Thus, we need a way of associating each bit of password policy state information with the password it applies to. > > For example. There is an attribute called pwdExpirationWarned. This holds the timestamp of when the client was first warned that the password would expire soon, thus it is single-valued. Now, let's say the object that is subject to password policy makes use of three password attributes due to there being three different hard access interfaces: atmPassword, telePassword, and webPassword (think bank account access). When the pwdExpirationWarned attribute is updated (due to an impending password expiration), there needs to be some way of associating the warning with the password that will expire (let's say it's webPassword). > > Our first attempt was to use attribute descriptions with a new tagging option called "pwd-". In the example above, pwdExpirationWarned;pwd-webPassword would be used to store/retrieve the warning time for the webPassword. The problem that was brought up with this approach (as I remember it) was that since the descr form of attribute types is not canonical, we cannot use it in the attribute option. It would lead to interoperability problems. > > Quickly, it was suggested to just use the oid form of the attribute type, like pwdExpirationWarned;pwd-1.2.3.4. While this would solve the problem above, it is an illegal encoding. Attribute options are defined as consisting of ALPHA, DIGIT, and DASH characters. > > Then the suggestion of moving the attribute association inside the value was put forth say something like "webPassword#200210240212Z". This requires new syntaxes which some implementors don't like, but worse: 1) It doesn't allow the attributes to be defined as single-value. 2) It doesn't allow the server to enforce uniqueness among the values. 3) It doesn't allow the replace operation (where replace would work with single-valued attributes). None of these limitations are desirable. > > I would now like to suggest returning to the first or second suggestion. The first has limitations in a distributed environment, and maybe something can be done about it, but I'm not sure what. The second would be modified to fit the required syntax by replacing dots with dashes. Thus the example would change to: pwdExpirationWarned;pwd-1-2-3-4 > > Jim > > p.s. I can provide a set of recent previous discussions on this and other issues to anyone that wants them. > > _______________________________________________ > 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 Nov 28 11:28:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29903 for ; Thu, 28 Nov 2002 11:28:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gASGStv28740; Thu, 28 Nov 2002 11:28:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gASGQxv28715 for ; Thu, 28 Nov 2002 11:26:59 -0500 Received: from smtp1.su.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29860 for ; Thu, 28 Nov 2002 11:24:10 -0500 (EST) Received: from daasi.de (unknown [195.84.31.21]) by smtp1.su.se (Postfix) with ESMTP id 38BFE34047; Thu, 28 Nov 2002 17:26:51 +0100 (CET) Message-ID: <3DE643C6.60706@daasi.de> Date: Thu, 28 Nov 2002 17:26:46 +0100 From: Peter Gietz Organization: DAASI International GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: Ed Reed , Jim Sermersheim Cc: ldapext@ietf.org, andrews@adacel.com.au, bcheckley@epresence.com, Alan Clark , Hal Henderson , ludovic.poitou@sun.com, Andrew_Marshall@TD.COM Subject: Re: [ldapext] Re: Password policy state attributes References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gASGR4v28718 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ed Reed wrote: > At the risk of sounding like a crackpot... > > You may need to consider something like the X.509 certificate object > class discussed in PKIX - an entry with all the policy associated with > the particular credential - in this case a password associated with an > authentication identity. Yes this came to my mind as well. Such a solution would also facilitate for other password policy attributes, such as duration, minimal length etc. etc. Implementationwise it seems to me that having all these attributes in one entry is far more easier than having to parse all the tags of the password attributes. [...]> > >>> "Jim Sermersheim" 11/22/02 12:16PM >>> > A group of people interested in progressing the password policy draft > has been growing and exchanging emails off list. We're moving discussion > here so we have a list and a wider audience. I very much appreciate this discussion. I think password policy is something more and more needed, since LDAP is more and more used as central authentication service. And I appreciate that this discussion is now taking place on this list. [...] > Jim > > p.s. I can provide a set of recent previous discussions on this and > other issues to anyone that wants them. yes please. May be you could put them in a webarchive or so. cheers, Peter -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 Tübingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Nov 28 23:40:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10917 for ; Thu, 28 Nov 2002 23:40:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAT4f8v28117; Thu, 28 Nov 2002 23:41:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAT4btv27988 for ; Thu, 28 Nov 2002 23:37:55 -0500 Received: from nexus.adacel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10825 for ; Thu, 28 Nov 2002 23:34:59 -0500 (EST) Received: (qmail 24551 invoked from network); 29 Nov 2002 04:28:25 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 29 Nov 2002 04:28:25 -0000 Reply-To: From: "Steven Legg" To: "'Jim Sermersheim'" Cc: Subject: RE: [ldapext] Re: Password policy state attributes Date: Fri, 29 Nov 2002 15:36:33 +1100 Message-ID: <000a01c29760$e5ae1180$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim, Jim Sermersheim wrote: > A group of people interested in progressing the password > policy draft has been growing and exchanging emails off list. > We're moving discussion here so we have a list and a wider audience. ... > Then the suggestion of moving the attribute association > inside the value was put forth say something like > "webPassword#200210240212Z". This requires new syntaxes which > some implementors don't like, but worse: 1) It doesn't allow > the attributes to be defined as single-value. 2) It doesn't > allow the server to enforce uniqueness among the values. If the syntax is designed so that the first component is an OBJECT IDENTIFIER (the password attribute type to which the policy applies), then the objectIdentifierFirstComponentMatch can be used as the equality matching rule and the server will enforce the requirement of no more than one set of policy parameters per password attribute type. > 3) > It doesn't allow the replace operation (where replace would > work with single-valued attributes). An aggregate syntax won't help with 3). Regards, Steven _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext