Summary

Clarify that drivers MUST NOT reject index creation options based on the option name being unrecognized, and MUST NOT validate option values/semantics — that's the server's job. Add tests for a currently-unspecified option (finestIndexedLevel), an invalid option, and an out-of-range value.

Plan: https://gist.github.com/blink1073/82b27f6a951508bde2a2b690afde13d5

Motivation

Who is the affected end user?

Driver maintainers, and indirectly app developers using newer index options a driver hasn't explicitly enumerated.

How does this affect the end user?

Drivers with strict client-side option lists reject or drop valid, newer server options, forcing users to wait for a driver release.

How likely is it that this problem or use case will occur?

Edge case, but recurs every time the server adds a new index option.

If the problem does occur, what are the consequences and how severe are they?

Minor: a confusing driver-side error instead of the server's, or worse, a silently dropped option.

Is this issue urgent?

No. Spec clarification building on an existing informal note (SERVER-769).

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No — it also changes normative spec language.

Acceptance Criteria

• Spec states drivers MUST NOT reject options by unrecognized name and MUST NOT validate option values/semantics, without precluding a typed driver API's normal type conformance for options it explicitly models.
• Q&A entry and changelog entry added.
• New unified tests: finestIndexedLevel forwarded and accepted; invalid option surfaces server's InvalidIndexSpecificationOption (code 197); out-of-range finestIndexedLevel value surfaces the server's rejection.
• Behavior confirmed via a spike against a real server.