From dev-return-18233-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed May 02 16:38:46 2007 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 70339 invoked from network); 2 May 2007 16:38:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 May 2007 16:38:46 -0000 Received: (qmail 27456 invoked by uid 500); 2 May 2007 16:38:51 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 27429 invoked by uid 500); 2 May 2007 16:38:51 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 27418 invoked by uid 99); 2 May 2007 16:38:51 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May 2007 09:38:51 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ersin.er@gmail.com designates 64.233.166.182 as permitted sender) Received: from [64.233.166.182] (HELO py-out-1112.google.com) (64.233.166.182) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May 2007 09:38:44 -0700 Received: by py-out-1112.google.com with SMTP id a29so154075pyi for ; Wed, 02 May 2007 09:38:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OT26rTueo0ghT+KukBN1VpESs+rXC7/CLrtzD05RBzxh+1H9CR176gXsNBfNueIe+INBu1XCjlDbocIgzSzI4+/bnb3U/NRK8/R0X6GiSNhsj78HzaTUQl+jkaNDXKUUXuz3xeyjrci9gon5K6xhl0TfiyrNcTnqULSmLZQXtno= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oVoixcmpw087XMHK1JyXLdHhLuJ6gcmGTeIGa9BCrpyIda4QFwuy8eJOQ2rZt7ION07hNz0GDk0N37qmGcFTkt9f2UrTFoRon2BGWbREBknYUpxlw3JQit2ZQ+pvdkMRqM49DCwZWcbLCThtnqy2XQsysMz19EGbd1rGhJV02Xo= Received: by 10.35.92.1 with SMTP id u1mr1498283pyl.1178123904142; Wed, 02 May 2007 09:38:24 -0700 (PDT) Received: by 10.35.51.6 with HTTP; Wed, 2 May 2007 09:38:22 -0700 (PDT) Message-ID: Date: Wed, 2 May 2007 19:38:23 +0300 From: "Ersin Er" To: "Apache Directory Developers List" Subject: Fwd: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Checked: Checked by ClamAV on apache.org Alex, Bringing this mail again to your attention. Please let me know is there is any pb. ---------- Forwarded message ---------- From: Ersin Er Date: Apr 6, 2007 7:50 PM Subject: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components To: Apache Directory Developers List Hi all, As PAM and Stefan are close to finishing the ACI editor, they have asked me a few questions about the "extended" subtree specification I introduced in 1.5. Although I have explained these changes on JIRA and IRC, I wanted to record them here on the list also. What we did in 1.5 branch about Subentries and subtreeSpecifications in particular is allowing regular LDAP filters to be used in the specification instead of refinements. Refinements can only be used to specify boolean combinations of object classes. However it is obvious that in this new "flat" directory world, people would like to "select" portions of the DIT via any entry attributes as well as objectClass. So people would like to be able to specify a set of entries to protect via ACIs not only saying "those persons (according to objectClass attribute)" but also saying "those persons who are from X department (according to some user attribute)". This is what we provided. So, now, regarding to subtreeSpecification related components in ACIs. They have not been effected by this change because they cannot be and we did not want also. There are two components that may come to mind about this change. First is the "classes" protected item and the second one is "subtree" user class. The "classes" protected item has the refinement syntax and it is really used for specifying a boolean combination of object classes. It can never include regular attributes other than object class values. So it does not have to support the LDAP filter syntax. The "subtree" user class, although it has subtreeSpecification syntax (particularly), it does not even support refinements; so there is nothing to be replaced with ldap filters. I hope it's clear. -- Ersin -- Ersin