[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt
I agree -- keep your draft focused on the vendor info. stuff. It will
be easier to make progress if you limit the scope of your document as
much as possible.
For the record, I don't like the idea of a general supportedFeature
attribute (for the reasons Mark M. mentioned). We already have
supportedExtension, supportedControl, supportedSASLMechanisms and so on,
which are fairly specific and line up clearly with LDAP protocol
extensions. I'd rather see us add additional specific attributes like
those (if someone can demonstrate a clear need).
--
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's. Got LDAP?
Gil Kirkpatrick wrote:
>
> Mark, I think you're right. The supportedFeature attribute can be a separate
> draft. I recommend getting the vendor info stuff done and consider the
> supportedFeature attr separately.
>
> -g
>
> Gil Kirkpatrick
> Director of Engineering
> NetPro
>
> > -----Original Message-----
> > From: Mark Meredith [SMTP:MMEREDIT@novell.com]
> > Sent: Wednesday, February 02, 2000 10:28 AM
> > To: paulle@Exchange.Microsoft.com; Helmut.Volpers@icn.siemens.de
> > Cc: kurt@boolean.net; ietf-ldapext@netscape.com; mcs@netscape.com;
> > pestrong@nortelnetworks.com
> > Subject: Re: I-D ACTION:draft-mmeredit-rootdse-vendor-info-00.txt
> >
> > 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 <mailto: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