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

From: "Mark Meredith" <[email-masked]>
Date: Wed, 02 Feb 2000 10:27:53 -0700

I am getting ready to do the second draft for vendor info.

In going over all of the responses I have some questions about the supportedFeature, and whether or not I should include it in this draft?

The examples that Helmut asks about at the end: "Supported features: TLS, Cram-MD5, schema-publishing, LDAP-ACL, Ldap-replication , etc ??"

I think that these should be specified in their own specific attributes. I am afraid that if something like supportedFeatures were present, it could become a catch all for every new proposal, it may even get to the point that it would be very hard to sift through the information to find what you are looking for?

So what does everyone think?  Should I just go forward with the vendorName and vendorVersion and let the supportedFeatures be a separate draft if at all? Or have all three in this draft?

-Mark

Mark Meredith
Novell Inc
122 E. 1700 S. Provo UT 84606
[email-masked]
801-861-2645
---------------------
A boat in the harbor is safe, 
but that is not what boats are for.
--John A. Shed
---------------------

>>> Helmut Volpers <[email-masked]> 11/21/99 02:47AM >>>
Hi,

> "Paul Leach (Exchange)" schrieb:
> 
> > -----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.

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