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 -----------------------------------