Subject: RE: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 19 Nov 1999 12:49:51 -0800

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Friday, November 19, 1999 7:27 AM
> To: Mark Smith
> Cc: Peter Strong; Paul Leach (Exchange); Mark Meredith; ietf-ldapext
> Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt
> 
> 
> I'm thinking we just need to define an operational attribute for the
> root DSE:
> 
> supportedFeature
>    
>    The values of this attribute are OBJECT IDENTIFIERs identifying the
>    supported optional or vendor-defined features which the 
> server supports.
>    
>     ( supportedFeatureOID NAME 'supportedFeature'
>      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
> 
> The key is that it lists features directly and eliminates the
> need to maintain out of band feature lists for each vendor version.

This sounds fine to me. Having vendor name and version is fine, too, as long
as it is _explicitly_ declared that it isn't to be used to discover
features.

In addition to the above, shouldn't one look at supported controls, and what
classes exist, rather than try to categorize everything as a "feature"?

---

From: Helmut Volpers <[email-masked]>
Date: Sun, 21 Nov 1999 10:47:24 +0100

Hi,

> "Paul Leach (Exchange)" schrieb:
> 
> This sounds fine to me. Having vendor name and version is fine, too,
> as long as it is _explicitly_ declared that it isn't to be used to
> discover features.

I agree that the vendor name (or product name) and version is fine to
find
out with which product and which version I interwork etc. We for example
support 
RFC 1565 (Network Services Monitoring MIB) where all this information
is already availible and it will not be a problem to make this
information
availible to a ldap-client when it retrieves the Root.
But I hope we will not encourage client implementors to build there
clients
that they derive special features of the product from this information.
For example: we support schema publishing over ldap but if an
administrator
set the access control that  only special users (administrators) can
read
the ldapsubschema-subentry then a client have to live without exploring
the
schema.
> 
> In addition to the above, shouldn't one look at supported controls,
> and what classes exist, rather than try to categorize everything as a
> "feature"?

Can somebody give me a real example for this feature list ? Is it
something
like:

Supported features: TLS, Cram-MD5, schema-publishing, LDAP-ACL,
Ldap-replication , etc ??

Bye

Helmut