RE: Extensibility of SearchRequest.attributes

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

Well, as you point out, in one breath RFC 2251 disallows the "*" string,
and in another, it allows it. It is not self consistent. I believe the
intent may have been to allow special strings. Furthermore, other
Internet-Drafts that describe new special strings have made significant
progress with no apparent concern from community members
(draft-zeilenga-ldap-opattrs (Proposed Standard, under IESG Evaluation),
 and draft-zeilenga-ldap-adlist). We either need to allow special
strings to be defined, or disallow anything other than "*" and empty,
and raise a red flag concerning those two I-D's

Jim

>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 4/6/03 7:27:49 PM >>>
Why do you believe special strings can be used. I looked at RFC 2251
and, regarding 'attributes', it says there are two special values. One
is no values at all and the other is the string "*". The ASN.1 defines
'attributes' to be of type AttributeDescriptionList, which would seem to
disallow arbitrary strings?

I think it is weirdness and that, as Mark Smith says, controls should
be used to cause special behaviours.

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:jimse@novell.com] 
Sent: Saturday, 5 April 2003 03:37
To: mcs@netscape.com; Kurt@OpenLDAP.org 
Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org 
Subject: Re: Extensibility of SearchRequest.attributes


I think the first thing to do is get consensus on whether new special
attributes are allowed. 

I believe the intent of RFC 2251 is that special strings can be used
to
request different things in the return attributes, thus it itself
allows
a *. I further believe that the RFC simply missed the point that it
was
self-inconsistent in the way it defined the data type for the return
attr specification. Thus, I believe it needs to a) fix the
inconsistency, b) allow for future special strings, and possibly c)
define how future extensions should be defined.

I'm fine with the suggestion Kurt made, though I'm still nervous about
the proliferation of special strings. I'd really like to see some "x-"
mechanism available--but I agree, that can be done outside the scope
of
ldapbis.

Unless there are other opinions, I will assume consensus is that we do
(a) and (b) above.

Jim

>>> Mark C Smith <mcs@netscape.com> 4/4/03 8:13:41 AM >>>
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


Kurt D. Zeilenga wrote:
>
> 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