RE: ldap PICS

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

What this discussion is saying that the keywords used in any text are
open to the context in which it is used!. Tables are good and precise
for representing protocol fields and information support and by these
place mandatory, optional and conditional statements.
People May or Should not like them - but I think we Must stop convincing
ourselves that a a few keywords embedded in the dozens of LDAP specs
(which is now a monolithic pile of protocol, schema, formats and labels,
etc) is the right way to build quality commercial products.

As said I think the more one adds to LDAP the worse it will get - simply
because its engineering basis cannot be realistically be tested and
operationally will be nothing but massive interoperability problems - in
the protocol, the schema, the labels, the transactions, the paged
results and the referral behaviour...

Would anyone on this list like to distil all the LDAP specs into a set
of tables of Musts, Shoulds and Mays -- 
If this cannot be done ie a LDAP  paper conformance exercise - how on
earth can anyone code the thing as a real life conformance exercise for
commercial product?


Regards alan


> -----Original Message-----
> From:	Harald Tveit Alvestrand [SMTP:Harald.Alvestrand@maxware.no]
> Sent:	Sunday, June 07, 1998 5:31 PM
> To:	d.w.chadwick@iti.salford.ac.uk; Alan Lloyd; 'Christopher Oliva';
> 'LDAP EXT'
> Subject:	RE: ldap PICS
> 
> At 23:20 06.06.98 +0000, David Chadwick wrote:
> >This is not quite true. ISO also has SHALL and MAY, SHALL being 
> >equivalent to IETF MUST. The ISPs are there to sort out which MAYs 
> >should be implemented and which should be ignored. Consider 93 X.500 
> >replication - all of it is MAY in the standard. How do you get 
> >interworking if none of it is mandatory, and the number of options in
> 
> >the MAYs is large. Answer, the ISP on replication. This is what ISPs 
> >are for - to sort out which MAYs to implement, not the SHALLs/MUSTs.
> 
> Are you saying that if DISP was a separate standard, all the required
> MAYs
> in its specification would be MUSTs, and there would be no need for
> the ISP?
> In IETF standards, this is usually a "conditional MUST" - you MAY
> support this feature, but if you do, you MUST do this other thing.
> Example: You MAY support IPSec, but if you do, you MUST support 3DES.
> 
> Hard to do right with monolithic protocols, and can easily be
> confusing
> if done as "base protocol plus extensions", like LDAP is trying to do.
> (LDAPEXT folks: Take care!)
> 
> >BTW, just what does IETF SHOULD mean - by pure logic if a feature is 
> >not MUST then it must be MAY, is it not? (Work that one out :-)
> 
> SHOULD is an indication that not doing it is stupid in most cases, but
> interworkable. Or that's how it SHOULD be :-)
> Yes, by Aristotelean logic it's equivalent to MAY. But Aristotelean
> logic
> is not a complete tool for describing real-world operation.
> 
>                    Harald
> -- 
> Harald Tveit Alvestrand, Maxware, Norway
> Harald.Alvestrand@maxware.no