Sorry, I was plain wrong. RFC 4512, par. 4.1.2 states that :
"Usage of userApplications, the default, indicates that attributes of
this type represent user information. That is, they are user attributes."
So the userApplications value is the default, and this parameter is not
inherited from a SUP :
"If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING fields,
if not specified, take their value from the supertype."
Emmanuel Lecharny wrote:
Hi,
I had to remove the default initialization of the USAGE parameter for
AttributeType, as we need to check that an injected AT is correct, and
it might not be the case if it has a SUP which is not a
UserApplications AT.
Let me explain the problem with some example. Let's assume we have 2
AT, 'parent' and 'child' :
( 2.5.4.3 NAME 'parent' USAGE directoryOperation )
( 2.5.4.4 NAME 'child' SUP parent )
as child inherit from parent, it must have the same Usage value. In
this case, everything is fine, as we don't have a USAGE specified, as
soon as the USAGE does not default to UserApplications, otherwise we
have an error :
( 2.5.4.3 NAME 'parent' USAGE directoryOperation )
( 2.5.4.4 NAME 'child' SUP parent USAGE userApplications ) /!\ Not
allowed /!\
Now, if we don't store the Usage with a default value (
userApplications ), we can deal with the first case, as Usage will be
null. If we don't have a SUP, we then can default to userApplications.
Things get a bit muddier when the AT has a COLLECTIVE flag set, as now
the USAGE *must* be userApplications.
Sadly, the description parser for such a case throw an exception when
trying to parse :
( 2.5.4.3 NAME 'cn' SUP name COLLECTIVE )
as it does not know that the SUP has a userApplications Usage.
IMO, we have to fix this by assuming that the SUP has necessarily a
userApplications USAGE when we have a SUP *and* a COLLECTIVE
parameters in the string. If we don't have a SUP, then we can default
USAGE to userApplications.
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
