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

From: "Volpers, Helmut" <[email-masked]>
Date: Fri, 4 Apr 2003 10:41:15 +0200

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:[email-masked]]
> Sent: Freitag, 4. April 2003 02:04
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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 <[email-masked]> 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
> 
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Michael Ströder <[email-masked]>
Date: Fri, 04 Apr 2003 10:56:56 +0200

> 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

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.