Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Note
titleWork 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.

...

No Format
   SubtreeSpecification = "{"    [ sp ss-base ]
                             [ sep sp ss-specificExclusions ]
                             [ sep sp ss-minimum ]
                             [ sep sp ss-maximum ]
                             [ sep sp (ss-specificationFilter / 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

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