Subject: Re: Feature discovery (Was: RFC 2596 questions)

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 15 Sep 2000 14:33:17 -0600

Whatever the discovery mech is, I'd rather we have it and be rarely used than not have it at all. Also, some things (like attr type options) need more than just an OID in a list. We need to specify where they can be used (which attrs or syntaxes support them).

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 9/15/00 2:01:22 PM >>>
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: [email-masked]
Date: Fri, 15 Sep 2000 16:58:18 -0400

Jim wrote:
Whatever the discovery mech is, I'd rather we have it and be  rarely used
than not have it at all. Also, some things (like attr type options)  need
more than just an OID in a list. We need to specify where they can be used
(which attrs or syntaxes support them).

Doesn't this imply then that support of the attribute tags should be
discovered as part of schema discovery?

Karen

Internet: [email-masked]
Internal: Karen Gdaniec/Endicott/IBM@IBMUS or
                 IBMUSM10(KGDANIEC)
phone: 607.752.1075   tie-line: 8/852-1075
fax: 607.752.3681
---------------------- Forwarded by Karen Gdaniec/Endicott/IBM on
09/15/2000 04:57 PM ---------------------------

"Jim Sermersheim" <[email-masked]> on 09/15/2000 04:33:17 PM

To:   <[email-masked]>, Timothy Hahn/Endicott/IBM@IBMUS
cc:   <[email-masked]>
Subject:  Re: Feature discovery (Was: RFC 2596 questions)

Whatever the discovery mech is, I'd rather we have it and be  rarely used
than not have it at all. Also, some things (like attr type options)  need
more than just an OID in a list. We need to specify where they can be used
(which attrs or syntaxes support them).

Jim

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?

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 15 Sep 2000 14:37:00 -0700

>Also, some things (like attr type options) need more than just an OID in a list. We need to specify where they can be used (which attrs or syntaxes support them).

Likely best to extend the attributeTypes and LDAPsyntaxes to include
additional fields... like X-FEATURES ( 1.2.3 $ 2.3.4 )  where 1.2.3
might indicate language tags support and 2.3.4 might indicate binary
transfer support.

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 18 Sep 2000 10:51:48 -0600

A couple other considerations dealing with approach 2 are:

- It allows an ATO (attribute type option) to be tied to any attribute that is of a given syntax.
- This type of not-so-easy-searching already has to be done for name forms, content rules, and structure rules. This follows the existing paradigm. I will say however, that I don't much like the existing paradigm as far as name forms and structure rules are concerned, I'd rather see that info in the object class. Oh well, side issue...

An issue with approach 1:
- Whether a server supports ATOs will largely be due to built-in support (unless a plug-in architecture is provided by the vendor). If the advertisement of the support is on the attributetype, who will populate it? In other words, If I extend the schema to include a new attributetype, Am I expected to supply the supported ATOs? What if I do, and the server can't handle them? Does the server auto-fill attributetypes with unspecified ATOs that it can support?

Jim

>>> <[email-masked]> 9/16/00 5:00:50 AM >>>

Hi all, 

I like the idea of extending the schema information with the set of attribute descriptions that are known to the server. 

Both approaches described so far: 

1) extend the attributeTypes value to allow for additional fields to be specified within each value, add a new value that defines the OIDs used in the field 
2) add a new attribute to the subschemasubentry and contain all the information here 

are in the right direction. 

Approach 1) has the benefit that just by looking at the attributeType value, you can get an indication if any attribute descriptions might have been used in creating/modifying entries that contain this attribute.  However, there would be the issue of whether or not the server supported the additional data in the attributeTypes value. 

Approach 2) doesn't change the attributeType value definition (nice for upward compatibility).  On the downside, though, in order to see what attribute description a given attribute type can have attached to it, a not-so-easy-search of the new schema attribute would have to be performed. 

After writing up this short discussion of the approaches, I think I prefer Approach 1) where the "DESCRIPTORS ( <OID> "$" ... )" clause of the attributeTypes value is an optional piece in the format of the value. 

Is there agreement here?

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

To:        "Jim Sermersheim" <[email-masked]> 
cc:        Timothy Hahn/Endicott/IBM@IBMUS, <[email-masked]> 
Subject:        Re: Feature discovery (Was: RFC 2596 questions) 

Kurt

---

From: Brian Jarvis <[email-masked]>
Date: Mon, 18 Sep 2000 14:13:37 -0600

I am hesitant to put language elements into the schema for two (so far)
reasons.
1.  If a particular language is not advertised in the schema, it would imply
that I cannot add an element with that language.
2.  It would greatly expand the number of schema elements.

--the walrus

[email-masked]

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Friday, September 15, 2000 3:29 PM
To: [email-masked]; [email-masked]
Subject: Re: Feature discovery (Was: RFC 2596 questions)

You mean advertised in the schema, right? I would say yes, I think there
should be another schema element called something like attributeTypeOptions,
the syntax would look something like this (ala 2252 nomenclature):
 
AttributeTypeOptionDescription = "(
   numericoid whsp ; Attribute Type Option Identifier
   [ "NAME" qdescrs ]
   [ "DESC" qdescrs ]
   [ "OBSOLETE" whsp ]
   "APPLIES TO" whsp "ALL" | (("SYNTAX" | "ATTRIBUTE") oids) ; list of
syntaxes or attributes that this ATO applies to.
   whsp ")"

Jim