DRIVERS-3439 Remove pre-MongoDB 4.2 references from specs and tests (#1929)

Remove spec tests and prose gated on MongoDB server versions < 4.2,
now that 4.2 is the minimum supported server version.

    - YAML spec test files deleted if no tests in them run post 4.0
    - Individual tests removed from mixed files
    - Normative spec text simplified across all spec documents - removed
      dead version/wire-version-gated behavior, pseudocode branches, and
      prose conditions that can never be false at a 4.2 floor
    - Prose/integration test instructions updated across ~15 test READMEs.
      Removed un-runnable version requirements and vacuous "X.Y or
      higher" qualifiers; outdated numbered prose tests marked "Removed".
    - Dead comments cleaned from YAML test files (comment-only changes)
    - Minimum Server Version front matter headers removed from specs
      whose stated minimum was below 4.2

Historical/rationale content (e.g. "Version 4.0 of the server
introduces...", Design Rationale sections, @SInCE annotations) was
intentionally left in place, as were minServerVersion/maxServerVersion
test gates regardless of value.

Author: jyemin

source/auth/auth.md

@@ -1,7 +1,6 @@
 # Authentication
 
 - Status: Accepted
-- Minimum Server Version: 2.6
 
 ______________________________________________________________________
 
@@ -103,8 +102,8 @@ Userinfo or authentication parameters in connection options MUST NOT be interpre
 #### Errors
 
 Drivers SHOULD raise an error as early as possible when detecting invalid values in a credential. For instance, if a
-`mechanism_property` is specified for [MONGODB-CR](#mongodb-cr), the driver should raise an error indicating that the
-property does not apply.
+`mechanism_property` is specified for a mechanism that does not support it, the driver should raise an error indicating
+that the property does not apply.
 
 Drivers MUST raise an error if any required information for a mechanism is missing. For instance, if a `username` is not
 specified for SCRAM-SHA-256, the driver must raise an error indicating the the property is missing.
@@ -147,8 +146,7 @@ Drivers MUST follow the following steps for an authentication handshake:
     type. If the `hello` or legacy hello of the MongoDB Handshake fails with an error, drivers MUST treat this as an
     authentication error.
 2. If the server is of type RSArbiter, no authentication is possible and the handshake is complete.
-3. Inspect the value of `maxWireVersion`. If the value is greater than or equal to `6`, then the driver MUST use
-    `OP_MSG` for authentication. Otherwise, it MUST use `OP_QUERY`.
+3. Drivers MUST use `OP_MSG` for authentication.
 4. If credentials exist: 3.1. A driver MUST authenticate with all credentials provided to the MongoClient. 3.2. A single
     invalid credential is the same as all credentials being invalid.
 
@@ -162,8 +160,6 @@ All blocking operations executed as part of the authentication handshake MUST ap
 
 #### Mechanism Negotiation via Handshake
 
-- Since: 4.0
-
 If an application provides a username but does not provide an authentication mechanism, drivers MUST negotiate a
 mechanism via a `hello` or legacy hello command requesting a user's supported SASL mechanisms:
 
@@ -177,8 +173,7 @@ in the auth credential. The username MUST NOT be modified from the form provided
 SASLprep), as the server uses the raw form to look for conflicts with legacy credentials.
 
 If the handshake response includes a `saslSupportedMechs` field, then drivers MUST use the contents of that field to
-select a default mechanism as described later. If the command succeeds and the response does not include a
-`saslSupportedMechs` field, then drivers MUST use the legacy default mechanism rules for servers older than 4.0.
+select a default mechanism as described later.
 
 Drivers MUST NOT validate the contents of the `saslSupportedMechs` attribute of the initial handshake reply. Drivers
 MUST NOT raise an error if the `saslSupportedMechs` attribute of the reply includes an unknown mechanism.
@@ -198,13 +193,8 @@ Drivers with a list of credentials at the time a connection is opened MAY do mec
 handshake, but only for the first credential in the list of credentials.
 
 When authenticating each credential, if the authentication mechanism is not specified and has not been negotiated for
-that credential:
-
-- If the connection handshake results indicate the server version is 4.0 or later, drivers MUST send a new `hello` or
-    legacy hello negotiation command for the credential to determine the default authentication mechanism.
-- Otherwise, when the server version is earlier than 4.0, the driver MUST select a default authentication mechanism for
-    the credential following the instructions for when the `saslSupportedMechs` field is not present in a legacy hello
-    response.
+that credential, drivers MUST send a new `hello` or legacy hello negotiation command for the credential to determine the
+default authentication mechanism.
 
 ### Caching credentials in SCRAM
 
@@ -232,9 +222,6 @@ used when running the authentication spec tests.
 
 ### Default Authentication Methods
 
-- Since: 3.0
-- Revised: 4.0
-
 If the user did not provide a mechanism via the connection string or via code, the following logic describes how to
 select a default.
 
@@ -255,101 +242,22 @@ be used as the default, regardless of whether SCRAM-SHA-1 is in the list. Driver
 mechanism (e.g. PLAIN) as the default.
 
 If `saslSupportedMechs` is not present in the handshake response for mechanism negotiation, then SCRAM-SHA-1 MUST be
-used when talking to servers >= 3.0. Prior to server 3.0, MONGODB-CR MUST be used.
+used as the default.
 
 When a user has specified a mechanism, regardless of the server version, the driver MUST honor this.
 
-#### Determining Server Version
-
-Drivers SHOULD use the server's wire version ranges to determine the server's version.
-
-### MONGODB-CR
-
-- Since: 1.4
-- Deprecated: 3.0
-- Removed: 4.0
-
-MongoDB Challenge Response is a nonce and MD5 based system. The driver sends a `getnonce` command, encodes and hashes
-the password using the returned nonce, and then sends an `authenticate` command.
-
-#### Conversation
-
-1. Send `getnonce` command
-
-    ```javascript
-    CMD = { getnonce: 1 }
-    RESP = { nonce: <nonce> }
-    ```
-
-2. Compute key
-
-    ```javascript
-    passwordDigest = HEX( MD5( UTF8( username + ':mongo:' + password )))
-    key = HEX( MD5( UTF8( nonce + username + passwordDigest )))
-    ```
-
-3. Send `authenticate` command
-
-    ```javascript
-    CMD = { authenticate: 1, nonce: nonce, user: username, key: key }
-    ```
-
-As an example, given a username of "user" and a password of "pencil", the conversation would appear as follows:
-
-```javascript
-CMD = {getnonce : 1}
-RESP = {nonce: "2375531c32080ae8", ok: 1}
-CMD = {authenticate: 1, user: "user", nonce: "2375531c32080ae8", key: "21742f26431831d5cfca035a08c5bdf6"}
-RESP = {ok: 1}
-```
-
-#### [MongoCredential](#mongocredential) Properties
-
-- username
-
-    MUST be specified and non-zero length.
-
-- source
-
-    MUST be specified. Defaults to the database name if supplied on the connection string or `admin`.
-
-- password
-
-    MUST be specified.
-
-- mechanism
-
-    MUST be "MONGODB-CR"
-
-- mechanism_properties
-
-    MUST NOT be specified.
-
 ### MONGODB-X509
 
-- Since: 2.6
-- Changed: 3.4
-
 MONGODB-X509 is the usage of X.509 certificates to validate a client where the distinguished subject name of the client
 certificate acts as the username.
 
-When connected to MongoDB 3.4:
-
 - You MUST NOT raise an error when the application only provides an X.509 certificate and no username.
 - If the application does not provide a username you MUST NOT send a username to the server.
 - If the application provides a username you MUST send that username to the server.
 
-When connected to MongoDB 3.2 or earlier:
-
-- You MUST send a username to the server.
-- If no username is provided by the application, you MAY extract the username from the X.509 certificate instead of
-    requiring the application to provide it.
-- If you choose not to automatically extract the username from the certificate you MUST error when no username is
-    provided by the application.
-
 #### Conversation
 
-1. Send `authenticate` command (MongoDB 3.4+)
+1. Send `authenticate` command
 
     ```javascript
     CMD = {"authenticate": 1, "mechanism": "MONGODB-X509"}
@@ -371,7 +279,7 @@ When connected to MongoDB 3.2 or earlier:
 
 - username
 
-    SHOULD NOT be provided for MongoDB 3.4+ MUST be specified and non-zero length for MongoDB prior to 3.4
+    SHOULD NOT be provided
 
 - source
 
@@ -393,8 +301,6 @@ TODO: Errors
 
 ### SASL Mechanisms
 
-- Since: 2.4 Enterprise
-
 SASL mechanisms are all implemented using the same sasl commands and interpreted as defined by the
 [SASL specification RFC 4422](http://tools.ietf.org/html/rfc4422).
 
@@ -428,12 +334,6 @@ SASL mechanisms are all implemented using the same sasl commands and interpreted
 
 ### GSSAPI
 
-- Since:
-
-    2.4 Enterprise
-
-    2.6 Enterprise on Windows
-
 GSSAPI is kerberos authentication as defined in [RFC 4752](http://tools.ietf.org/html/rfc4752). Microsoft has a
 proprietary implementation called SSPI which is compatible with both Windows and Linux clients.
 
@@ -557,8 +457,6 @@ configuration option is set to `false`.
 
 ### PLAIN
 
-- Since: 2.6 Enterprise
-
 The PLAIN mechanism, as defined in [RFC 4616](http://tools.ietf.org/html/rfc4616), is used in MongoDB to perform LDAP
 authentication. It cannot be used to perform any other type of authentication. Since the credentials are stored outside
 of MongoDB, the `$external` database must be used for authentication.
@@ -605,8 +503,6 @@ MongoDB supports either of these forms.
 
 ### SCRAM-SHA-1
 
-- Since: 3.0
-
 SCRAM-SHA-1 is defined in [RFC 5802](http://tools.ietf.org/html/rfc5802).
 
 [Page 11 of the RFC](http://tools.ietf.org/html/rfc5802#page-11) specifies that user names be prepared with SASLprep,
@@ -691,8 +587,6 @@ RESP = {conversationId: 1, payload: BinData(0,"dj1VTVdlSTI1SkQxeU5ZWlJNcFo0Vkh2a
 
 ### SCRAM-SHA-256
 
-- Since: 4.0
-
 SCRAM-SHA-256 extends [RFC 5802](http://tools.ietf.org/html/rfc5802) and is formally defined in
 [RFC 7677](https://tools.ietf.org/html/rfc7677).
 
@@ -1903,19 +1797,18 @@ def reauth(connection):
 
 - authMechanism
 
-    MONGODB-CR, MONGODB-X509, GSSAPI, PLAIN, SCRAM-SHA-1, SCRAM-SHA-256, MONGODB-AWS
+    MONGODB-X509, GSSAPI, PLAIN, SCRAM-SHA-1, SCRAM-SHA-256, MONGODB-AWS
 
-    Sets the Mechanism property on the MongoCredential. When not set, the default will be one of SCRAM-SHA-256,
-    SCRAM-SHA-1 or MONGODB-CR, following the auth spec default mechanism rules.
+    Sets the Mechanism property on the MongoCredential. When not set, the default will be SCRAM-SHA-256 or SCRAM-SHA-1,
+    following the auth spec default mechanism rules.
 
 - authSource
 
     Sets the Source property on the MongoCredential.
 
 For GSSAPI, MONGODB-X509 and MONGODB-AWS authMechanisms the authSource defaults to `$external`. For PLAIN the authSource
-defaults to the database name if supplied on the connection string or `$external`. For MONGODB-CR, SCRAM-SHA-1 and
-SCRAM-SHA-256 authMechanisms, the authSource defaults to the database name if supplied on the connection string or
-`admin`.
+defaults to the database name if supplied on the connection string or `$external`. For SCRAM-SHA-1 and SCRAM-SHA-256
+authMechanisms, the authSource defaults to the database name if supplied on the connection string or `admin`.
 
 - authMechanismProperties=PROPERTY_NAME:PROPERTY_VALUE,PROPERTY_NAME2:PROPERTY_VALUE2
 
@@ -1960,8 +1853,6 @@ Connection string tests have been defined in the associated files:
 
 ### SCRAM-SHA-256 and mechanism negotiation
 
-Testing SCRAM-SHA-256 requires server version 3.7.3 or later with `featureCompatibilityVersion` of "4.0" or later.
-
 Drivers that allow specifying auth parameters in code as well as via connection string should test both for the test
 cases described below.
 
@@ -2143,6 +2034,8 @@ practice to avoid this. (See
 
 ## Changelog
 
+- 2026-06-17: Remove additional pre-4.2 version references.
+
 - 2025-11-25: Remove redundant `*.mongodbgov.net` on `ALLOWED_HOSTS`
 
 - 2025-11-19: Extend `ALLOWED_HOSTS` with `*.mongo.com` and `*.mongodbgov.net`

source/bson-decimal128/decimal128.md

@@ -1,15 +1,14 @@
 # BSON Decimal128
 
 - Status: Accepted
-- Minimum Server Version: 3.4
 
 ______________________________________________________________________
 
 ## Abstract
 
-MongoDB 3.4 introduces a new BSON type representing high precision decimal (`"\x13"`), known as Decimal128. 3.4
-compatible drivers must support this type by creating a Value Object for it, possibly with accessor functions for
-retrieving its value in data types supported by the respective languages.
+Decimal128 is a BSON type representing high precision decimal (`"\x13"`). Drivers must support this type by creating a
+Value Object for it, possibly with accessor functions for retrieving its value in data types supported by the respective
+languages.
 
 Round-tripping Decimal128 types between driver and server MUST not change its value or representation in any way.
 Conversion to and from native language types is complicated and there are many pitfalls to represent Decimal128
@@ -340,15 +339,12 @@ Most of the tests are converted from the
 
     - NumberDecimal("2.000")
 
-- Should a driver avoid sending Decimal128 values to pre-3.4 servers?
-
-    - No
-
 - Is there a wire version bump or something for Decimal128?
 
     - No
 
 ## Changelog
 
+- 2026-06-17: Remove pre-4.2 version references.
 - 2024-02-08: Migrated from reStructuredText to Markdown.
 - 2022-10-05: Remove spec front matter.

source/causal-consistency/causal-consistency.md

@@ -1,7 +1,6 @@
 # Causal Consistency Specification
 
 - Status: Accepted
-- Minimum Server Version: 3.6
 
 ______________________________________________________________________
 
@@ -196,9 +195,9 @@ started with `causalConsistency = true` then all operations using that session w
 
 There are no new server commands related to causal consistency. Instead, causal consistency is implemented by:
 
-1. Saving the `operationTime` returned by 3.6+ servers for all operations in a property of the `ClientSession` object.
-    The server reports the `operationTime` whether the operation succeeded or not and drivers MUST save the
-    `operationTime` in the `ClientSession` whether the operation succeeded or not.
+1. Saving the `operationTime` returned by servers for all operations in a property of the `ClientSession` object. The
+    server reports the `operationTime` whether the operation succeeded or not and drivers MUST save the `operationTime`
+    in the `ClientSession` whether the operation succeeded or not.
 2. Passing that `operationTime` in the `afterClusterTime` field of the `readConcern` field for subsequent causally
     consistent read and write operations (for all commands that support a `readConcern`)
 3. Gossiping clusterTime (described in the Driver Session Specification)
@@ -284,7 +283,7 @@ that causally consistent operations are not causally consistent with unacknowled
 Below is a list of test cases to write.
 
 Note: some tests are only relevant to certain deployments. For the purpose of deciding which tests to run assume that
-any deployment that is version 3.6 or higher and is either a replica set or a sharded cluster supports cluster times.
+any deployment that is either a replica set or a sharded cluster supports cluster times.
 
 1. When a `ClientSession` is first created the `operationTime` has no value.
     - `session = client.startSession()`
@@ -374,7 +373,7 @@ any deployment that is version 3.6 or higher and is either a replica set or a sh
 
 ## Motivation
 
-To support causal consistency. Only supported with server version 3.6 or newer.
+To support causal consistency.
 
 ## Design Rationale