DRIVERS-2789 Convert Sessions Spec to Markdown

source/client-side-encryption/client-side-encryption.md

@@ -2385,7 +2385,7 @@ libmongocrypt would create multiple OP_MSGs to send.
 
 Key management functions currently assume there are no concurrent accesses of the key vault collection being operated
 on. To support concurrent access of the key vault collection, the key management functions may be overloaded to take an
-explicit session parameter as described in the [Drivers Sessions Specification](../sessions/driver-sessions.rst).
+explicit session parameter as described in the [Drivers Sessions Specification](../sessions/driver-sessions.md).
 
 ## Changelog
 

source/client-side-operations-timeout/client-side-operations-timeout.md

@@ -363,8 +363,8 @@ See [Change stream behavior](#change-stream-behavior).
 
 ### Sessions
 
-The [SessionOptions](../sessions/driver-sessions.rst#mongoclient-changes) used to construct explicit
-[ClientSession](../sessions/driver-sessions.rst#clientsession) instances MUST accept a new `defaultTimeoutMS` option,
+The [SessionOptions](../sessions/driver-sessions.md#mongoclient-changes) used to construct explicit
+[ClientSession](../sessions/driver-sessions.md#clientsession) instances MUST accept a new `defaultTimeoutMS` option,
 which specifies the `timeoutMS` value for the following operations executed on the session:
 
 1. commitTransaction

source/index.md

@@ -13,6 +13,7 @@
 - [Connection String Spec](connection-string/connection-string-spec.md)
 - [Driver Authentication](auth/auth.md)
 - [Driver CRUD API](crud/crud.md)
+- [Driver Sessions Specification](sessions/driver-sessions.md)
 - [Driver Transactions Specification](transactions/transactions.md)
 - [FaaS Automated Testing](faas-automated-testing/faas-automated-testing.md)
 - [GridFS Spec](gridfs/gridfs-spec.md)
@@ -33,6 +34,7 @@
 - [Server Monitoring](server-discovery-and-monitoring/server-monitoring.md)
 - [Server Selection](server-selection/server-selection.md)
 - [Server Selection Test Plan](server-selection/server-selection-tests.md)
+- [Snapshot Reads Specification](sessions/snapshot-sessions.md)
 - [URI Options Specification](uri-options/uri-options.md)
 - [Unified Test Format](unified-test-format/unified-test-format.md)
 - [Wire Compression in Drivers](compression/OP_COMPRESSED.md)

source/retryable-reads/retryable-reads.md

@@ -520,8 +520,8 @@ No.
 [This is in contrast to the answer supplied in in the retryable writes specification.](../retryable-writes/retryable-writes.md#can-drivers-resend-the-same-wire-protocol-message-on-retry-attempts)
 However, when retryable writes were implemented, no driver actually chose to resend the same wire protocol message.
 Today, if a driver attempted to resend the same wire protocol message, this could violate
-[the rules for gossiping $clusterTime](../sessions/driver-sessions.rst#gossipping-the-cluster-time): specifically
-[the rule that a driver must send the highest seen $clusterTime](../sessions/driver-sessions.rst#sending-the-highest-seen-cluster-time).
+[the rules for gossiping $clusterTime](../sessions/driver-sessions.md#gossipping-the-cluster-time): specifically
+[the rule that a driver must send the highest seen $clusterTime](../sessions/driver-sessions.md#sending-the-highest-seen-cluster-time).
 
 Additionally, there would be a behavioral difference between a driver resending the same wire protocol message and one
 that does not. For example, a driver that creates a new wire protocol message could exhibit the following

source/retryable-writes/retryable-writes.md

@@ -32,20 +32,20 @@ The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SH
 The transaction ID identifies the transaction as part of which the command is running. In a write
 command where the client has requested retryable behavior, it is expressed by the top-level `lsid` and `txnNumber`
 fields. The `lsid` component is the corresponding server session ID. which is a BSON value defined in the
-[Driver Session](../sessions/driver-sessions.rst) specification. The `txnNumber` component is a monotonically increasing
+[Driver Session](../sessions/driver-sessions.md) specification. The `txnNumber` component is a monotonically increasing
 (per server session), positive 64-bit integer.
 
 **ClientSession**\
 Driver object representing a client session, which is defined in the
-[Driver Session](../sessions/driver-sessions.rst) specification. This object is always associated with a server session;
+[Driver Session](../sessions/driver-sessions.md) specification. This object is always associated with a server session;
 however, drivers will pool server sessions so that creating a ClientSession will not always entail creation of a new
 server session. The name of this object MAY vary across drivers.
 
 **Retryable Error**\
 An error is considered retryable if it has a RetryableWriteError label in its top-level
 "errorLabels" field. See [Determining Retryable Errors](#determining-retryable-errors) for more information.
 
-Additional terms may be defined in the [Driver Session](../sessions/driver-sessions.rst) specification.
+Additional terms may be defined in the [Driver Session](../sessions/driver-sessions.md) specification.
 
 ### Naming Deviations
 
@@ -265,8 +265,8 @@ enabled.
 When constructing a supported write command that will be executed within a MongoClient where retryable writes have been
 enabled, drivers MUST increment the transaction number for the corresponding server session and include the server
 session ID and transaction number in top-level `lsid` and `txnNumber` fields, respectively. `lsid` is a BSON value
-(discussed in the [Driver Session](../sessions/driver-sessions.rst) specification). `txnNumber` MUST be a positive
-64-bit integer (BSON type 0x12).
+(discussed in the [Driver Session](../sessions/driver-sessions.md) specification). `txnNumber` MUST be a positive 64-bit
+integer (BSON type 0x12).
 
 The following example illustrates a possible write command for an `updateOne()` operation:
 
@@ -454,7 +454,7 @@ section of the SDAM specification.
 
 When retrying a write command, drivers MUST resend the command with the same transaction ID. Drivers MUST NOT resend the
 original wire protocol message if doing so would violate rules for
-[gossipping the cluster time](../sessions/driver-sessions.rst#gossipping-the-cluster-time) (see:
+[gossipping the cluster time](../sessions/driver-sessions.md#gossipping-the-cluster-time) (see:
 [Can drivers resend the same wire protocol message on retry attempts?](#can-drivers-resend-the-same-wire-protocol-message-on-retry-attempts)).
 
 In the case of a multi-statement write operation split across multiple write commands, a failed retry attempt will also
@@ -513,7 +513,7 @@ driver API needs to be extended to support this behavior.
 
 ## Design Rationale
 
-The design of this specification piggy-backs that of the [Driver Session](../sessions/driver-sessions.rst) specification
+The design of this specification piggy-backs that of the [Driver Session](../sessions/driver-sessions.md) specification
 in that it modifies the driver API as little as possible to introduce the concept of at-most-once semantics and
 retryable behavior for write operations. A transaction ID will be included in all supported write commands executed
 within the scope of a MongoClient where retryable writes have been enabled.
@@ -635,7 +635,7 @@ Since retry attempts entail sending the same command and transaction ID to the s
 the same wire protocol message in order to avoid constructing a new message and computing its checksum. The server will
 not complain if it receives two messages with the same `requestId`, as the field is only used for logging and populating
 the `responseTo` field in its replies to the client. That said, re-using a wire protocol message might violate rules for
-[gossipping the cluster time](../sessions/driver-sessions.rst#gossipping-the-cluster-time) and might also have
+[gossipping the cluster time](../sessions/driver-sessions.md#gossipping-the-cluster-time) and might also have
 implications for [Command Monitoring](#command-monitoring), since the original write command and its retry attempt may
 report the same `requestId`.
 

source/retryable-writes/tests/README.md

@@ -71,7 +71,7 @@ Drivers should also assert that command documents are properly constructed with
 on whether the write operation is supported.
 [Command Logging and Monitoring](../../command-logging-and-monitoring/command-logging-and-monitoring.rst) may be used to
 check for the presence of a `txnNumber` field in the command document. Note that command documents may always include an
-`lsid` field per the [Driver Session](../../sessions/driver-sessions.rst) specification.
+`lsid` field per the [Driver Session](../../sessions/driver-sessions.md) specification.
 
 These tests may be run against both a replica set and shard cluster.
 

source/run-command/run-command.rst

@@ -76,7 +76,7 @@ The following represents how a runCommand API SHOULD be exposed.
  * An optional explicit client session.
  * The associated logical session id (`lsid`) the driver MUST apply to the command.
  *
- * @see https://github.com/mongodb/specifications/blob/master/source/sessions/driver-sessions.rst#clientsession
+ * @see ../sessions/driver-sessions.md#clientsession
  */
  session?: ClientSession;
 
@@ -129,11 +129,11 @@ Drivers MUST NOT attempt to check the command document for the presence of an ``
 Every ClientSession has a corresponding logical session ID representing the server-side session ID.
 The logical session ID MUST be included under ``lsid`` in the command sent to the server without modifying user input.
 
-* See Driver Sessions' section on `Sending the session ID to the server on all commands <https://github.com/mongodb/specifications/blob/master/source/sessions/driver-sessions.rst#sending-the-session-id-to-the-server-on-all-commands>`_
+* See Driver Sessions' section on `Sending the session ID to the server on all commands <../sessions/driver-sessions.md#sending-the-session-id-to-the-server-on-all-commands>`_
 
 The command sent to the server MUST gossip the ``$clusterTime`` if cluster time support is detected.
 
-* See Driver Sessions' section on `Gossipping the cluster time <https://github.com/mongodb/specifications/blob/master/source/sessions/driver-sessions.rst#gossipping-the-cluster-time>`_
+* See Driver Sessions' section on `Gossipping the cluster time <../sessions/driver-sessions.md#gossipping-the-cluster-time>`_
 
 Transactions
 """"""""""""
@@ -274,7 +274,7 @@ All ``getMore`` commands constructed for this cursor MUST send the same ``lsid``
 A cursor is considered exhausted or closed when the server reports its ``id`` as zero.
 When the cursor is exhausted the client session MUST be ended and the server session returned to the pool as early as possible rather than waiting for a caller to completely iterate the final batch.
 
-* See Drivers Sessions' section on `Sessions and Cursors <https://github.com/mongodb/specifications/blob/master/source/sessions/driver-sessions.rst#sessions-and-cursors>`_
+* See Drivers Sessions' section on `Sessions and Cursors <../sessions/driver-sessions.md#sessions-and-cursors>`_
 
 Server Selection
 """"""""""""""""
@@ -320,7 +320,7 @@ Drivers MUST provide an explicit mechanism for releasing the cursor resources, t
 If the cursor id is nonzero a KillCursors operation MUST be attempted, the result of the operation SHOULD be ignored.
 The ClientSession associated with the cursor MUST be ended and the ServerSession returned to the pool.
 
-* See Driver Sessions' section on `When sending a killCursors command <https://github.com/mongodb/specifications/blob/master/source/sessions/driver-sessions.rst#when-sending-a-killcursors-command>`_
+* See Driver Sessions' section on `When sending a killCursors command <../sessions/driver-sessions.md#when-sending-a-killcursors-command>`_
 * See Find, getMore and killCursors commands' section on `killCursors <https://github.com/mongodb/specifications/blob/master/source/find_getmore_killcursors_commands.rst#killcursors>`_
 
 Client Side Operations Timeout