Re: please publish draft-mmeredith-rootdse-vendor-info-01.txt

[Roger Harrison <RHARRISON@novell.com>]

I agree wholeheartedly with your thoughts.  For documented server features, the best way to specify server behavior is by some standard mechanism.  There could even be some sort of grading provided to allow servers to specify which portions of a feature are implemented.

However, every server implementation has "quirks" (also sometimes known as bugs), which may not be known in advance of shipping the server.  A client that wants to interoperate with a server that doesn't do something quite right can be greatly aided if it knows the server's vendor and version.  Often there's a way to work around quirky behavior if that information is available.

Roger Harrison
Novell, Inc.

>>> Mark Wahl <M.Wahl@INNOSOFT.COM> 02/09/00 08:51AM >>>

Again, I believe this is the wrong approach to specifying server behavior 
and will not lead to interoperable clients.  

If there is a element of service X which two or more vendors implement 
differently, then there should be a proposal for a new attribute or similar
for the server to advertise how it implements X.

For example,

allowsMultipleSubschemas: TRUE

or

accessControlScheme: 1.2.3.4

A standards-track proposal would be best for each, because during the course
of discussion on the mailing list, we may find that the root DSE it not the 
best place for it, or there are more than an anticipated number of approaches
and so what was a BOOLEAN option flag might be better described some other way.

E.g. if a server uses chaining to automatically forward operations in a 
naming context to other servers which is a different implementation, then the 
capabilities that the chaining initiating server might advertise would 
potentially be more than if the server was not chaining.

Another example.  A server implementation allows the subschema subentry to
be modified to introduce new object classes, for compatibility with 
Netscape-oriented clients. It also allows subsubentries to be created below 
the subschema subentry to introduce new object classes, for compatibility with
Active Directory-oriented clients.  That server would advertise:

allowsSubschemaEntryModification: TRUE
implementsSubschemaLikeActiveDirectory: TRUE


> If a client relies on a vendorVersion number then that client MUST
> be coded to work with later versions and not just one version and
> no other.

I don't see how this would work at all.  If the first version of the server
ships on 1-JAN-2000, the client ships on 1-JAN-2001 and the next version of 
the server makes an incompatible change to something and ships on 1-JAN-2002,
that would mean that the client would need to know a year in advance what 
non-backwards compatible changes would be made.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.