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

From: [email-masked]
Date: Sat, 16 Sep 2000 06:59:16 -0400

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:48:05 +1100

Tim,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, 16 September 2000 21:59
> To: [email-masked]
information here
> 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.
>

No, unless you can convince the X.500 committee to also extend the
definition of the syntax of the attributeTypes operational attribute.
If further fields are added to the LDAP string encoding of values of
the attributeTypes attribute then it will be out of sync with its X.500
ASN.1 syntax definition and BER encoding. That will be painful for
those of us with servers supporting both LDAP and X.500. The ldapSyntaxes
attribute is fair game though.

Regards,
Steven