[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Dereference Control (Was: How to implement Extended DNs for Samba4?)
Pierangelo Masarati wrote:
Howard,
this is where I got so far with the specification (and the code :)
That's good progress. You said you'd start this weekend, so you're ahead of
schedule. ;)
/*
* request:
*
* controlValue ::= SEQUENCE OF DerefSpec
*
* DerefSpec ::= SEQUENCE {
* derefAttr AttributeDescription,
* attributes AttributeList }
*
* AttributeList ::= SEQUENCE OF attr AttributeDescription
*
*
* response:
*
* controlValue ::= SEQUENCE OF DerefRes
*
* DerefRes ::= SEQUENCE {
* spec DerefSpec,
* vals DerefVals }
*
* DerefVals ::= SEQUENCE OF DerefVal
*
* DerefVal ::= SEQUENCE {
* derefSpecVal AttributeValue,
* attrSets AttrSets }
*
* AttrSets ::= SEQUENCE of attrSet AttributeValues
*
* AttributeValues ::= SET OF value AttributeValue
*
*
* example request:
*
* { { member, { GUID, SID } }, { memberOf, { GUID, SID } } }
*
* example response:
*
* { { { memberOf, { GUID, SID } },
* { { "cn=abartlet,cn=users,dc=abartlet,dc=net",
* { { "0bc11d00-e431-40a0-8767-344a320142fa" },
* { "S-1-2-3-2345" } } },
* { "cn=ando,cn=users,dc=sys-net,dc=it",
* { { "0bc11d00-e431-40a0-8767-344a320142fb" },
* { "S-1-2-3-2346" } } } } } }
*/
I designed the response this way, because it'd allow to make it as
compact as possible while allowing for multiple as well as missing
attribute values in each attrSet. However I'm facing two issues, which
I can't solve directly since I don't have X.690 handy right now:
- does BER allow to have an empty set/sequence? Apparently, I'm unable
to set an empty set using ber_printf("[]").
I think we should avoid that, but I'll look it up later.
- does it make sense to have a structured response like this, where the
attribute types are listed first, and aggregate values follow, so that
the order of the value sets (including empty sets, if allowed) matches
the order of the attributes? I mean:
{ member, { cn, uid, drink } }
is supposed to match
{ "cn=Ando,dc=sys-net,dc=it",
{ [ "Ando", "Pierangelo Masarati" ], [ "ando" ], [] } }
such that set #0 ([ "Ando", "Pierangelo Masarati" ]) refers to attr #0
(cn), set #1 ([ "ando" ]) refers to attr #1 (uid), and set #2 ([])
refers to attr #2 (drink).
In fact, one could argue that the order in attrSets needs not
necessarily be the same of the attributes in spec. This would require
to use an alternative definition like
/*
* response:
*
* controlValue ::= SEQUENCE OF DerefRes
*
* DerefRes ::= SEQUENCE {
* derefAttrVal DerefAttrVal,
* attrsVals SEQUENCE OF attrVals DerefAttrsVals }
*
* DerefAttrVal ::= SEQUENCE {
* attr AttributeDescription,
* val AttributeValue }
*
* DerefAttrVals ::= SEQUENCE {
* attr AttributeDescription,
* vals SET OF val AttributeValue }
*/
which implies a repetition of all the attribute descriptions for each
derefAttrVal. Comments?
I theink DerefResponse should just be
DerefRes ::= SEQUENCE of Attribute
(See RFC4511 for Attribute)
I.e., there doesn't need to be a lot of structure here, and repeating the
AttributeDescription is fine. And we can ignore the issue of empty sets by
just not returning them if there's no corresponding value. (Same as a search
entry response, really.(
I have some question in my mind about whether we should accommodate returning
multivalued attrs in the response. I guess there's no reason not to, for the
general case. For the Samba use case it obviously won't make a difference.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/