[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Subschema management (was Abstract object class)
Thanks, David - I agree that content rules are useful but not sufficient for the
broad set of needs that large organizations have.
I subscribe to some variation on your first option, below - that is, that the
organization, writ large, is partitioned into several internal administrative
domains for the purpose of schema management. Additions to schema
in, say, the European office of Daimler-Chrysler, for instance, ought not
have any bearing on those required in the Detroit manufacturing plants.
similarly, Sales, Engineering, and Human Resources may reasonably
have purchased different applications which each extend the schema
of the directory for their own application use (consider what happens if
one settles on Netscape's Suite Spot for messaging, another uses
Microsoft Exchange, and a third uses Novell's Groupwise, just to pick
an obvious example from the messaging world - all have their own
extensions upon which they rely for various features, none of which
are relevant to users of other products).
So, yes, whether a new type of domain - a schema management domain -
is created that is able to operate within the boundaries of the current
administrative domain of an organization, or whether each department
is run as a separate administrative domain, each with their own schema
management I think is more of a transition strategy than an intended
end point. The intended endpoint is that the directory flexibly, and securely,
is able to model the kinds of operational delegation of authority, in this
case to purchase software and install it without outside interference from
some directory god at headquarters, that are routinely encountered in
commercial businesses of all sizes.
This is why you'll find me protesting loudly and frequently that listing
schema on the root dse of servers is wrong (servers must be able to hold
nameContexts, and therefore schema, from many different administrative
authorities, at least as shadows, and can't be in the position to limit the
schema each uses arbitrarily (granted, before you ask, that some
servers will not be ABLE to support some schema extensions - those which
entail new syntaxes or special relationship management, for instance, and
THAT is a suitable subject for the root DSE - the list of syntaxes that
the server CAN support, from which supported schema may draw
for their own definitions).
Moving the "global schema definition" from the root of the world to the
root of the server only complicates deployment. Schema definition,
as you can tell I believe, belongs in alignment with the portitions of the
namespace which use the definitions under common, possibly
departmental, administrative authority.
Ed
----------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861-3320
>>> "David Chadwick" <d.w.chadwick@iti.salford.ac.uk> 11/21/1998 10:48:21 >>>
Ed Reed wrote:
> > Note that even within administrative domains (corporations, for
> > instance) it's vital that departments and org units within the larger
> > namingContext have their own schema - it's unreasonable for the software
> > purchased by Sales in NYC to extend the schema for Engineering in Denver
> > when they have separate internal administrative domains with separate
> > administrators and namespaces. But both still reside within the larger
> > corporate namingContext, and may need to be subject to a common
> > organizational schema onto which their schema extensions are laid.
>
And Jeff added:
> I just want to simply "second" the above requirement statement. It's clear
> in our deployment at Stanford that such capabilities are needed. And
> replication needs to play into this also.
>
> I wasn't aware of the "content rules" notion in X.500(93). Thanks to Ed,
> Erik, and Paul for the enlightening discussion.
If we want to keep in sync with the X.500 administrative model, then we cannot
have inner administrative authorities for subschema, whereby departments add
their own subschema definitions to their bits of the tree. The schema for the
whole administrative domain (the organisation) must be held in a single
subschema subentry. There are two solutions to this as I see it (using the
existing X.500 model)
i) the organisation's naming context is partitioned into separate administrative
domains for subschema management, and each domain can set its own
subschema in its own subentry. In this case the common schema used by the
whole organisation would only be held externally on paper somewhere, and not
actually in the DIT.
ii) the organisation is not partitioned for subschema management, but the
various departmental administrators are given access permissions to update
the subschema subentry by adding their own definitions to it (note adding and
not deleting!!). The new definitions do however apply to the whole organisation.
In this case we have devolved management but global applicability.
On my reading of X.500, content rules on their own do not provide a solution,
since these are held in the single subschema subentry.
David
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************