re : X.500

Paul-Andre Pays <pays@gctech.edelweb.fr> Sat, 23 September 1995 19:17 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11920; 23 Sep 95 15:17 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11916; 23 Sep 95 15:17 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa13552; 23 Sep 95 15:17 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.03442-0@haig.cs.ucl.ac.uk>; Sat, 23 Sep 1995 19:57:12 +0100
Received: from edelweb.fr by bells.cs.ucl.ac.uk with Internet SMTP id <g.12579-0@bells.cs.ucl.ac.uk>; Sat, 23 Sep 1995 19:57:04 +0100
Received: from [194.2.128.44] (client14.sct.fr [194.2.128.44]) by edelweb.fr (8.6.12/8.6.9) with SMTP id UAA25258; Sat, 23 Sep 1995 20:56:52 +0200
X-Sender: pays@edelweb.fr
Message-Id: <v01530501ac89fe84756a@[194.2.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 23 Sep 1995 20:56:54 +0200
To: maciag@server1.deltanet.com
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul-Andre Pays <pays@gctech.edelweb.fr>
Subject: re : X.500
Cc: osi-ds@cs.ucl.ac.uk


You asked me to elaborate on my comments about X.500 being
        "not that good"  at white pages type usage
        "not good at all" at yellow pages type usage

Here is very briefly (as I consider X.500 is already dead, I cann't afford
to spend more time) what I can write down.

Beware this might appear as very offensive. It is, but please
consider that what I attack is X.500 (for which I lost
half of 5 years of my professional life :-( ) and not people or groups.
My goal is to try to help people avoid the same errors and
waste their time and efforts.


White pages:
   in short lookups from "naming attributes"

    X.500 is at best OK for name resolution when you have the DN or
        a nearly exact DN
    if you have several naming attributes but errors or missing
        RDN high in the DIT, then the far too hierarchical
        naming structure will make X.500 unusable in practice
        most of the time

yellow pages:
        searches using other attributes than RDN attributes

        are in general absolutely not doable with X.500
        (think at looking for a guy whose name is Mike Maciag
        and email address maciag@server1.DELTANET.COM: you would have
        to search each and every database in the whole world...)

        in fact it is not fully X.500 specific, but there is no real
        yellow pages without a specific purpose pre-indexing of the
        searchable attributes. X.500 just does not enable this.

---------

design flaws:

        there are many, many design flaws and I won't go into details
        such as NSSR and the brain-damaged aliases but just point out
        a few major issues

        1. it is pure utopy to believe that a large scale distributed
        directory (eg. hundreds of millions of people, even more
        documents) can be a "database" ie. it can offer update
        functions. there is no chance to get an acceptable
        level of performance with all the access control and side
        effects overheads implied.
        If you want a world wide directory system, you have to
        forget online updates (think of the DNS).

        2. the X.500 model does not allow for "non globally accepted"
        schema (whatever the X500 93 efforts) because DUA will just be
        unable to deal with entries and schema not predefined.
        No chance to use a large distributed X.500 with new
        object classes and DIT structuring. In fact the whole X.500
        class concept is brain damaged too.
        The only schema usable will at most be the one approved by all
        PTTs. No chance to store your own objects, to structure your names.
        No chance to have user acceptable DUAs/DUIs for that.

        3. the whole ADDMD concept is broken. there is no realistic
        way to have competing service providers share the same
        naming space. The NADF efforts are just unrealistic
        moves to try to overcome this flaw. The model is
        a centralistic/monopoly based model only suited to
        monopoly PTTs.

        4. there is no chance to have a worldwide directory based
        on a connection oriented approach. Even if you use RFC1006
        to run X.500 on top of TCP you are out of the game except for
        demos. your system will never scale up.
        Again, take the DNS example, do you believe there would be an
        internet with a TCP (connection oriented) DNS? the answer is
        definitely NO. X.500 being even more ambitious is a toy, or
        at most a tool between a few (<1000) PTTs and carriers.
        A worldwide large scale directory MUST be UDP based.


--------

I will not say anything about the implementations and services
   They are doing there best... BTW I was one of them for years
   and it take me far too much time to get aware that I was blind
   and wasting my efforts.  general purpose X.500 is simply dead.


regards,

-- PAP

PS: as said before have the situation is not that bad if you have a close look
at things such as whois++ and its centroid concept and Harvest
with its gather/broker concept.

_________________________________________________________________________
PAP:  paul-andre.pays@gctech.edelWeb.fr
     tel:  +33 1 34 52 00 88                fax: +33 1 34 52 25 26
         GC Tech   "The Globe Online and Globe ID Technology Company"
  http://www.globeonline.fr/                 http://www.gctech.fr/