RE: modifying top

[Kim Fenley <kfenley@ozemail.com.au>]

 A view from the silent majority

I find this whole area of TOP being buggered by the IETF (which is an
abstract point under the ITU/ISO X.500 standard) abhorrent.  Just becauce
Microsoft gets it wrong everyone is now trying to work around a problem that
isn't.

We now have one solution, get Microsoft and others to stick to the standard,
not bugger it up even more.

I've seen this same thing happen with IPV6 (not working yet) and now LDAP.
LDAP as we know was developed for one very specific thing and for a specific
situation, which then went out of control (mainly because it was political
and ideological, not technical).

The "L" in LDAP was for Lightweight, it now means LARGE and LETHARGIC. DAP
is faster and more compact (150K) and will work in an e-commerce and PKI
infrastructure globally, distributed and in a trusted pridictable way. LDAP
is just a client/server relationship, ie. no better than the databases and
addressbooks it's supose to replace.

We now have a car with square wheels along a very bumpy road and going out
of control.

This group has been adding more and more features of full DAP to LDAP, to
compensate for the LDAP deficiencies.  The further we have moved along, the
less De Facto a standard it has become to the point of proprietariness eg.
Microsoft, Lotus, Novell, Netscape all adding their own bits in an attempt
to capture the market and which are X.500 like.  Or they just plainly don't
understand the standards.

I know that if I want to operate in a secure and trusted environment, there
is only one solution full DAP and full X.500.  There seems to be no global
operational understanding of Directories from the LDAP Group.

Its this publish or perish mentality, rather than for GOOD technical
reasons.

The systems you are currently developing are forcing implementors to know
where every Directory is, rather than let the X.500 system find the resource
as in full DAP/X.500, and you can't own your environment because someone may
rename it for you without your permission.  If I was a Bank or Defence
organisation I would want a system that can be trusted and is secure.  That
I don't get with LDAP and LDAP servers.

So lets look at realtime operating systems that will work globally, that are
secure, that can be trusted, that are predictable and that will work as a
distributed Directory system and in a PKI infrastructure.

Kim

-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick@iti.salford.ac.uk]
Sent: Tuesday, 15 June 1999 8:20
To: ietf-ldapext@netscape.com; Bruce Greenblatt
Subject: Re: modifying top


Date forwarded: 	Sun, 13 Jun 1999 23:41:54 -0700 (PDT)
Date sent:      	Sun, 13 Jun 1999 23:41:51 -0700
To:             	ietf-ldapext@netscape.com
From:           	Bruce Greenblatt <bgreenblatt@dtasi.com>
Subject:        	modifying top
Forwarded by:   	ietf-ldapext@netscape.com

> Here's the explanation that I use for LDAP servers that modify the top
> object class.  It may be a little convuluted, but it satisfies conformance
> concerns (at least to me).

Unfortunately where this falls down is if subschema publishing is
supported in the subschema subentry (which it should be for
LDAPv3). When a remote server wishes to read the new subschema
definitions it will find that it does not exist and top has in fact been
redefined (or alternatively that the long convoluted explanation that
you went into is in fact reality and that this invisible auxiliary object
class does exist, and then all is fine.)

David


>
> From my  perspective the LDAP servers only appear to modify the top object
> class, but in reality they don't.  Let's use the Netscape DS as an
> example.
>  All objects that are contained in the DS database have both the
> objectClass attribute and the ACI attribute.  They get the objectClass
> attribute from the top object class.  They get the ACI attribute by virtue
> of the fact that every object created in DS also a member of the hidden
> auxiliary object class netscapeTop.  This object class value is hidden
> because nobody normally has sufficient access rights to see this
> particular value of the objectClass attribute.  The netscapeTop auxiliary
> object class has the one attribute type ACI.  Thus, Netscape hasn't
> modified top at all, they've made use of the auxiliary object class
> mechanism in a very standard way.
>
> Bruce
>
>


***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
*NEW* Mobile +44 790 167 0359 *NEW*
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
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************