RE: (ITS#4670) Problem with nisNetgroupTriple SYNTAX definition according to Sun support

[Kurt@OpenLDAP.org]

At 07:42 PM 9/11/2006, Neulinger, Nathan wrote:
>> ># Syntaxes are under 1.3.6.1.1.1.0 (two new syntaxes are defined)
>> >#       validaters for these syntaxes are incomplete, they only
>> >#       implement printable string validation (which is good as the
>> >#       common use of these syntaxes violates the specification).
>> >
>> >So, here's what I'm unclear on is what the behavior of 
>> searches will be?
>> 
>> The attribute type is described as having no equality, no
>> ordering, and no substrings rules, hence equality, ordering
>> and substrings assertions should and do evaluate to Undefined.
>
>That seems like a pretty harsh read of the spec,

I believe it is the only reasonable read of the specifications.

The reality of the specification's failure to specify desired
rules for various attribute types might be harsh.  But that's
another matter (one which is far beyond the scope of the
Issue Tracking System).

The question here is whether or not slapd(8) properly implements
applicable specifications for this attribute type.  The applicable
specifications, in addition to the LDAP Technical Specification
[RFC 4510], is RFC 2307.  RFC 2307 clearly specifies 'nisNetgroupTriple'
attribute type as having no EQUALITY, no ORDERING, and no SUBSTR
matching rule.  The LDAP Technical Specification is clear that
for an attribute type equality, ordering, or substrings assertion
requires an attribute type whose description states the rule.
In absence of the rule, one has no knowledge of the assertion
syntax or matching semantics.

I don't see any problem with slapd(8) validation of
values of the nisNetgroupTripleSyntax syntax.  If you do,
I suggest you file a new report detailing the issue.  In
particular, the report should include examples of
values improperly considered valid or invalid.

Kurt