Subject: Re: Extensibility of SearchRequest.attributes

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 03 Apr 2003 17:03:55 -0700

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

---

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

OK; thanks for the list. I hope I never have to implement support for 
all of these in a server (not that each one is very difficult; this is 
just a long list).

A side note: it makes sense to me to express concepts like "all" in an 
AttributeDescriptionList, but I think it makes more sense to use a 
control to modify how the entire list is processed. So I would use a 

 > ":-("            Attributes with deleted/unpurged values

The "*Len<" one is included because I might want to say "return values 
for attributes a, b, c whose length is less than 1000 octets" or "return 
all operational attributes whose length is less than 512 octets."

Controls have other nice properties: collisions can't happen (due to use 
of OIDs), handling of unknown controls is well defined, etc.

-Mark Smith
  Netscape

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 04 Apr 2003 10:09:30 -0700

ldapbis has everything to do with interoperability. The fact that you
hope no client sends one of these strings to your server, and the fact
that there are currently no instructions on what should happen if one
does means that thisis a topic for ldapbis.

ldapbis needs to tell servers that it's ok, for unknown strings (which
are invalid attribute names) to be sent, and for servers to ignore those
unknown strings.

Jim

>>> "Volpers, Helmut" <[email-masked]> 4/4/03 1:41:15 AM
>>>
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
> 
>

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 04 Apr 2003 10:13:37 -0700

Yeah, I just popped these off the top of my head--some are more
reasonable than others. I'm not sure that I plan to implement any or all
of them. The nice thing about not defining a control is that clients
don't have to be re-compiled.

>>> Mark C Smith <[email-masked]> 4/4/03 8:24:37 AM >>>

just a long list).

for attributes a, b, c whose length is less than 1000 octets" or
"return 
all operational attributes whose length is less than 512 octets."

Controls have other nice properties: collisions can't happen (due to
use 
of OIDs), handling of unknown controls is well defined, etc.

-Mark Smith
  Netscape

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 04 Apr 2003 10:36:33 -0700

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 <[email-masked]> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 04 Apr 2003 09:41:04 -0800

At 09:36 AM 4/4/2003, Jim Sermersheim wrote:
>the proliferation of special strings. 

Requiring that specials be extended by standard track specifications
(until someone defines a general specials extension mechanism) will
slow proliferation.

Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 7 Apr 2003 11:27:49 +1000

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:[email-masked]]
Sent: Saturday, 5 April 2003 03:37
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Extensibility of SearchRequest.attributes

Jim

-Mark Smith
  Netscape

specials

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 07 Apr 2003 08:38:08 -0600

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" <[email-masked]> 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:[email-masked]] 
Sent: Saturday, 5 April 2003 03:37
To: [email-masked]; [email-masked] 
Cc: [email-masked]; [email-masked] 
Subject: Re: Extensibility of SearchRequest.attributes

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.

Jim

mechanism for AttributeDescriptions is a new LDAP feature and should
be

-Mark Smith
  Netscape

specials

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 8 Apr 2003 11:28:35 +1000

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:[email-masked]]
Sent: Tuesday, 8 April 2003 00:38
To: Ramsay, Ron; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Extensibility of SearchRequest.attributes

Jim

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Saturday, 5 April 2003 03:37
To: [email-masked]; [email-masked] 
Cc: [email-masked]; [email-masked] 
Subject: Re: Extensibility of SearchRequest.attributes

Jim

-Mark Smith
  Netscape

specials

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 07 Apr 2003 23:57:00 -0600

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" <[email-masked]> 4/7/03 7:28:35 PM >>>

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.

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

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Tuesday, 8 April 2003 00:38
To: Ramsay, Ron; [email-masked]; [email-masked] 
Cc: [email-masked]; [email-masked] 
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

'attributes' to be of type AttributeDescriptionList, which would seem

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Saturday, 5 April 2003 03:37
To: [email-masked]; [email-masked] 
Cc: [email-masked]; [email-masked] 
Subject: Re: Extensibility of SearchRequest.attributes

Jim

-Mark Smith
  Netscape

specials