RE: MUST X.500

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

It's my view that the MUST should be SHOULD per RFC 2119
guidelines.  That is, LDAPv3 is an application protocol
of requests and responses.  Interoperability imperatives,
as referred to in RFC 2119, I believe should be at the level
of protocol peers.  Protocol peers can (and do) interoperate
if they understand each other PDUs.  The fact that a given
request may induce different reply from implementation to
implementation is not indicative of inoperability, but a
indication that servers are free to respond with any valid
protocol construct.

Though I agree that a general purpose browser should be
able to browse a distributed directory.  I do not concur
that we'll ever reach the point where all sophisticated
applications can operate on any compliant implementation.
Though one could attempt to tighten the specification, each
tightening of the specification reduces its flexibility.

I firmly believe that the success of LDAP will depend
greatly on it's ability to be flexible and that, in
spaces require interoperability at higher levels, can
be handled by standard track elective features designed
to handle the specific requirements of that space.

I should also note that the MUST X.500(93) statement is quite
problematic for other reasons. 
	the MUST X.500 specify states 93 documents.

	the MUST X.500 does not specify which of the
	ITU recommendations must be implemented.  One must
	assume the complete series (including elective
	recommendations) must be implemented.

	the MUST X.500 overrules any other SHOULD or MAY in
	the document (or related documents) which is counter
	to X.500.

	Encoding of directory information in LDAP makes
	it actually quite difficult, maybe impossible, to
	truely act in accordance to X.500(93) recommendations.
	[Case in point: LDAP representation of DNs]

additional comments inline...

At 09:25 AM 4/11/00 +1000, Lloyd, Alan wrote:
>
>
>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 ?

many types of LDAP clients and servers... but only one protocol.
Just like we have today.

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

Reuse.
Just like we have today.

>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

Yes, they need to detect the features they need.
Just like we have today.

>and the protocol is still lightweight ?

Yes.
Just like we have today.

>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

But here lies part of the problem.  If X.500 were truely a MUST,
then LDAP would just be a DAP replacement.  However, LDAP goes
beyond replacing DAP but infact attempts to replace the X.500
information model with it's own.

Many LDAPext'ers say LDAP is an access protocol to X.500 directories
and then, pretty much in the same breath, say LDAP can selective
replace portions of the X.500 directory model.

>- 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?

You've just described the Internet... funny thing is, it,
for better or worse, does works.  It's amazing how so-called
"better" approaches have failed.  History has shown that
flexible protocols survive where rigid protocols fail...
and that implementations of flexible protocol specfications
converge on true interoperabiliity just as fast (if not
faster) than those of more rigid protocols specfications.

>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".

Your addition could be taken that X.500 is somehow going to solve the
compatibility issues.  It won't.  There are enough other SHOULDs
and MAYs which make this addition more appropriate (IMO):
	"Different implementations of LDAP MAY behave differently."

>> 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"..

I agree that X.500 has an extensible "information model".
I was referring to LDAPext's continuing efforts to supplant
X.500 with their own Information model [ala LDAPsubentry,
ala LDAP ACM, referrals, ala ...], which IMO is disallowed
by the MUST X.500.

I prefer to allow LDAP to support "pure" X.500 implementations,
this LDAP directory model (which is like X.500, but not X.500),
as well as other information models.

>	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..

I believe lightweight still applies to protocol, but not necessarily
to applications classes.  However, I see no reason to burden all
implementations of LDAP to ease the burden for subsets of application
classes.  In particular, management applications need to know much
more about the server than a general browswer.  A general browser
should be easy to implement and require little feature discovery
and no apiori knowledge of the service it's browsing.  However,
a management client will likely need a wealth of feature discover
and some (if not a lot) of apiori knowledge of the service its
managing.

I don't believe using MUSTs will solve the management client
interoperability problem.... vendors will always have
different (so they can market their wares) and these differences
will require that some clients use feature discover or have
apiori knowledge of the differences.

Attempts to solve this problem, don't.  But they do reduce the
flexibility of the protocol.

>	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.

The current state of LDAP is my example.  It's the flexibility of
flexibility of LDAPv2 and lazy implementations which enabled
LDAP to grow to what it is.  Should we have disallowed U-Mich
from implementing slapd, a very non-X.500 solution?  Should we
disallow most major LDAP vendors from continuing to provide
their unique (and often very un-X.500) solutions?  Should we
continue to define LDAP specifications which remove the complexity
of X.500 (ie: are not X.500)?  Should we not continue to allow
LDAP to support other X.500 varients (87,97)?

MUST X.500 has largely been ignored, and IMO, rightly so.

>	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..

This seems like an argument for discontinuing LDAPext efforts
that supplant X.500 with an LDAP model.