|
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 mark_meredith@novell.com 801-861-2645 --------------------- A boat in the harbor is safe, but that is not what boats are for. --John A. Shed --------------------- >>> Helmut Volpers <Helmut.Volpers@icn.siemens.de> 11/21/99 02:47AM >>> Hi, > "Paul Leach (Exchange)" schrieb: > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:kurt@boolean.net] > > 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 |