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

From: [email-masked]
Date: Mon, 18 Sep 2000 14:56:48 -0400

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: [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/18/2000 02:51 PM ---------------------------

"Jim Sermersheim" <[email-masked]> on 09/18/2000 12:51:48 PM

To:   <[email-masked]>, 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

>>> <[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)

>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: "Steven Legg" <[email-masked]>
Date: Fri, 22 Sep 2000 12:40:28 +1100

Karen,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, 19 September 2000 5:57
> To: [email-masked]; [email-masked]

I like this approach, especially when viewed from the perspective
of replication and the X.500 schema administrative model. The
information about what attribute type options a server is *capable*
of supporting is specific to that server. It is not appropriate
for that information to be replicated or held in the schema definition
for a DIT subtree that is distributed across multiple servers
(as allowed by X.500). The root DSE is a reasonable place to hold this
kind of information. The information about what attribute type
options are *permitted* to be used with what attribute types is
part of the schema configuration and it seems entirely appropriate
to me to allow this to be in the subschema subentry (where it can
be replicated).

The separation also deals with the variant uses of the attribute type
options. The options that don't imply attribute subtyping
(e.g. ;binary) have no business being described in the schema subentry
as far as I'm concerned.

Regards,
Steven

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 23 Sep 2000 12:11:56 +0100

Steven wrote

> I like this approach, especially when viewed from the perspective of
> replication and the X.500 schema administrative model. The information
> about what attribute type options a server is *capable* of supporting
> is specific to that server. It is not appropriate for that information
> to be replicated or held in the schema definition for a DIT subtree
> that is distributed across multiple servers (as allowed by X.500). The
> root DSE is a reasonable place to hold this kind of information. The
> information about what attribute type options are *permitted* to be
> used with what attribute types is part of the schema configuration and
> it seems entirely appropriate to me to allow this to be in the
> subschema subentry (where it can be replicated).

I agree with this

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************