[glue-wg] LDAP Rendering

[Paul Millar]

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.