Return-Path: X-Original-To: apmail-directory-users-archive@www.apache.org Delivered-To: apmail-directory-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 91CB69B2A for ; Mon, 30 Apr 2012 09:54:03 +0000 (UTC) Received: (qmail 17299 invoked by uid 500); 30 Apr 2012 09:54:03 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 17254 invoked by uid 500); 30 Apr 2012 09:54:03 -0000 Mailing-List: contact users-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@directory.apache.org Delivered-To: mailing list users@directory.apache.org Received: (qmail 17246 invoked by uid 99); 30 Apr 2012 09:54:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Apr 2012 09:54:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-wg0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Apr 2012 09:53:56 +0000 Received: by wgbdr13 with SMTP id dr13so378109wgb.1 for ; Mon, 30 Apr 2012 02:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=H5uxKy2IaJEygLVlCxY19HRQZF4WOelFNObzEtbUpr8=; b=YIdPX1jjn6LdVqvXhRo+F45ALWe+dogtGhv7RMkZQXv7eDKxXUZiePu/RL5XlD19+Z CFr5BOAoL3qzX85sorrqtrPyrwsHexK5xYMGgTTeQxf413+vt6MZoYvcJHxuVFpdysBp lWjRibzlaSVfPXmp7v5f0e4wzIANKZn88VR+jvgBMBjfr01CX4izxeh6WtxErt43wgcM tHSrhtxFJhVHMZurnsDInsnkmNF7LYw4GyWr5nr+/LOccjdh7X4jyxpEjAUxDw7ZgqlE yAbwZv2s6BrlpvebHTgk25aCzXcyR7NP9N62B2POy+2MZ1xB7hmkcDjl4m8Atui4yAIF p3YQ== MIME-Version: 1.0 Received: by 10.180.100.230 with SMTP id fb6mr18970427wib.3.1335779616321; Mon, 30 Apr 2012 02:53:36 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.180.126.97 with HTTP; Mon, 30 Apr 2012 02:53:36 -0700 (PDT) In-Reply-To: References: <1554570.NjuOaEdBII@venus> Date: Mon, 30 Apr 2012 12:53:36 +0300 X-Google-Sender-Auth: VVjZn4EUWL6cDa3EYeOvfdC0_-c Message-ID: Subject: Re: [ApacheDS] subschema subentries and DIT structure rules etc. From: Alex Karasulu To: users@directory.apache.org Content-Type: multipart/alternative; boundary=f46d041824ee87713c04bee26d78 --f46d041824ee87713c04bee26d78 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 30, 2012 at 12:52 PM, Alex Karasulu wrote: > > > On Mon, Apr 30, 2012 at 11:53 AM, Karl Weber wrote: > >> Hi, >> >> as far as I read in the documentation for ApacheDS 1.5.7, ApacheDS does >> support subentries according to RFC 3672 with the exception of subschema >> subentries. >> >> > Yes it does and so will all other implementations to come like 2.0 below. > Ooop I read in correctly (thought you meant subentries), I see you mean schema subentries. True we don't suport this. > > >> Is this still valid for the current 2.0.0 milestone? Unfortunately the >> links >> to the documentation are broken. The support of subschema subentries has >> been >> announced in the 1.5.7 documentation for the "future"... >> >> > We need help with docs :). > > >> Does ApacheDS support DIT structure rules and DIT content rules? > > > Unfortunately it has all the machinery but enforcement of these rules > don't take place and that peeves me a great deal. For really great schema > design these are a must. Unfortunately many don't understand just how > important these are including NameForms for carving out the namespace > properly. > > >> The >> documentation for 1.5.7 claims that ApacheDS is RFC 4512 compliant, >> however >> support for these rules is optional, so some clarification is needed. >> > > Yes we may have falsely advertised this if these features are required. > > >> Furthermore, in order to use DIT structure rules, administrative areas >> with >> there own subschemas would make sence. (DIT structure rules do not have >> global >> OIDs but only integer IDs which have to be unique within the controlling >> schema.) Furthermore, quote of RFC 4512: >> >> If no superior rules are identified, the DIT structure rule applies >> to an autonomous administrative point (e.g., the root vertex of the >> subtree controlled by the subschema) [X.501]. >> > > Schema right now applies globally to the entire DIT and I don't like this > myself. However it's really hard to make it work with AAP and IAPs. I hope > we get to this at some point. > > -- > Best Regards, > -- Alex > > -- Best Regards, -- Alex --f46d041824ee87713c04bee26d78--