RE: Extensibility of SearchRequest.attributes

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

ldapbis has everything to do with interoperability. The fact that you
hope no client sends one of these strings to your server, and the fact
that there are currently no instructions on what should happen if one
does means that thisis a topic for ldapbis.

ldapbis needs to tell servers that it's ok, for unknown strings (which
are invalid attribute names) to be sent, and for servers to ignore those
unknown strings.

Jim

>>> "Volpers, Helmut" <helmut.volpers@siemens.com> 4/4/03 1:41:15 AM
>>>
Hi,

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.
How will your client decide whether this attributes can be used
(Vendors
Name ?).

I don't think its a topic for LDAPbis ?!

Helmut

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