> Specifically, in looking how the NAC is proposing a conformity test which
> will effectively give vendors a base line stamp of approval for their
> LDAP implementation, I must ask the question, What will this baseline
> test prove? If the lowest common denominator for interoperability means
> that an LDAP client from one vendor can access an LDAP server from
> another vendor, does that really fulfil the promise of the spec?

Absolutely. That is precisely the key promise made by having a vendor-OS-independent, vendor-hardware-independent, open, *network protocol* specification. I.e. this is just basic LDAP "motherhood and apple pie" stuff.

So, testing and demonstrating base-line multi-vendor interoperability on a highly heterogeneous network is quite interesting.

> I understand that many vendors are choosing to implement LDAP extensions
> above this baseline as a means to a competitive advantage, but who is to
> say that those will work with other implementations?

Well, no one. But, "interoperation" in terms of something as complex as an extensible directory protocol, such as LDAP, has a large potential solution space. Here's an example that I hope will help clairfy this..

If you have a client from one vendor that implements the core ldap protocol plus some (sub)set of the documented protocol extensions (see below), and a server from another vendor implementing the core ldap protocol plus it own particular (sub)set of the documented protocol extensions, then..

• they will (read: "certainly oughtta") interoperate smoothly within the set of core protocol operations AND the intersection (if any) of their protocol extension (sub)sets.
  
  
• they should (if they're quality implementations) gracefully fail operations which fall outside of the above intersection.
  
  
• they might have ungraceful interoperability problems due to differing interpretations of the protocol specs and perhaps implementation bugs that affect each other.

And so testing these assertions is a resonable and interesting thing to do. For any given pair of client and server, one would hope that the first two assertions are true and the last is false. But only conclusive way to know is to actually do hands-on, active testing.

On one hand, such testing will benefit vendors by actively uncovering implementation and interoperability bugs, and on the other it will benefit customer orgs by..

• providing information about which products have been specificly tested together and how they performed, and,
  
  
• helping to promote vendor interoperability.

This is quite important because, for example, the directory service providers at an organization may well not have any control over the set of clients users will use (that's our situation here at stanford). Users at many orgs are going to be able to simply download most anything off the Internet and give it a go. In this sort of case it is imperative for the service providers to be able to decide on a given server vendor, and thus a service feature profile, independent to some extent of the clients users acquire. Having knowledge of the results of interoperability testing is invaluable in this situation. It aids directory service providers in making a set of statements in their service profile such as..

• if you choose to use clients from vendors I, J, and K, you'll be able to exercise the full user-visible feature set of our directory service, and we offer this full set of support services (e.g. ref manuals, FAQs, etc) for their use; or,
  
  
• if you choose to use clients from vendors L, M, and N, you can expect to only be able to utilize these service features, and we offer only this level of support (perhaps less than above); or,
  
  
• if you choose to use clients from vendors X, Y, and Z, you can expect only this stuff to work, and you are also taking a chance that this or that (e.g. client crash) might happen, and you are completely on your own, we offer no support at all for these clients; or,
  
  
• if you choose to use some other client not mentioned here, it is probable that core query-level functionality will work, if the client is sufficiently configurable in order to make sense of our directory schema, but we, the directory service providers, make no claims and nothing is guaranteed to work.

> Which extensions do you think are appropriate to undergo interoperability
> testing ...

Well, ideally all implemented ldap protocol extensions ought to receive multi-vendor client/server interoperability testing.

Specifically, a directory service provider will want to have done (and/or have hard evidence that it was done) testing sufficient to make whatever claims they make in their service profile.

> ... in order that the end users will be able to get real benefits
> from the LDAP-enabled products that they buy.

I believe the core protocol functionality is such that end users will likely see a definite benefit from clients that at least properly implement that level of functionality. I say "likely", tho, because the actual utility delivered to the user via the directory service (i.e. the union of the clients and the server(s)) rides at least as much on the quality of the information placed in the target directory, and the quality of the organization of that info, as it is on the quality of the client and server implementations.

I hope this helps answer your questions. Even tho LDAP is "Lightweight" (i.e. compared to the X.500 protocol standards & implementations), directory services, and thus LDAP, are inherently complex.

I.E. there's no accurate short answers. 8^)

There are two legit flavors of "extensions" a given client and/or server implementation may incorporate..

  1. legitimate (i.e. defined via IETF process) ldap *protocol* extensions. 
     e.g see...
 
      http://info.internet.isi.edu:80/in-drafts/files/


           draft-ietf-asid-ldapv3ext-04.txt
           draft-ietf-asid-ldapv3-sorting-00.txt
           draft-ietf-asid-ldapv3-tls-01.txt
           draft-ietf-asid-ldapv3-simple-paged-01.txt
           draft-ietf-asid-ldapv3-strong-00.txt
 
  2. vendor-specific client and/or server *implementation features* 
     e.g...
 
        - which particular (sub)set of authentication capabilities are 
          implemented.
 
        - what sort of authorization capabilities are implemented. Note that 
          authorization (as opposed to authentication) conventions and 
          capabilities are not defined in the ldap protocol spec and thus 
          are left entirely up to vendors to design and implement. See below 
          for brief explanation of authentication vs. authorization.
 
        - what sort of server and directory-content creation, configuration, 
          and adminstration features are implemented, and also what sort
          of client configuration capabilities are impl'd. (these are 
          non-trivial aspects of vendor differentiation).

..and one clearly "illegit" (from an "openness" perspective), and one "grey-area" case..

  3. An illegit ldap protocol extension would be some material change to the 
     protocol itself (e.g. defining a new protocol operation) that is not 
     defined in terms of the protocol extension capability that is an intregal 
     part of the ldap protocol spec, and that is not openly documented and 
     incorporated in the specs via the IETF process.
 
  4. A grey-area ldap protocol extension would be one that is implemented via 
     the legit extension mechanisms defined in the ldap specs, but that is not 
     openly documented via the IETF process. 

Authentication and authorization are orthogonal, but related concepts. First, 
two parties authenticate, and then they decide what each is authorized to do...
 
 
  authentication ::= "I (the client) am who I say I am, please validate 
                      it via these credentials."
 
                           plus, perhaps...
 
                     "And I (the server) am who I say I am, here's my 
                      credentials."
 
 
  authorization ::= "ok, so I (the server) now knows who this requestor is, 
                     and I have info specifying what operations 
                     it may specifically perform on any given 
                     entry and/or attribute. So, I'll let it go for it, 
                     and let it know if it oversteps its bounds."