RE: Extensibility of SearchRequest.attributes

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

Ron, you're absolutely right about the control thing. There is nothing
that can be done with a special string that can't be done with a
control. Special strings have the advantage that oftentimes existing
applications can just use them without being re-compiled.

I do not think we can allow "+", and disallow others. How would such a
thing be worded in 2251bis without "extending"? Oh, I know. It can say
that all attrDescriptions are allowed, as well as the "*" string, and
also any future extensions, so long as they only use the "+" string. ha
ha ha.

Consensus seems murky on this topic. Does anyone else out there have
further input?

Jim

>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 4/7/03 7:28:35 PM >>>
I hadn't realised that "+" was PS and that it had passed last call.

However, as "*" only returns normal attributes, and as operational
attributes have to be named to be returned, perhaps there is a case for
"+". X.500 has a framework for this - a comparable facility in LDAP
would have been another item, say "op-attributes" after the item
"attributes". But that is water under the bridge.

I'd like to see the nonsense stop at "+".

A control could serve for the other uses, you just need an I-D to
define an OID and some strings (or integers?)

Extended-EIS:Control=
 OID:Name=x.y.z
 Boolean:Criticality
 ANY:Value=@Table

Table=(table of values and meanings)

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:jimse@novell.com] 
Sent: Tuesday, 8 April 2003 00:38
To: Ramsay, Ron; mcs@netscape.com; Kurt@OpenLDAP.org 
Cc: ldapext@ietf.org; ietf-ldapbis@OpenLDAP.org 
Subject: RE: Extensibility of SearchRequest.attributes


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