[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Dynamic group draft
Pierangelo Masarati writes:
>Jaimon Jose wrote:
>>> And how do I implement it? My client MUST NOT attempt to make use of
>>> dynamic group features without first checking that they are supported?
>>> What if it attempts to check but does not find the schema (or
>>> supportedExtension)? Should a server which does support the
>>> objectClasses attribute (or supportedExtension) refrain from supporting
>>> dynamic groups?
>>>
>> I'm not sure I understood this.
>
> As far as I understand, this point addresses clients that want to
> __create__ a dynamic group, rather than clients that want to __use__
> them.
Ah. Yes, that's what I meant. I was thinking "make use of" as a client
user. Also if you don't create them you can't use them. You can create
entries by building the LDAP database offline, but the LDAP standard
does not cover that so it's simpler to formally think of everything as
created by clients.
A few other points:
The Compare and Search operations match subtypes. If subtypes of
"member" and "uniqueMember" are not considered for static members,
then Compare(base DN, "member", candidate DN) and Search with
filter "(member=candidate DN)" are incorrect membership checks.
Maybe you should leave the behavior of static groups implementation-
defined and merely suggest a recommended practice:
A number of servers already implement groups based on member or
uniqueMember. Since such groups are not standardized, whatever the
draft says about static groups will surely conflict with several
implementations. Vendors may find it infeasible to switch from their
established behavior to what the draft says.
I suggest in any case to keep the behaviour of dynamic and static groups
a bit more separate in the draft, and then say that they do not affect
each other except that duplicates are removed - i.e. excludedMember only
excludes from memberQueryURL, not from static members. (Assuming I
haven't missed some other interaction.)
I suggested a dgAttribute which could specify that a group should
produce e.g. "roleOccupant" instead of "member". If you do that, it
would be better to put it in the attribue part of the URL - similar
to what Pierangelo said of an "x-nest" URL extension.
Both draft authors and Pierangelo seem to disagree with me about the
"x-" in URL extensions. Why do you put it there, if not to suggest that
the extension is private?
--
Regards,
Hallvard
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext