DRIVERS-1673 Minor typo fixes (#1338)

Co-authored-by: Kaitlin Mahar <kaitlinmahar@gmail.com>

Co-authored-by: Kaitlin Mahar <kaitlinmahar@gmail.com>

Co-authored-by: Kaitlin Mahar <kaitlinmahar@gmail.com>

Co-authored-by: Kaitlin Mahar <kaitlinmahar@gmail.com>

Co-authored-by: Kaitlin Mahar <kaitlinmahar@gmail.com>

Co-authored-by: Kaitlin Mahar <kaitlinmahar@gmail.com>

Co-authored-by: Kaitlin Mahar <kaitlinmahar@gmail.com>

Co-authored-by: Kaitlin Mahar <kaitlinmahar@gmail.com>

Author: prestonvasquez

source/client-side-encryption/tests/README.rst

@@ -610,15 +610,15 @@ Using ``client_encrypted`` perform the following operations:
 
    - ``{ "_id": "over_2mib_2", "unencrypted": <the string "a" repeated (2097152) times> }``
 
-   Expect the bulk write to succeed and split after first doc (i.e. two inserts occur). This may be verified using `command monitoring <https://github.com/mongodb/specifications/tree/master/source/command-monitoring/command-monitoring.rst>`_.
+   Expect the bulk write to succeed and split after first doc (i.e. two inserts occur). This may be verified using `command monitoring <https://github.com/mongodb/specifications/tree/master/source/command-logging-and-monitoring/command-logging-and-monitoring.rst>`_.
 
 #. Bulk insert the following:
 
    - The document `limits/limits-doc.json <../limits/limits-doc.json>`_ concatenated with ``{ "_id": "encryption_exceeds_2mib_1", "unencrypted": < the string "a" repeated (2097152 - 2000) times > }``
 
    - The document `limits/limits-doc.json <../limits/limits-doc.json>`_ concatenated with ``{ "_id": "encryption_exceeds_2mib_2", "unencrypted": < the string "a" repeated (2097152 - 2000) times > }``
 
-   Expect the bulk write to succeed and split after first doc (i.e. two inserts occur). This may be verified using `command monitoring <https://github.com/mongodb/specifications/tree/master/source/command-monitoring/command-monitoring.rst>`_.
+   Expect the bulk write to succeed and split after first doc (i.e. two inserts occur). This may be verified using `command logging and monitoring <https://github.com/mongodb/specifications/tree/master/source/command-logging-and-monitoring/command-logging-and-monitoring.rst>`_.
 
 #. Insert ``{ "_id": "under_16mib", "unencrypted": <the string "a" repeated 16777216 - 2000 times>``.
 

source/crud/tests/README.rst

@@ -269,7 +269,7 @@ like so:
      }
    }
 
-Enable `command monitoring <../../command-monitoring/command-monitoring.rst>`_
+Enable `command monitoring <../../command-logging-and-monitoring/command-logging-and-monitoring.rst>`_
 to observe CommandSucceededEvents. Then, insert an invalid document (e.g.
 ``{x: 1}``) and assert that a WriteError occurs, that its code is ``121``
 (i.e. DocumentValidationFailure), and that its ``details`` property is

source/logging/logging.rst

@@ -12,7 +12,7 @@ Logging
 
 Abstract
 ========
-This specification defines requirements for drivers' logging configuration and behavior. 
+This specification defines requirements for drivers' logging configuration and behavior.
 
 
 META
@@ -51,7 +51,7 @@ not require any changes to an application's source code, and in the case of comp
 does not require recompilation.
 However, if that is impossible to do without conflicting with idiomatic logging patterns for the
 language ecosystem, it is acceptable for a driver to require minimal changes to enable logging,
-such as recompiling with a feature flag specified, or passing a logging configuration to a 
+such as recompiling with a feature flag specified, or passing a logging configuration to a
 ``MongoClient`` constructor. In that case, drivers SHOULD strive to minimize the amount of code
 change needed.
 
@@ -75,8 +75,8 @@ Per-Component Configuration of Log Levels
 -----------------------------------------
 Drivers MUST support enabling logging and specifying the minimum severity level for emitted messages
 on a per-component level, for each component defined below in the `Components`_ section.
-  
-  **Fallback implementation method**: Support configuration via environment variables 
+
+  **Fallback implementation method**: Support configuration via environment variables
   corresponding to each component, as defined in `Components`_, as well as via the
   environment variable ``MONGODB_LOG_ALL``.
 
@@ -89,7 +89,7 @@ on a per-component level, for each component defined below in the `Components`_
   If ``MONGODB_LOG_ALL`` is specified in addition to one or more component variables, the
   component variable(s) MUST take precedence.
 
-  The default is to not log anything. 
+  The default is to not log anything.
 
   If a variable is set to an invalid value, it MUST be treated as if it were not specified at all.
 
@@ -118,11 +118,11 @@ producing invalid Unicode data.
 Drivers MUST implement truncation naively by simply truncating the output at the required length; i.e.
 do not attempt to implement truncation such that the output is still valid JSON.
 Truncated extended JSON MUST have a trailing ellipsis ``...`` appended to indicate to the user that
-truncation occurred. The ellipsis MUST NOT count toward the the max length.
+truncation occurred. The ellipsis MUST NOT count toward the max length.
 
     **Fallback Implementation method**: Environment variable ``MONGOB_LOG_MAX_DOCUMENT_LENGTH``.
     When unspecified, any extended JSON representation of a document which is longer than the
-    default max length MUST be truncated to that length. 
+    default max length MUST be truncated to that length.
     When set to an integer value, any extended JSON document longer than that value MUST be
     truncated to that length.
     If the variable is set to an invalid value, it MUST be treated as if it were not specified at
@@ -149,7 +149,7 @@ driver-specific messages they produce.
      - Environment Variable
 
    * - command
-     - `Command Monitoring <../command-monitoring/command-monitoring.rst>`__
+     - `Command Logging and Monitoring <../command-logging-and-monitoring/command-logging-and-monitoring.rst>`__
      - ``MONGODB_LOG_COMMAND``
 
    * - topology
@@ -263,7 +263,7 @@ SHOULD utilize it to support both types of logging.
 
 Note that drivers implementing unstructured logging MUST still support some internal way to intercept
 the data contained in messages in a structured form, as this is required to implement the unified tests
-for logging conformance.. See the `unified test format specification 
+for logging conformance. See the `unified test format specification
 <../unified-test-format/unified-test-format.rst#expectedLogMessage>`_ for details.
 
 Representing Documents in Log Messages
@@ -277,7 +277,7 @@ Drivers MAY represent errors in log messages in whatever format is idiomatic for
 existing error types. For example, if a driver's error classes have existing ``toString()``
 implementations, those MAY be used. Alternatively, if a driver emits structured log messages, a
 structured format containing error data could be used. Any information which a driver reports via
-its error classes MUST be included in the log representations. 
+its error classes MUST be included in the log representations.
 Note that if the driver includes full server responses in its errors these MUST be truncated in
 accordance with the max document length option.
 
@@ -286,7 +286,7 @@ Omitting Null Values from Log Messages
 Some log messages will include fields that are only present under particular circumstances, for example
 on certain server versions. When such a field is not present:
 
-- If the driver does structured logging, the field MUST be omitted from the message altogether, i.e. the field 
+- If the driver does structured logging, the field MUST be omitted from the message altogether, i.e. the field
   MUST not be present with an explicit null value.
 - If the driver does unstructured logging, the corresponding segment of the message string MUST be omitted
   altogether.
@@ -296,8 +296,8 @@ Performance Considerations
 The computation required to generate certain log messages can be significant, e.g. if extended
 JSON serialization is required. If possible, drivers SHOULD check whether a log message would
 actually be emitted and consumed based on the users' configuration before doing such computation.
-For example, this can be checked in Rust via `log::log_enabled 
-<https://docs.rs/log/latest/log/macro.log_enabled.html>`_. 
+For example, this can be checked in Rust via `log::log_enabled
+<https://docs.rs/log/latest/log/macro.log_enabled.html>`_.
 
 Drivers SHOULD optimize extended JSON generation to avoid generating JSON strings longer than will
 be emitted, such that the complexity is O(N) where N = ``<max document length>``, rather than
@@ -344,7 +344,7 @@ Design Rationale
 Truncation of large documents
 -----------------------------
 
-1. Why have an option? 
+1. Why have an option?
     We considered a number of approaches for dealing with documents of potentially very large size
     in log messages, e.g. command documents, including 1) always logging the full document, 2) only
     logging documents with the potential to be large when the user opts in, and 3) truncating large
@@ -354,10 +354,10 @@ Truncation of large documents
     will show the user the full data. In the case where data is large, the user will receive a
     readable message with truncated data, but have the option to see more or all of the data.
 
-2. Why are the units for max document length flexible? 
+2. Why are the units for max document length flexible?
     String APIs vary across languages, and not all drivers will be able to easily and efficiently
     truncate strings in the same exact manner. The important thing is that the option exists and
-    that its default value is reasonable, and for all possible unit choices (byte, code point, 
+    that its default value is reasonable, and for all possible unit choices (byte, code point,
     code unit, or grapheme) we felt 1000 was a reasonable default. See
     `here <https://exploringjs.com/impatient-js/ch_unicode.html>`_ for a helpful primer on related
     Unicode concepts.

source/retryable-reads/retryable-reads.rst

@@ -446,15 +446,16 @@ Command Monitoring
 
 `As with retryable writes
 <https://github.com/mongodb/specifications/blob/master/source/retryable-writes/retryable-writes.rst#command-monitoring>`__,
-in accordance with the `Command Monitoring
-<https://github.com/mongodb/specifications/blob/master/source/command-monitoring/command-monitoring.rst>`__
+in accordance with the `Command Logging and Monitoring
+<https://github.com/mongodb/specifications/blob/master/source/command-logging-and-monitoring/command-logging-and-monitoring.rst>`__
 specification, drivers MUST guarantee that each ``CommandStartedEvent`` has
-either a correlating ``CommandSucceededEvent`` or ``CommandFailedEvent``. If the
-first attempt of a retryable read operation encounters a retryable error,
-drivers MUST fire a ``CommandFailedEvent`` for the retryable error and fire a
-separate ``CommandStartedEvent`` when executing the subsequent retry
-attempt. Note that the second ``CommandStartedEvent`` may have a different
-``connectionId``, since a server is reselected for a retry attempt.
+either a correlating ``CommandSucceededEvent`` or ``CommandFailedEvent`` and that
+every "command started" log message has either a correlating "command succeeded"
+log message or "command failed" log message. If the first attempt of a retryable
+read operation encounters a retryable error, drivers MUST fire a ``CommandFailedEvent`` and emit a "command failed" log message
+for the retryable error and fire a separate ``CommandStartedEvent``and emit a separate "command started" log message when executing
+the subsequent retry attempt. Note that the second ``CommandStartedEvent`` and "command started" log message may have
+a different ``connectionId``, since a server is reselected for a retry attempt.
 
 Documentation
 -------------
@@ -678,6 +679,7 @@ degraded performance can simply disable ``retryableReads``.
 Changelog
 =========
 
+:2022-11-09: CLAM must apply both events and log messages.
 :2022-10-18: When CSOT is enabled multiple retry attempts may occur.
 :2022-10-05: Remove spec front matter, move footnote, and reformat changelog.
 :2022-01-25: Note that drivers should retry handshake network failures.

source/retryable-writes/retryable-writes.rst

@@ -533,22 +533,23 @@ specification does not define a format for such log messages.
 Command Monitoring
 ==================
 
-In accordance with the `Command Monitoring`_ specification, drivers MUST
+In accordance with the `Command Logging and Monitoring`_ specification, drivers MUST
 guarantee that each ``CommandStartedEvent`` has either a correlating
-``CommandSucceededEvent`` or ``CommandFailedEvent``. If the first attempt of a
-retryable write operation encounters a retryable error, drivers MUST fire a
-``CommandFailedEvent`` for the retryable error and fire a separate
-``CommandStartedEvent`` when executing the subsequent retry attempt. Note that
-the second ``CommandStartedEvent`` may have a different ``connectionId``, since
+``CommandSucceededEvent`` or ``CommandFailedEvent`` and that every "command started"
+log message has either a correlating "command succeeded" log message or "command failed"
+log message. If the first attempt of a retryable write operation encounters a retryable
+error, drivers MUST fire a ``CommandFailedEvent`` and emit a "command failed" log message for the retryable error and fire a
+separate ``CommandStartedEvent`` and "command succeeded" log message when executing the subsequent retry attempt. Note that
+the second ``CommandStartedEvent`` and "command succeeded" log message may have a different ``connectionId``, since
 a writable server is reselected for the retry attempt.
 
-.. _Command Monitoring: ../command-monitoring/command-monitoring.rst
+.. _Command Logging and Monitoring: ../command-logging-and-monitoring/command-logging-and-monitoring.rst
 
 Each attempt of a retryable write operation SHOULD report a different
 ``requestId`` so that events for each attempt can be properly correlated with
 one another.
 
-The `Command Monitoring`_ specification states that the ``operationId`` field is
+The `Command Logging and Monitoring`_ specification states that the ``operationId`` field is
 a driver-generated, 64-bit integer and may be "used to link events together such
 as bulk write operations." Each attempt of a retryable write operation SHOULD
 report the same ``operationId``; however, drivers SHOULD NOT use the
@@ -809,6 +810,7 @@ inconsistent with the server and potentially confusing to developers.
 Changelog
 =========
 
+:2022-11-09: CLAM must apply both events and log messages.
 :2022-10-18: When CSOT is enabled multiple retry attempts may occur.
 :2022-10-05: Remove spec front matter and reformat changelog.
 :2022-01-25: Note that drivers should retry handshake network failures.

source/retryable-writes/tests/README.rst

@@ -291,11 +291,11 @@ Command Construction Tests
 
 Drivers should also assert that command documents are properly constructed with
 or without a transaction ID, depending on whether the write operation is
-supported. `Command Monitoring`_ may be used to check for the presence of a
+supported. `Command Logging and Monitoring`_ 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`_ specification.
 
-.. _Command Monitoring: ../../command-monitoring/command-monitoring.rst
+.. _Command Logging and Monitoring: ../../command-logging-and-monitoring/command-logging-and-monitoring.rst
 .. _Driver Session: ../../sessions/driver-sessions.rst
 
 These tests may be run against both a replica set and shard cluster.