Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2E797DF7C for ; Wed, 26 Dec 2012 10:37:04 +0000 (UTC) Received: (qmail 88342 invoked by uid 500); 26 Dec 2012 10:37:03 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 88206 invoked by uid 500); 26 Dec 2012 10:37:03 -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 88189 invoked by uid 99); 26 Dec 2012 10:37:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Dec 2012 10:37: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 ayyagarikiran@gmail.com designates 209.85.210.182 as permitted sender) Received: from [209.85.210.182] (HELO mail-ia0-f182.google.com) (209.85.210.182) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Dec 2012 10:36:56 +0000 Received: by mail-ia0-f182.google.com with SMTP id x2so7054393iad.27 for ; Wed, 26 Dec 2012 02:36:36 -0800 (PST) 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=s7iz+bWuMU4LyZxISP28wiHLdB/At8Xcgs8GXo7aHxQ=; b=J8sIaDezh60Erpfk14ujw8ynoYWaWvJ/F4M1EtXM/19auWMzI16leXG0Qdt/7PCgrH wSQzKAqIfaA1LMMyBaETIjZfAF5NhL443iALDtt/z8GjyIfAA+yEFKi3lwqZ/0V4+q5j 3amrpdHclY4DACzmr8+1HyxDMGljSIPg7ikwEEotaw3Wf7BkOwnwm3cAhr/HaUVocZxu NEfhWQ9MiUdVuVJ+UU7wFOlL2H2s1KthnKJQ6DCUMFK8+qEsyIQ9QD/CoYdgKmn0hYkN Id4hjGKre08k14hTDVVdz5+5GL6I6+6MagNf8/bApNORYt7YIBlpZrBPlMHdg5Iy8KQY Y34g== MIME-Version: 1.0 Received: by 10.50.108.161 with SMTP id hl1mr18591590igb.101.1356518195958; Wed, 26 Dec 2012 02:36:35 -0800 (PST) Sender: ayyagarikiran@gmail.com Received: by 10.231.142.6 with HTTP; Wed, 26 Dec 2012 02:36:35 -0800 (PST) In-Reply-To: <50DAD20B.9000809@gmail.com> References: <50DAD20B.9000809@gmail.com> Date: Wed, 26 Dec 2012 16:06:35 +0530 X-Google-Sender-Auth: IJsr-7L-ZiBHKeVvN80JZ8euxo8 Message-ID: Subject: Re: Configuration and MUST attributes From: Kiran Ayyagari To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=f46d0402a9af3394ac04d1bf01eb X-Virus-Checked: Checked by ClamAV on apache.org --f46d0402a9af3394ac04d1bf01eb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable we actually did(fix!) this intentionally in the recent release to prevent a user from deleting these attributes. This also helps in letting the users know what attributes are there that are mandatory for the server to function and their default values. On Wed, Dec 26, 2012 at 4:01 PM, Emmanuel L=E9charny w= rote: > Hi ! > > as I'm writing the doc about configuration, I'm wondering if some of the > MUST attributeType we have in many of the configuration ObjectClasses > should not be MAY attributeTypes instead. For instance, considering the > ads-directoryService ObectClass, we have : > > m-must: ads-directoryServiceId > m-must: ads-dsReplicaId > m-must: ads-dsAccessControlEnabled > m-must: ads-dsAllowAnonymousAccess > m-must: ads-dsDenormalizeOpAttrsEnabled > m-must: ads-dsPasswordHidden > m-must: ads-dsSyncPeriodMillis > m-may: ads-dsTestEntries > > Many of those AttributeType have default values, and we probably don't > need to require the administrator to fill some value for, say, > ads-dsSyncPeriodMillis. > > I would rather suggest we switch from MUST to MAY some of the > AttributeType, something like : > > > m-must: ads-directoryServiceId > m-must: ads-dsReplicaId > m-may: ads-dsAccessControlEnabled > m-may: ads-dsAllowAnonymousAccess > m-may: ads-dsDenormalizeOpAttrsEnabled > m-may: ads-dsPasswordHidden > m-may: ads-dsSyncPeriodMillis > m-may: ads-dsTestEntries > > Such a modification could be done for other ObjectClasses. > > wdyt ? > > -- > Regards, > Cordialement, > Emmanuel L=E9charny > www.iktek.com > > --=20 Kiran Ayyagari http://keydap.com --f46d0402a9af3394ac04d1bf01eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable we actually did(fix!) this intentionally in the recent release to prevent a= user
from deleting these attributes. This also helps in letting the use= rs know
what attributes are there that are mandatory for the server to f= unction and
their default values.


On Wed, Dec 26,= 2012 at 4:01 PM, Emmanuel L=E9charny <elecharny@gmail.com> wrote:
Hi !

as I'm writing the doc about configuration, I'm wondering if some o= f the
MUST attributeType we have in many of the configuration ObjectClasses
should not be MAY attributeTypes instead. For instance, considering the
ads-directoryService ObectClass, we have :

m-must: ads-directoryServiceId
m-must: ads-dsReplicaId
m-must: ads-dsAccessControlEnabled
m-must: ads-dsAllowAnonymousAccess
m-must: ads-dsDenormalizeOpAttrsEnabled
m-must: ads-dsPasswordHidden
m-must: ads-dsSyncPeriodMillis
m-may: ads-dsTestEntries

Many of those AttributeType have default values, and we probably don't<= br> need to require the administrator to fill some value for, say,
ads-dsSyncPeriodMillis.

I would rather suggest we switch from MUST to MAY some of the
AttributeType, something like :


m-must: ads-directoryServiceId
m-must: ads-dsReplicaId
m-may: ads-dsAccessControlEnabled
m-may: ads-dsAllowAnonymousAccess
m-may: ads-dsDenormalizeOpAttrsEnabled
m-may: ads-dsPasswordHidden
m-may: ads-dsSyncPeriodMillis
m-may: ads-dsTestEntries

Such a modification could be done for other ObjectClasses.

wdyt ?

--
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com




--
Kiran Ayy= agari
http://keydap.com<= /a> --f46d0402a9af3394ac04d1bf01eb--