Re: [ldapext] empty-groupOfNames-issue

[Michael Ströder <[e-mail]>]

Simo Sorce wrote:
> I do not agree with this conclusion.
> Realxing the constraint from MUST to MAY is forward compatible, and
> older tools can keep doing what they always did.
> 
> Given there is no provision in the old or new groupOfNames to have
> members that "make sense", software always need to be prepared to deal
> with bogus members, so p) is not a "problem to solve".
> 
> You may have a point with q) if you want to deal with a generic
> management system, but then your proposal to create a new objectlcass
> adds exactly the same problem, as the management system need to know
> what to use, except it makes it worse in 2 ways:
> 1) you have no way to find out what to do just by inspecting the schema
> because both classes may be in the schema, which do you choose ?
> 2) you have to change all client applications that are hardcoded to use
> groupOfNames
> 
> Looking at 1) and 2) then q) is a comparatively little price to pay.
> 
>> On the other hand, the corrupt version of groupOfNames does serve as
>> a proof that groupOfEntries is desired by the community because it is
>> functionally identical.
> 
> Yet it is not identical, see 2) above.

I concur with Simo: The issues are almost non-issues because applications
already have to deal with the non-standard variants today.

Also in practice I see much less client applications capable to properly add
dummy 'member' values, and if they do you have to explicitly configure it anyway.

The only soft issue is that changing 'groupOfNames', after careful
considerations of course, could be abused as an example to request more
quick&dirty changes in standardized schema (probably without careful
considerations).

Ciao, Michael.