DRIVERS-2789 Read Write Concern Spec to Markdown

formatting

Author: blink1073

source/causal-consistency/causal-consistency.md

@@ -237,8 +237,7 @@ For causal consistency the driver MUST send the `operationTime` saved in the `Cl
 ```
 
 For the lists of commands that support causally consistent reads, see
-[ReadConcern](https://github.com/mongodb/specifications/blob/master/source/read-write-concern/read-write-concern.rst#read-concern/)
-spec.
+[ReadConcern](../read-write-concern/read-write-concern.md#read-concern/) spec.
 
 The driver MUST merge the `ReadConcern` specified for the operation with the `operationTime` from the `ClientSession`
 (which goes in the `afterClusterTime` field) to generate the combined `readConcern` to send to the server. If the level

source/change-streams/change-streams.md

@@ -555,10 +555,10 @@ NOT throw a custom exception if multiple `$changeStream` stages are present (e.g
 in the pipeline supplied to the helper), as the server will return an error.
 
 The helper methods MUST determine a read concern for the operation in accordance with the
-[Read and Write Concern specification](https://github.com/mongodb/specifications/blob/master/source/read-write-concern/read-write-concern.rst#via-code).
-The initial implementation of change streams on the server requires a 'majority' read concern or no read concern.
-Drivers MUST document this requirement. Drivers SHALL NOT throw an exception if any other read concern is specified, but
-instead should depend on the server to return an error.
+[Read and Write Concern specification](../read-write-concern/read-write-concern.md#via-code). The initial implementation
+of change streams on the server requires a 'majority' read concern or no read concern. Drivers MUST document this
+requirement. Drivers SHALL NOT throw an exception if any other read concern is specified, but instead should depend on
+the server to return an error.
 
 The stage has the following shape:
 

source/crud/crud.md

@@ -1672,7 +1672,7 @@ Drivers MUST construct a `WriteConcernError` from a server reply as follows:
 - Set `message` to `writeConcernError.errmsg` if available.
 - Set `details` to `writeConcernError.errInfo` if available. Drivers MUST NOT parse inside `errInfo`.
 
-See [writeConcernError Examples](../read-write-concern/read-write-concern.rst#writeconcernerror-examples) in the
+See [writeConcernError Examples](../read-write-concern/read-write-concern.md#writeconcernerror-examples) in the
 Read/Write Concern spec for examples of how a server represents write concern errors in replies.
 
 ###### WriteError
@@ -2263,7 +2263,7 @@ Write concern is about indicating how writes are acknowledged. Since all operati
 in this specification are performed on a collection, it's uncommon that two different write operations on the same
 collection would use a different write concern, potentially causing mismatched and out-of-sync data. As such, the most
 natural place to indicate write concern is on the client, the database, or the collection itself and not the operations
-within it. See the [Read/Write Concern specification](../read-write-concern/read-write-concern.rst) for the API of
+within it. See the [Read/Write Concern specification](../read-write-concern/read-write-concern.md) for the API of
 constructing a read/write concern and associated API.
 
 However, it might be that a driver needs to expose write concern to a user per operation for various reasons. As noted

source/index.md

@@ -34,6 +34,7 @@
 - [ObjectID format](./objectid.md)
 - [Performance Benchmarking](benchmarking/benchmarking.md)
 - [Polling SRV Records for mongos Discovery](polling-srv-records-for-mongos-discovery/polling-srv-records-for-mongos-discovery.md)
+- [Read and Write Concern](read-write-concern/read-write-concern.md)
 - [Retryable Reads](retryable-reads/retryable-reads.md)
 - [Retryable Writes](retryable-writes/retryable-writes.md)
 - [SDAM Logging and Monitoring Specification](server-discovery-and-monitoring/server-discovery-and-monitoring-logging-and-monitoring.md)