DRIVERS-3439 Remove pre-MongoDB 4.2 references from specs and tests

source/auth/auth.md

@@ -103,8 +103,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.
@@ -162,8 +162,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:
 
@@ -232,9 +230,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,98 +250,19 @@ 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+)
@@ -371,7 +287,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 +309,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 +342,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 +465,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 +511,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 +595,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).
 
@@ -757,8 +659,6 @@ RESP = {conversationId: 1, payload: BinData(0, "dj02cnJpVFJCaTIzV3BSUi93dHVwK21N
 
 ### MONGODB-AWS
 
-- Since: 4.4
-
 MONGODB-AWS authenticates using AWS IAM credentials (an access key ID and a secret access key),
 [temporary AWS IAM credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) obtained from
 an [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html)
@@ -1903,19 +1803,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
 

source/bson-decimal128/decimal128.md

@@ -7,9 +7,9 @@ ______________________________________________________________________
 
 ## 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

source/causal-consistency/causal-consistency.md

@@ -196,9 +196,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 operations (for all commands that support a `readConcern`)
 3. Gossiping clusterTime (described in the Driver Session Specification)
@@ -283,7 +283,7 @@ that causally consistent reads are not causally consistent with unacknowledged w
 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()`
@@ -373,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
 

source/change-streams/change-streams.md

@@ -325,9 +325,6 @@ The responses to a change stream aggregate or getMore have the following structu
        ns: String,
        id: Int64,
        firstBatch: Array<ChangeStreamDocument>,
-       /**
-        * postBatchResumeToken is returned in MongoDB 4.0.7 and later.
-        */
        postBatchResumeToken: Document
     },
     operationTime: Timestamp,
@@ -343,9 +340,6 @@ The responses to a change stream aggregate or getMore have the following structu
        ns: String,
        id: Int64,
        nextBatch: Array<ChangeStreamDocument>
-       /**
-        * postBatchResumeToken is returned in MongoDB 4.0.7 and later.
-        */
        postBatchResumeToken: Document
     },
     operationTime: Timestamp,
@@ -784,11 +778,9 @@ thrown by opening, writing to, or reading from the socket.
 
 ##### Exposing All Resume Tokens
 
-- Since: 4.0.7
-
-Users can inspect the \_id on each `ChangeDocument` to use as a resume token. But since MongoDB 4.0.7, aggregate and
-getMore responses also include a `postBatchResumeToken`. Drivers use one or the other when automatically resuming, as
-described in [Resume Process](#resume-process).
+Users can inspect the \_id on each `ChangeDocument` to use as a resume token. Aggregate and getMore responses also
+include a `postBatchResumeToken`. Drivers use one or the other when automatically resuming, as described in
+[Resume Process](#resume-process).
 
 Drivers MUST expose a mechanism to retrieve the same resume token that would be used to automatically resume. It MUST be
 possible to use this mechanism after iterating every document. It MUST be possible for users to use this mechanism