Subject: Extensibility of SearchRequest.attributes

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 02 Apr 2003 15:32:17 -0700

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.

To start with, I think the current restriction needs to be lifted in
the ldapbis work. The easiest thing to do here is to redefine
SearchRequest.attributes as SEQUENCE OF OCTET STRING. It would be a
little better to define it as a type that has an associated restriction
described in ABNF, where the restriction is like, but less than the
current attributedescription restriction.

Furthermore, I forsee other "special strings" being introduced, and
believe that we'll run out of handy things like * + # $ % etc (beside's
they become less and less intuitive). I suggest we come up with some
generalized standard extensibility mechanism for this. Something like
putting special strings inside parens would work, and would allow the
tradition of setting "x-" prefixed strings aside as experimental. Here's
my suggested ABNF for a single search attribute (refer to
http://ietf.org/internet-drafts/draft-ietf-ldapbis-models-07.txt for
elements not defined here):

searchattribute = descr / numericoid / %x2A / specialsearchattr

specialsearchattr = LPAREN WSP (standardspecialsearchattr /
experimentalspecialsearchattr) WSP RPAREN

standardspecialsearchattr = 1*(%x21-28 / %x2A-7E)

experimental = X HYPHEN standardspecialsearchattr

Jim

---

From: [email-masked] (Mark C Smith)
Date: Thu, 03 Apr 2003 14:07:48 -0500

> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 03 Apr 2003 21:46:28 -0800

At 02:32 PM 4/2/2003, Jim Sermersheim wrote:
>SearchRequest.attributes as SEQUENCE OF OCTET STRING.

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

---

From: [email-masked] (Mark C Smith)
Date: Fri, 04 Apr 2003 10:13:41 -0500

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