Re: Extensibility of SearchRequest.attributes

["Jim Sermersheim" <jimse@novell.com>]

I think the first thing to do is get consensus on whether new special
attributes are allowed. 

I believe the intent of RFC 2251 is that special strings can be used to
request different things in the return attributes, thus it itself allows
a *. I further believe that the RFC simply missed the point that it was
self-inconsistent in the way it defined the data type for the return
attr specification. Thus, I believe it needs to a) fix the
inconsistency, b) allow for future special strings, and possibly c)
define how future extensions should be defined.

I'm fine with the suggestion Kurt made, though I'm still nervous about
the proliferation of special strings. I'd really like to see some "x-"
mechanism available--but I agree, that can be done outside the scope of
ldapbis.

Unless there are other opinions, I will assume consensus is that we do
(a) and (b) above.

Jim

>>> Mark C Smith <mcs@netscape.com> 4/4/03 8:13:41 AM >>>
I agree with the approach suggested by Kurt. Creating an extensibility

mechanism for AttributeDescriptions is a new LDAP feature and should be

out of scope for LDAPBis. But doing a little work in LDAPBis to allow 
for the possibility makes sense to me.

I am a little concerned about leaving the possibilities for "specials"

wide open. If we adopt the statement suggested by Kurt, then servers 
must accept any octet inside an AttributeDescription. Perhaps most 
implementations already do, but some may not.

-Mark Smith
  Netscape


Kurt D. Zeilenga wrote:
>
> We need to be careful here.
> 
> That said, another possibility would be to change it to:
>         SEQUENCE OF AttributeDescriptionOrSpecial
>         AttributeDescriptionOrSpecial ::= LDAPString
> 
> where the LDAPString is contains a value conforming to the
production:
>         attributeDescriptionOrSpecial = attributeDescription /
specials
>         specials = "*"
> 
> and a statement:
>         The specials production may be updated by standard track
>         technical specifications updating this document to allow
>         additional specials. Servers MUST treat specials they do
>         not recognize as unrecognized attribute types.
> 
> This leaves the exact form of a future specials up to
> future standard track technical specifications.
> 
> If one wanted to allow non-standard track specification of
> specials, then one could write a standard track specification
> defining a family of specials that have disambiguated by
> an IANA registry of specials.  I rather leave this to others
> (e.g., not LDAPBIS).
> 
> Kurt