[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Extensibility of SearchRequest.attributes



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
>