Hi Stephen, Sorry, this one was delayed whilst I was away (helping run a training workshop, then Easter). On Tuesday 31 March 2009 17:46:47 Burke, S (Stephen) wrote:
[extensible filters instead of GlueChunkKey] For one thing you can't do wildcard queries with the extensible query format,
I spent a little bit of time investigating this. It's actually a complex, somewhat interesting and layered issue. Having read (only the relevant bits of ;-) RFC-4511 I couldn't find anything to suggests that one cannot use substring match rules in an extensible filter. However, from my reading of the RFC, it seems that the people writing LDAPv3 spec. didn't really consider substring-like extensible filters since the ABNF in RFC-4515 removes the ability to specify an ASTERISK character in extensible filters. In contrast, the ABNF in RFC-4511 (sec. 4.5.1) does not contain this restriction. See: http://tools.ietf.org/html/rfc4515#section-3 The restriction in RFC-4515 contradicts RFC-4511 (sec. 4.5.1.7.7). When describing extensible filters, it says: http://tools.ietf.org/html/rfc4511#section-4.5.1.7.7 The matchingRule used for evaluation determines the syntax for the assertion value. [...] So, using a substring-like matching rule should allow substring-like assertion values, in contradiction with the ABNF in RFC-4515. In summary, one should be able to conduct substring query by explicitly specifying the matchingRule in an extensible filter. However, all of this is doesn't matter since OpenLDAP currently doesn't support substring-like extensible filters. Scanning through the src-code of the latest version, it seems to make a tacit assumption that the assertion value is formatted for exact-match-like filters and ASTERISK characters are forbidden. However, even this is immaterial since clients MUST NOT (as in RFC 2119) conduct wildcard searches against the DN. On page 5 of GLUE v2.0 spec: [...]. The ID MUST NOT be interpreted by the user or the system as having any meaning other than an identifier. [...] Currently, we use the object's ID attribute in the RDNs to build the DNs. I believe filtering using a substring-like filter would imply that the ID attributes have some searchable structure, which contradicts the "[not] having any meaning" bit above. So, I interpret this to mean clients MUST NOT use wildcard searches in the DN.
and for another it's often useful to query *for* the chunkey so you can extract the relevant ID, which is a lot easier than extracting it from the DN.
This is certainly true: LDAP provides a very limited ability to search across links (effectively dereferencing a link). As an aside: there was a proposal to add support for cross-querying by adding a new matchingRule; however, the proposal seems to have been shot down due to interop. concerns. With the scheme David is proposing, we could include the upward pointing links. Omitting the objectClass declarations, this could be: dn: GlueStorageShareID=someShare,GlueStorageServiceID=someSE, AdminDomain=aGridSite,o=grid GlueStorageShareID: someShare GlueStorageShareName: example storage share GlueStorageShareStorageService: someSE Cheers, Paul.