[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: MUST X.500


Hello all ..

Re this change.
Does this mean that when a client application accessing a directory via LDAP
now needs to know what type of directory it is - How many types of LDAP
servers are there going to be in the world ?

Why have "a common access protocol" when the client application and the
servers they connect to - for a directory service,  are different...

Does this mean we have lots of code in the client apps to detect what
features are in the servers, and lots of code in the servers to emulate
services for all types of clients - and the protocol is still lightweight ?

Just me and my "logic" :-)

I dont mind extensions and variances - but what is the end game here - Is it
standard X.500 distributed directory service that scales and is consistent
to many LDAP/DAP type applications - AS WELL AS lots of incompatable
unscaleable, non distributed  LDAP servers with odd mechanisms that dont
work on distributed directories - for small scale odd ball applications and
lots of incompatible clients - And the market and business organisations of
the world working for the next ten years to achieve compatible products?

The words below require some changes.

> -----Original Message-----
> From:	Kurt D. Zeilenga 
> Sent:	Tuesday, April 11, 2000 5:51 AM
> To:	ietf-ldapext@netscape.com
> Subject:	MUST X.500
> 
> RFC 2251 contains the requirement:
>    An LDAP server MUST act in accordance with the
>    X.500(1993) series of ITU recommendations when providing the service.
> 
> This statement imples that LDAP servers must act in accordance
> with X.500(1993).  However, it is clear that most servers do not
> act in accordance with X.500(1993).  Some act in accordance with
> various LDAP specifications which are counter to X.500(1993),
> some act in accordance with other revisions of X.500, some use
> LDAP to access non-X.500 directories, etc.
> 
> I would like to change the above requirement (before LDAPv3
> is progressed to draft standard) to:
>    An LDAP server SHOULD act in accordance with the X.500(1993)
>    [or later revisions] series of ITU recommendations unless
>    such specifications are conflict with LDAP specifications.
>    An LDAP server MAY provide access to non-X.500 directories
>    as long as operations behave as defined by this document.
	[Lloyd, Alan]  
	" An LDAP server may not perform all the functions of an X.500
distributed directory - and may provide other features, mechanisms or
services as defined in other LDAP specifications, Such features, mechanisms,
services may cause compatibility issues with directory client and server
products from different vendors".


> Besides allowing the LDAP community to "revise and extend" the
> information model, 
	[Lloyd, Alan]  X.500 - and an industry strength version of its
implementation (with LDAP access) does have an extensible "information
model"..
	The correct term that LDAP standards should be using is - extensions
to LDAP server functionality and LDAP server information management
mechnisms.
> this allows LDAP to be used to access
> directories which do not act in accordance with the X.500
> series of ITU recommendations.
> 
> It may also be useful to define a Root DSE attribute type which
> describes the directory model in use.  Ie: "X.500(1993)"
> or "X.500(2020)" or "LDAP(v3)" or "X-other".
	[Lloyd, Alan]  Although this is easy to implement - what would
client apps do as the result of reading this attribute..The reason for a
"standard "lightweight" access protocol" is to remove the issue of clients
being complex and service knowledge based  - and having to understand all
the server variances..

	Before we standardise  mechanisms that indicates extensibility - and
incompatibility (which are very easy to define) - can someone give any
concrete examples of the requirements  and what the outcomes are - in terms
of end user benefits and directory "service" functionality.

	I just hate to see a simple access protocol literally bogged down
with twice the size in specifications for all its variances and how one
deals with the variances..


	Sorry - just more of my strange  logic !

	regards alan

>  	Kurt