Subject: Re: RFC 2596 questions

From: [email-masked]
Date: Fri, 15 Sep 2000 07:18:14 -0400

Greetings,

The discussion on this list regarding attribute descriptions has been 
quite useful to me - thanks for continuing it.  I also hope that 2251 bis 
is much better about spelling out how these are to be handled.

From the discussions so far on this list, it appears that attribute 
descriptions might be used in various ways.  The trouble with this is that 
it implies that there is no "generic method" for handling attribute 
descriptions since each one might imply some special code in the server 
you are contacting.  Unlike controls and extended operations, there is 
nothing in the rootDSE that gives any indication as to what attribute 
descriptions are supported or not.  Thus, the use of them will, at least 
for the moment, result in applications that don't work, in general, across 
different server implementations.

Should we investigate some additional rootDSE attribute to indicate the 
set of attribute descriptions that are supported?  Further, when a new 
attribute description is defined, should we be assigning OIDs and keeping 
these as an additional part of the subschemasubentry data?

I know of the following attribute descriptions that have been discussed:

;binary
;lang-<some code>

from the discussions on the list and the I-Ds and RFCs that have been 
published we have a sense of what each means.  Are there other attribute 
descriptions now proposed/defined?

One more observation:  there is currently a thread on the mailing list 
regarding "crosstalk issues" between multiple controls specified on LDAP 
operations.  It seems that we run the same risk with multiple attribute 
descriptions if we are not careful.

I think that the discussions over the past day have clarified alot of the 
intended handling of at least ;binary and ;land-<some code>.  Thanks!

I hope that we get the same level of detail into 2251 bis and the 
definition of future attribute descriptions.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 15 Sep 2000 13:01:22 -0700

At 07:18 AM 9/15/00 -0400, [email-masked] wrote:
>Should we investigate some additional rootDSE attribute to indicate the set of attribute descriptions that are supported?  Further, when a new attribute description is defined, should we be assigning OIDs and keeping these as an additional part of the subschemasubentry data?

I wouldn't mind too much having one attribute type "supportedFeatures" of
syntax OID which listed "supported" features.  This could include MAYs and
SHOULDs from the "core" specification as well as any MAY, SHOULD, MUST of
any extension.  This would provide a discovery mechanism for any feature
you might want to publish support for.

However, I wonder the value of providing additional discovery mechanisms
when the discovery mechanisms we already provide are rarely used and,
in some cases, not needed or inappropriate to use.  [Discovery of StartTLS
is not needed, discovery of SASL mechanisms is inappropriate without
appropriate consideration of security risks].

Kurt

---

From: Mark Wahl <[email-masked]>
Date: Mon, 18 Sep 2000 14:39:35 -0500

FYI the option "dynamic" was used by a draft which did not become an RFC.

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance