Re: [ldapext] RE: Extensibility of SearchRequest.attributes

[Michael Ströder <michael@stroeder.com>]

Volpers, Helmut wrote:
> I am a little bit confused about the examples of the special attributes.
>
> I have no problem if your server supports this special attributes, but
> I hope your client will not send it to my server.

I hope your server won't crash when receiving these special attributes in a 
search request. ;-)

> How will your client decide whether this attributes can be used (Vendors
> Name ?).

A client can look at attribute 'supportedFeatures' in RootDSE. My client is 
checking for 1.3.6.1.4.1.4203.1.5.1 (defined in draft-zeilenga-ldap-opattrs) 
and then sends '+'.

Ciao, Michael.

> > -----Original Message-----
> > From: Jim Sermersheim [mailto:jimse@novell.com]
> > Sent: Freitag, 4. April 2003 02:04
> > To: mcs@netscape.com
> > Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org
> > Subject: Re: Extensibility of SearchRequest.attributes
> >
> >
> > Yes, here are some examples of special attributes:
> >
> > Attribute        Meaning
> > "*"              All User Attrs (P-S RFC)
> > "+"              All Operational Attrs (S-T I-D)
> > "+"<classname>   All Attributes of an object class (I-T I-D)
> > "*;lang-"<xx>    All User Attrs with lang-xx (no spec yet on
> > remaining)
> > "@"<uri>         All Attrs listed at uri
> > "*MCSN>"<csnval> All User Attrs who's mod CSN is greater than that
> > specified
> > "*Len<"<len>     All User Attr val's less than len octets
> > "^"              No virtual attributes
> > "^^"             No collective attributes
> > "$"              Only static (no dynamically calculated) attributes
> > ":-("            Attributes with deleted/unpurged values
> > "+dirOp"         All directoryOperation operational
> > "+distOp"        All distributedOperation operational
> > "+dsaOp"         All dsaOperation operational
> > "#"<syntaxOID>   All attributes belonging to specified syntax
> >
> > Obviously, there are many (inconsistent) ways to express these, and
> > there are no guidelines or instructions to those who want to 
> > create new
> > special attributes but don't want to collide with special attributes
> > being defined by other people.
> >
> > Jim
> >
> >
> > > > > Mark C Smith <mcs@netscape.com> 4/3/03 12:07:48 PM >>>
> >
> > Jim Sermersheim wrote:
> >
> > > I believe this data type needs to be re-defined in the LDAPBis work,
> >
> > and
> >
> > > I believe there needs to be a more formal way of extending it with
> > > "special" values.
> > >
> > > Currently (in both RFC 2251, and LDAPBis work), this data type does
> >
> > not
> >
> > > allow the string "*" (or the proposed "+" for that matter). Both
> > > specifications restrict it to a list of attribute descriptions. An
> > > attribute description must either be a numeric oid, or begin with a
> > > alpha. Yet both have "special wording" like: "There are two special
> > > values which may be used: an empty list with no attributes, and the
> > > attribute description string "*". Both of these signify that all
> >
> > user
> >
> > > attributes are to be returned. (The "*" allows the client to request
> >
> > all
> >
> > > user attributes in addition to any specified operational
> >
> > attributes).".
> >
> > > Another proposal furthers this and allows "+" to indicate that all
> > > operational attributes are to be returned, and other proposals for
> >
> > other
> >
> > > special strings are in the works.
> >
> > Can you provide some examples? I am generally in favor of allowing for
> >
> > extensions in many areas, but I am not convinced we need to 
> > allow it in
> >
> > this specific area.
> >
> > -Mark