RE: ldap PICS

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Yes 
	this is absolutey necessary and error management/precedence
processing should also be on the list. 

In fact the PICS/ISP process is the thing that really shakes out the
real implementations from the ones that are the engineering  "proof of
concept" variety.

In the ISO/ITU world, the rules are - that the standard cannot reach
Draft International status without a PICS - and from that ISPs are
produced. That way we dont end up with so many variances of non
interoperating implementations. ie. customers get some comfort with
stability in standards.

It would seem obvious the same process needs to be applied by the IETF,
but I am not sure if they want that or want to regulate such events and
processes.  So this is where all this "lightweight - add a bit here and
there if you want to -  process" all breaks down.
Also once you start down this track one needs "freeze dates" for the
implementation just like ISO/ITU eg 1993, 1997, etc.

So its a question of does the IETF- LDAP development process want to
institutionalise any sort of doctrine which stabilises the specification
process so that implementations can at least be compatable to a common
reference point defined by a PICS and ISP OR;
 is it business as usual where any bits can be added to "LDAP" at any
time without too much concern for stability or correctness or
compatability.

My recent comments and concerns and from many dealing with directories -
eg. re ACL, non deleteing deletes, signed ops and all the issues with
LDAP in general, are symptomatic of the mess being created by LDAP.

There are two options in my book:

1) LDAP business as usual - more "bits" justs compounds the mess,
customers recognise the mess, industry just does not bother to invest in
it because: too unstable, does not scale, no trust in the system, can be
derailed by "yet another bright idea on the fly".. and commercially
there is no money in putting technology into an organisation which costs
an LDAP army to configure and maintain it.

2) Doctrine is provided to the development and release process via PICS
and ISPs - any new features are discussed and scheduled into the
Standard/PICs release process - IETF works like the ISO.

If the second approach is an option, perhaps for starter we could take
the DAP PICS format and the X.500 schema ISP format and just  modify
that.

It seems that in an exercise to make a lightweight directory protocol so
that directory things can be the same, the multitude of mechanisms and
options (which may or may not be compatable) can in fact make things
quite different.

regards alan

  
> -----Original Message-----
> From:	Christopher Oliva [SMTP:Chris.Oliva@entrust.com]
> Sent:	Saturday, May 30, 1998 9:12 AM
> To:	'LDAP EXT'
> Subject:	ldap PICS
> 
> Hi,
> 
> Has anyone created a conformance statement template which is
> applicable to
> LDAP vendors? If not perhaps this should be addressed by the group. It
> would
> be nice to be able to identify exact functionality of clients and
> servers so
> 
> you can compare products or specify common profiles for
> interoperability.
> 
> There are many features of LDAP which may or may not be provided and
> which
> may or may not be mapped to X.500 features. This would include details
> about
> ldap versions, SSL/TLS versions and CipherSuites, which authentication
> mechanisms are supported and how they map to authentication levels in 
> X.500, what operational attributes are supported, subschema entries
> and
> attributes within those entries which define the schema, referrals and
> URL
> formats, aliases, matching rules ..... and the list goes on.
> 
> Since there are now ldap v3 directories available, how can we compare
> them 
> or even determine a common subset of functionality? 
> 
> Chris.
> 
> 
> -----------------------------------------
> Chris Oliva
> Entrust Technologies
> 
> (613) 248-3014
> Chris.Oliva@entrust.com
> http://www.entrust.com
> -----------------------------------------