Re: Feature discovery (Was: RFC 2596 questions)

[kgdaniec@us.ibm.com]

Jim,
Perhaps a combination of the approaches mentioned already really is needed,
then.  Servers could publish in their rootDSE the attributetype
options/extensions that they support.  This would allow anyone adding to or
modifying the schema to know what the server supports.  However, the server
could also publish as part of the schema what the "currently active" set of
attributetype "descriptors" (to use Tim's term) is.

Would these be specified by syntax or by attributetype, though, or both?
Setting these by syntax allows defaults to be in effect for each
attributetype.  I suppose this is no more confusing than  "default"
matching rules based upon syntax.

Karen

Internet: kgdaniec@us.ibm.com
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/18/2000 02:51 PM ---------------------------

"Jim Sermersheim" <JIMSE@novell.com> on 09/18/2000 12:51:48 PM

To:   <ietf-ldapext@netscape.com>, Timothy Hahn/Endicott/IBM@IBMUS
cc:
Subject:  Re: Feature discovery (Was: RFC 2596 questions)




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

>>> <hahnt@us.ibm.com> 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: hahnt@us.ibm.com
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"  <JIMSE@novell.com>
cc:        Timothy Hahn/Endicott/IBM@IBMUS,  <ietf-ldapext@netscape.com>
Subject:         Re: Feature discovery  (Was: RFC 2596 questions)




>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