I don't think it matters. If we weren't going to allow it in a 4.0.1 then it would have been pushed separately but if we're doing either then whatever we build off will be the tip of master anyway.

I probably should have initiated a discussion before pushing this to master. I was assuming either a 4.0.1 or a 4.1.0, but not both. Likely an ill informed decision. I'm happy to revert this and push to the appropriate branch if that's the decision.

I know it’s a bug fix so allowable, but I’d sooner see this in an earlier than anticipated 4.1 than a 4.0.1

However the messaging and timing is important (I’d like to get at least the beta of the module installer stuff in 4.1 and that’s is several weeks out at best) 

Fixed in ea76bef8aa25bfbde881f8a43f76c948115d2a5a

Couple of comments about the current implementation:

• <AuthenticationType /> is deprecated for v5 in favor of <SASLConfig />

• <SASLProperty /> elements are currently mapped to a few specific properties which only support single values. (Unlike their corresponding java properties which may be multi-valued.) Ldaptive v2 will add support for arbitrary properties.

  •  javax.security.sasl.qop

  • javax.security.sasl.strength

  • javax.security.sasl.server.authentication

• The mechanism attribute was not mapped to an enum in order to more easily support new mechanisms without updating the schema.