...
Another questions rises, as we change the syntax: Do we have to define a new attribute type like extendedSubtreeSpecification or ldapSubtreeSpecification?
Again considering the last question, the following syntax can be proposed:
No Format |
---|
SubtreeSpecification = "{" [ sp ss-version ]
[ sp ss-base ]
[ sep sp ss-specificExclusions ]
[ sep sp ss-minimum ]
[ sep sp ss-maximum ]
[ sep sp ss-specificationFilter ]
[ ss-ldapFilter ]; >>> The new element <<<
sp "}"
ss-version = "version" msp SubtreeSpecificationVersion
ss-base = "base" msp LocalName
ss-specificExclusions = "specificExclusions" msp SpecificExclusions
ss-minimum = "minimum" msp BaseDistance
ss-maximum = "maximum" msp BaseDistance
ss-specificationFilter = "specificationFilter" msp Refinement
ss-ldapFilter = "ldapFilter" msp LdapFilter; http://tools.ietf.org/html/rfc4515#section-3
SubtreeSpecificationVersion = ( "basic" / "extended" / .. )
SpecificExclusions = "{" [ sp SpecificExclusion
*( "," sp SpecificExclusion ) ] sp "}"
SpecificExclusion = chopBefore / chopAfter
chopBefore = "chopBefore" ":" LocalName
chopAfter = "chopAfter" ":" LocalName
|
In this syntax, if the version is "basic", only specificationFilter is considered in evaluations. If the version is "extended", only ldapFilter is considered in evaluations. Both of the filter elements can coexist and evaluation depends on the version information. Default value of the version is "basic". This scheme is backward compatible with RFC3672. It can be improved for future needs unless breaking the backward compatilibity.