…ge with newSuperior set to undef if we don't specify it in the options of moddn. Once encoded it doesn't get to the server in the message, so it's not a hack to find the base DN to which the newrdn is relative to since we cannot assume newSuperior is going to be in the moddn. This is the expected behaviour described in RFC 2251
…lways come from decoded moddn request.
From RFC 4511: 184.108.40.206. SearchRequest.scope Specifies the scope of the Search to be performed. The semantics (as described in [X.511]) of the defined values of this field are: baseObject: The scope is constrained to the entry named by baseObject. and 220.127.116.11. SearchRequest.filter A filter that defines the conditions that must be fulfilled in order for the Search to match a given entry. Nowhere does the RFC specify that the baseObject is excluded from the filters, and doing so would render the 'base' scope not nearly as useful.
DNs may contain spaces which the depth checking regex didn't expect. Use a Net::LDAP utility method to count the depth level properly and compare against the base's depth. t/05-scope.t now passes the previously TODOed tests.
Scope is enumerated as 0, 1, or 2 in the request data, but the auto_schema search method expected words. Additionally, when writing tests I discovered that a scope of 'one' doesn't work when the DN has spaces in it due to an incomplete regex pattern. Fix to follow.