Re: Global Directory System Backbones

[howes@netscape.com (Tim Howes)]

All:

While I'm sure this discussion is fascinating to some,
it is not related to any LDAPEXT work items. Please
take it off the LDAPEXT list, which should only be
used for LDAPEXT-related topics. And please do
not cc: the ASID list on LDAPEXT traffic. Thanks.
        -- Tim

Alan Lloyd wrote:

> Lars you raise some interesting points and I just love the failure of
> OSI stuff.
>
> OSI is a 7 layer reference model that is used in about most things in
> distributed computing world today as one would expect. - I belong to
> many industry groups including the Intelligent Transport System
> standards group (US, Asia, Europe and Aus) and we (those thousands of
> companies participating) are developing standards and products for
> vehicle onboard equipment, traffic management centres, etc, etc. (Yes
> OSI to the car!!) And these use OSI teminiolgy and standards. eg
> "Network layer, Transport layer, , Session layer, Presentation layer.
> even Fax machines have these.
>
> One of the cornerstones of "OSI" was ASN.1 which is used to build
> presentation layer code and the application hooks - for transfering
> information (transparently - text and binary) in a common way between
> distributed systems. This was invented in 1984 for X.400. ie. ASN.1 is
> the tool for defining objects, messages and data syntax for distributed
> systems. One even has compilers which automatically build this stuff -
> to save all that hand coding of these layers - OSI is an Automated build
> process  from ASN.1 definitions!!!
>
> ie. If it has ASN.1 in it it, by definition it has an OSI  presentation
> and application layer.
>
> In the late 80s and early 90s OSI and ASN.1 was relentlessly attacked
> (even though its now proved to be about 130kb of code).Today 10 years on
> we have ASN.1 in S/MIME, SNMP, LDAP, X.509 certificates etc... In
> addition X.509 - requires X.500 directories otherwise how on earth do
> you find them, particularly  in a WEB system. And quite honestly I dont
> want a domain name stamped on my head as my name - machines have those.
> Tell me how I find your phone number in a WEB system and fast when I
> have is your name and roughly your location?? (eg. See Telephone systems
> and their directories.)
>
> It seems to follow that it  takes about 10 years to go through the
> process of "its too complex", "lets make a simpler one" and in the
> process - actually adopt the the technology originally defined .
>
> LDAP is having the same problem. ie X.500 - "all too complex" and now
> are we all re inventing X.500 - the whole works.
>
> SMTP is running into tremendous scaling problems because of its list and
> CC expansion on origination (in most cases) therefore by definion, the
> thing will not scale as more and more uses get on to the internet - the
> internet must adopt a "telephone" system architecture - where mail list
> expansion is performed within the network at the optimum points for
> every recipient  - like X.400 expansion. Again I believe that SMTPers
> are looking at this issue..But X.400 dealt with that 12 odd years ago.
> Directories will be the same, they must be distributed (server to
> server) and not this LDAP "client to many servers paradigm.
>
> IP6 - well theres an intersting concept. As data and voice services come
> together and we have  2 billion people on the phone system and 100m on
> the internet with the IP4 addresses depleted (although DHCP has saved
> the day to some extent). What will we do. Map IP6 hexadecimal addresses
> to phone numbers, have two global routing schemes, put hexadecimal phone
> numbers out there, remap the whole world and reprint all the worlds
> paper with phone numbers, get 16 fingers????
> I believe IP6 is operationally unworkable in a globalising world. Its a
> protocol that has nowhere to go and if it did we would need an IP6
> configuration army.
>
> Not one person on this planet seems to be able to say how IP6 addresses
> will be administerd operationally, how such a scheme relates to the
> phone network addressing or have the dollars to make the whole world
> have two routing infrastructures with different address forms.
> Please if anyone can guide me here with good OPERATIONAL information re
> the above , ie mapping ISDN numbering and operational deployment .
> Please do,  many issues on this are coming to the fore.
>
> I think as we all move to ATM that ISDN based IP (CLNAP) services will
> be used based on phone numbers - rendering IP4, IP6 redundant. History
> will prove me right or wrong here.
>
> X.500 is about consolidating ones own business information into an
> object oriented named based transaction system  (not just mail address
> book things) - which then, via its distribution protocols (DSP), is
> publically enabled (under its protection/access controls)  to be part of
> a larger disciplined information system that enables business to
> interoperate - particularly - verify capabilities such as those
> presented in certificates. LDAP has not dealt with distribution (like
> DSP) so certficate verification in a larger environment is impossible -
> shall I repeat that.
>
> Again just basics of IT engineering says that a client- server paradigm
> does not scale. Server to server protocols and distributed server
> architectures are required (see the telephone system) if systems are to
> globalise effectively.
>
> I do find it absolutely amazing that given these basics of engineering.
> ie using ASN.1  = OSI Prentation layers, Object oriented design requires
> object naming and global directories require distribution protocols and
> knowledge based on the objects naming properties (for real life objects
> - not machine host names) . That OSI is dead!!!, "X.500 is too complex"
> and global directories are not needed....
>
> As for the WEB and X.500 - they are two complemenary information
> systems.
> X.500 - is highly disciplined schema in a controlled/configurable (with
> ACI) environment for name based transactions. WEB is a browse system for
> publically published information. In fact we interwork WEB and X.500
> technologies. eg we can put "subjects" as entries in a directory system
> so we can find these fast, protect those entries for the parties who can
> see them via the ACI and within those subject entries - contain either
> the WEB pages as entry attributes or point to the WEB services directly.
> Ie X.500 and WEB technologies combined provide a fast, discipklined,
> protected, role based data warehousing system. _ All seamless from a
> user perspective.
> Brilliant!
>
> As you can see - X.500 is not just "LDAP" and protocols to get address
> book info.
>
> I think X.500 is a corner stone of this planets distributed information
> system for voice, data, internet, EC (X.509) and data warehousing
> systems.
>
> And those adopting X.500 directory systems will be a far better
> commercial and business position with their information skills than
> those companies just adopting "LDAP".
>
> ie. If  IT systems represent a companies capability and competitive
> advantage , why on earth would I want the "simple" directory system.
>
> Just thoughts and regards alan.
>
> > -----Original Message-----
> > From: Lars Aronsson [SMTP:lars@aronsson.se]
> > Sent: Saturday, April 18, 1998 9:36 AM
> > To:   ietf-asid@umich.edu
> > Subject:      Re: Global Directory System Backbones
> >
> >
> > Hi.  A newcomer in this IETF WG, I should read more before writing,
> > but some questions that have already been raised here indicate even
> > greater confusion than mine.  If any of the following statements seem
> > provocative, they should be construed as questions to which I seek the
> > answers, even though question marks might be missing.  It is almost
> > ten years since I last had anything to do with X.500 Directories, and
> > I did not understand much about them then either.
> >
> > The Directory has been compared to the web itself, because it builds a
> > service out of a network of independent contributions, and to web
> > search engines, because it helps people find what they are looking
> > for.  The contradiction seems to be that existing web search engines
> > are monolithic (owned by one organization) and still claim to cover
> > the entire web, so why should the Directory be a distributed system.
> >
> > The purpose of the Directory is to help people (sometimes through
> > their e-mail software, whether MUA or MTA) to find useful addresses to
> > other people and institutions.  Any way this can be best solved should
> > be used, and monolithic solutions should not be excluded beforehand.
> >
> > The reason that distributed solutions have been favored so far is that
> > the address information that is to be searched, in order to be
> > accurate and useful, needs to be maintained, and this cannot be done
> > by just any software like the AltaVista, but must be made by the
> > individuals themselves or by the organization to which they belong
> > (employer, membership organization, school, ISP, telco, etc).
> >
> > Therefore, the distribution of the Directory is not a part of its
> > purpose, but a part of the best current practice.  The original work
> > on Directory services in the 1980s (X.500) was not based on the web as
> > we know it, but on OSI and X.400 e-mail as some pre-1984 AT&T-style
> > telcos, many of them with a national monopoly, had envisioned it.  The
> > world and the Net is different today, and anybody doing Directory work
> > in the late 1990s must consider these entirely new conditions.  Not
> > only have we witnessed the widespread use of the Net, the invention of
> > the Web, the failure of OSI, and the design of IPv6, but new business
> > concepts such as BPR and outsourcing have also become a fashion.
> > (Not to mention the Berlin Wall, Linux, and a few other things.)
> >
> > Everybody maintains a website today, but not everybody runs the server
> > or owns the hardware.  Just as web hotels is a way of outsourcing
> > parts of your online publishing, a few large-scale privately owned
> > Directory servers may be used by many companies.  The content owners
> > can use the Internet and a password to update their data any time.
> > The server does not have to be close to the content owner.  It might
> > be better to have it close to the people who use it for searching.
> > The Directory server does not have to be owned by the telco or the
> > ISP.  Aggregating information from many sources into a large database
> > leads to more efficient searching with shorter response times.  This
> > attracts users, and is a good basis for selling space for commercial
> > ads.  There are web hotels that charge their users, and web hotels
> > such as Geocities that allow web space for free in substitution for
> > the right to place banner ads on the customer's web pages.  I would
> > not be surprised if BigFoot or Four11, instead of charging for the
> > outsourced services, would pay companies for depositing their
> > Directory data.  And the reason that would keep large companies away
> > from this is the risk of spamming.  Who had heard of bulk unsolicited
> > commercial e-mail in 1988 when the X.500 blue book was published?  If
> > you were a governmental agency with a limited budget and a requirement
> > to provide Directory data to the public, would you invest in your own
> > server, or would you use an outsourcing concept that generates income?
> >
> > Correct me if I am wrong here: In the traditional view of an X.500
> > network, every company (or every telco) runs their own X.500 server,
> > from which any end user or any other server may retrieve information
> > at no cost, using a well-specified protocol that does not allow the
> > content owner to insert ads or charge the end user for the service.
> > Ultimately, someone else will set up a web gateway, presenting a
> > user-friendly interface to this sea of well-structured information
> > together with commercial banner ads that generate income for the
> > gateway owner, but not for the content owners.  Why would any company
> > or institution be so stupid as to provide Directory service on these
> > terms?  Is the answer only "web gateways did not exist in 1988"?
> >
> > If the answers to these questions were written down in an FAQ, this
> > mailing list would be able to concentrate on the technical issues.
> >
> >
> > Lars Aronsson.
> > --
> >   Aronsson Datateknik           mailto:lars@aronsson.se
> >   Teknikringen 1e               http://www.aronsson.se/
> >   583 30 Linköping, Sweden      tel:+46-13-211720    fax:+46-13-211820