Work in progress

This site is in the process of being reviewed and updated.

Extending the subtreeSpecification syntax so that it allows an LDAP Filter (instead of)/(together with) a Refinement.

Current subtreeSpecification syntax is as follows:

   SubtreeSpecification = "{"    [ sp ss-base ]
                             [ sep sp ss-specificExclusions ]
                             [ sep sp ss-minimum ]
                             [ sep sp ss-maximum ]
                             [ sep sp ss-specificationFilter ]
                                   sp "}"

   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

   SpecificExclusions = "{" [ sp SpecificExclusion
                           *( "," sp SpecificExclusion ) ] sp "}"
   SpecificExclusion  = chopBefore / chopAfter
   chopBefore         = "chopBefore" ":" LocalName
   chopAfter          = "chopAfter"  ":" LocalName

The new proposed syntax is as follows:

   SubtreeSpecification = "{"    [ sp ss-base ]
                             [ sep sp ss-specificExclusions ]
                             [ sep sp ss-minimum ]
                             [ sep sp ss-maximum ]
                             [ sep sp ss-specificationFilter ]
                             [ sep sp ss-ldapFilter ]; >>> The new element <<<
                                   sp "}"

   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

   SpecificExclusions = "{" [ sp SpecificExclusion
                           *( "," sp SpecificExclusion ) ] sp "}"
   SpecificExclusion  = chopBefore / chopAfter
   chopBefore         = "chopBefore" ":" LocalName
   chopAfter          = "chopAfter"  ":" LocalName

Purpose of extending the syntax in this way is providing compatibility with existing subtree specifications.

One thing that needs to be answered is that what will happen if both specificationFilter and ldapFilter exist. We need to agree on a conflict resoution scheme here. For example, we may just ignore specificationFilter if ldapFilter exists or we may try to "merge" both. In order to make things clearer the following syntax which can no longer be converted to ASN.1 can be used:

   SubtreeSpecification = "{"    [ 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-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

   SpecificExclusions = "{" [ sp SpecificExclusion
                           *( "," sp SpecificExclusion ) ] sp "}"
   SpecificExclusion  = chopBefore / chopAfter
   chopBefore         = "chopBefore" ":" LocalName
   chopAfter          = "chopAfter"  ":" LocalName

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:

   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..

  • No labels