DRIVERS-3439 simplify spec prose for 4.2+ minimum

Author: jyemin

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 and write operations (for all commands that support a `readConcern`)
 3. Gossiping clusterTime (described in the Driver Session Specification)
@@ -284,7 +284,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 +374,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

source/collation/collation.md

@@ -7,12 +7,10 @@ ______________________________________________________________________
 
 ## Abstract
 
-As of MongoDB server version 3.4 (maxWireVersion 5), a collation option is supported by the query system for matching
-and sorting on language strings in a locale-aware fashion.
+A collation option is supported by the query system for matching and sorting on language strings in a locale-aware
+fashion.
 
-A driver MUST support a Collation option for each of the relevant operations in server versions >= 3.4 (maxWireVersion
-5\) and MUST throw an error if a user supplies a Collation option for the operation and the selected server has
-maxWireVersion < 5 or if the user is using opcode-based unacknowledged writes.
+A driver MUST support a Collation option for each of the relevant operations.
 
 The CRUD and Index Management specs include the collation option in descriptions of API elements where it is supported.
 This document provides more details on the specific driver behavior required to handle the collation option.
@@ -38,13 +36,6 @@ eventually the majority of users wishing to use Collations on all operations on
 with a server-side default. We chose to favor user verbosity right now over abstracting the feature for short-term
 gains.
 
-### Drivers throw an error if a user supplies Collation and the selected server does not support the feature
-
-Server versions earlier than 3.4 don't always throw an error if an unknown option is supplied to certain operations.
-Because a Collation defines how documents are matched and sorted for both read and write operations, behavior
-differences between server versions are significant. Drivers therefore MUST throw an error if a user specifies a
-Collation and the selected server has a maxWireVersion < 5 or if using opcode-based unacknowledged writes.
-
 ## Specification
 
 ### Collation Document Model
@@ -137,11 +128,6 @@ The collation option is sent to the server in the form of a BSON Document. See t
 Driver helpers manipulating or using indexes MUST support a collation option. These include creating, deleting, and
 hinting an index. See the [Index Management specification](../index-management/index-management.md) for details.
 
-### Require maxWireVersion 5
-
-Drivers MUST require the server's maxWireVersion >= 5 to support Collations. When a collation is explicitly specified
-for a server with maxWireVersion < 5, the driver MUST raise an error.
-
 ### Opcode-based Unacknowledged Writes
 
 The driver MUST NOT allow collation with opcodes, because the server doesn't support it. If a driver uses opcode-based
@@ -158,30 +144,6 @@ db.command({
 });
 ```
 
-### BulkWrite API
-
-If maxWireVersion < 5, the driver MUST inspect each BulkWrite operation model for a collation and MUST raise an error
-and MUST NOT send any operations to the server if a collation is explicitly specified on an operation. For example, the
-user will provide BulkWrite operation models as in the following example:
-
-```typescript
-db.collection.bulkWrite([
-  {insertOne: { ... }},
-
-  {updateOne: { filter: { name: "PING" },
-                        update: { $set: { name: "pong" }},
-                        collation: { locale: "en_US", strength: 2 }}},
-  {updateMany: {..., collation: {...}}},
-  {replaceOne: {..., collation: {...}}},
-  {deleteOne: {..., collation: {...}}},
-  {deleteMany: {..., collation: {...}}}
-]);
-```
-
-The driver MUST inspect all operations before sending any to the server. If any operation specifies a Collation, the
-driver MUST raise an error and MUST NOT send any operations to the server. In the example above, even the insertOne
-(which has no Collation) MUST NOT be sent.
-
 ## Test Plan
 
 There is no specific test plan for driver Collation support; however drivers should test each affected CRUD, Index
@@ -191,9 +153,6 @@ In addition, drivers should test that two indexes can be created with identical
 custom name must be provided for one of them. Then, the test should ensure that the correct index is dropped when
 delete_one is called with an index name.
 
-Drivers should also test that errors are raised in each place Collation can be provided to a API method and the selected
-server has maxWireVersion < 5.
-
 ## Backwards Compatibility
 
 There should be no backwards compatibility concerns.