Re: Dereference Control

[Pierangelo Masarati <ando@sys-net.it>]

Hallvard B Furuseth wrote:
> Pierangelo Masarati writes:
> > - does BER allow to have an empty set/sequence?
>
> Yes.
>
> > Apparently, I'm unable to set an empty set using ber_printf("[]").
>
> You could look at the OpenLDAP code for RFC 4511's
>   PartialAttribute.vals    - can be an empty SET OF AttributeValue.
>   SearchRequest.attributes - can be an empty SEQUENCE OF LDAPString.
> (No opinion on whether that's better than making it OPTIONAL or
> something, I haven't looked at what this is about yet.)

That's what I've done so far.  The current specification I'm delineating is:


/*
 * 1. Specification
 *
 * 1.1 Request
 *
 *  controlValue ::= SEQUENCE OF DerefSpec
 *
 *  DerefSpec ::= SEQUENCE {
 *      derefAttr       attributeDescription,    ; DN-valued
 *      attributes      AttributeList }
 *
 *  AttributeList ::= SEQUENCE OF attr AttributeDescription
 *
 *
 * 1.2 Response
 *
 *  controlValue ::= SEQUENCE OF DerefRes
 *
 * From RFC 4511:
 *      PartialAttribute ::= SEQUENCE {
 *           type       AttributeDescription,
 *           vals       SET OF value AttributeValue }
 *
 *      PartialAttributeList ::= SEQUENCE OF
 *                           partialAttribute PartialAttribute
 *
 *  DerefRes ::= SEQUENCE {
 *      derefAttr       AttributeDescription,
 *      derefVal        LDAPDN,
 *      attrVals        PartialAttributeList
 *
 * 2. Examples
 *
 * 2.1 Example
 *
 * 2.1.1 Request
 *
 * { { member, { GUID, SID } }, { memberOf, { GUID, SID } } }
 *
 * 2.1.2 Response
 *
 * { { memberOf, "cn=abartlet,cn=users,dc=abartlet,dc=net",
 *     { GUID, [ "0bc11d00-e431-40a0-8767-344a320142fa" ],
 *       SID, [ "S-1-2-3-2345" ] } },
 *   { memberOf, "cn=ando,cn=users,dc=sys-net,dc=it",
 *     { GUID, [ "0bc11d00-e431-40a0-8767-344a320142fb" ],
 *       SID, [ "S-1-2-3-2346" ] } } }
 *
 * 2.2 Example
 *
 * 2.2.1 Request
 *
 * { { member, { cn, uid, drink } } }
 *
 * 2.2.2 Response
 *
 * { { member, "cn=ando,cn=users,dc=sys-net,dc=it",
 *     { cn, [ "ando", "Pierangelo Masarati" ],
 *       uid, [ "ando" ] } } }
 */

Right now, the implementation only looks for exact attribute 
descriptions; probably, we should consider the possibility to:

  - honor inheritance both in derefAttr & type

  - allow objectClasses as shortcuts for attribute sets in attributes

but I don't want to complicate things too much right now.

This brings me to consider the possibility to selectively stop honoring 
inheritance in otherwise regular operations.  I was initially thinking 
of something like a special language tag option ("x-nosubs"), but this 
would probably violate RFC 3688 in many places.  So I'm more inclined 
towards a control that lists what attributes and objectClasses in a 
request (search and compare requests, by now) should not honor 
inheritance, possibly using separate sets for filtering and 
requested/asserted attributes.  I'll probably post a separate message 
for this food for thoughts...

I have another issue in mind: given the above specification, if the same 
derefAttr appears in more than one DerefSpec, one could hardly tell 
which DerefSpec one DerefRes belongs to.  For example:

	request: { { member { cn, sn } }, { member { uid } } }
	response: { { member, "cn=ando" }, { member, "cn=ando" } }

because the client's identity had read access to entryDN but not to cn, 
sn, uid attrs, we'd have a duplicate result.  Of course, this could have 
been much better formulated as

	request: { { member { cn, sn, uid } } }
	response: { { member, "cn=ando" } }

for this reason I'm inclined towards requesting that each derefAttr in a 
sequence of DerefSpec to be unique.

I'll complete the client side library and commit things shortly, 
definitely by next week.

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------