fix: empty section, misspelling, RFC7049 is now RFC8949 (#1550)

These are minor editorial cleanups

fixes #1549

index.bs

@@ -363,7 +363,7 @@ as described below.
 refer to [[WebAuthnAPIGuide]] for an overall tutorial.
 Beyond that, the intended audiences for this document are the following main groups:
 
-- [=[RP]=] web application developers, expecially those responsible for [=[RP]=] [=web application=] login flows, account recovery flows,
+- [=[RP]=] web application developers, especially those responsible for [=[RP]=] [=web application=] login flows, account recovery flows,
     user account database content, etc.
 - Web framework developers
 
@@ -381,7 +381,11 @@ Beyond that, the intended audiences for this document are the following main gro
     [=authenticator=] APIs, platform [=WebAuthn Client=] instantiation, etc.
 
     - The above two audiences should read [[#sctn-api]] very carefully, along with [[#sctn-extensions]] if they intend to support extensions.
-        They should also carefully read [[#sctn-security-considerations-client]] and [[#sctn-privacy-considerations-client]].
+        They should also carefully read
+        <!-- no sec cons for clients enumerated at this time
+        [[#sctn-security-considerations-client]] and
+        -->
+        [[#sctn-privacy-considerations-client]].
 
 - [=Authenticator=] developers. These readers will want to pay particular attention to [[#sctn-authenticator-model]],
     [[#sctn-defined-attestation-formats]], [[#sctn-extensions]], and [[#sctn-defined-extensions]].
@@ -869,7 +873,7 @@ below and in [[#index-defined-elsewhere]].
 
 : CBOR
 :: A number of structures in this specification, including attestation statements and extensions, are encoded using the
-    [=CTAP2 canonical CBOR encoding form=] of the Compact Binary Object Representation (<dfn>CBOR</dfn>) [[!RFC7049]],
+    [=CTAP2 canonical CBOR encoding form=] of the Compact Binary Object Representation (<dfn>CBOR</dfn>) [[!RFC8949]],
     as defined in [[!FIDO-CTAP]].
 
 : CDDL
@@ -3432,7 +3436,7 @@ laid out as shown in <a href="#table-authData">Table <span class="table-ref-foll
             <td><dfn lt="authDataExtensions">extensions</dfn></td>
             <td>variable (if present)</td>
             <td>
-                Extension-defined [=authenticator data=]. This is a [=CBOR=] [[!RFC7049]] map with [=extension identifiers=] as keys,
+                Extension-defined [=authenticator data=]. This is a [=CBOR=] [[!RFC8949]] map with [=extension identifiers=] as keys,
                 and [=authenticator extension outputs=] as values. See [[#sctn-extensions]] for details.
             </td>
         </tr>
@@ -5294,7 +5298,7 @@ are converted to [=CBOR=] values in the [=authenticator extension inputs=].
 When the JavaScript value is an [=%ArrayBuffer%=], it is converted to a [=CBOR=] byte array.
 When the JavaScript value is a non-integer number, it is converted to a 64-bit CBOR floating point number.
 Otherwise, when the JavaScript type corresponds to a JSON type, the conversion is done
-using the rules defined in Section 4.2 of [[!RFC7049]] (Converting from JSON to CBOR),
+using the rules defined in Section 6.2 of [[!RFC8949]] (Converting from JSON to CBOR),
 but operating on inputs of JavaScript type values rather than inputs of JSON type values.
 Once these conversions are done,
 canonicalization of the resulting [=CBOR=] MUST be performed using the [=CTAP2 canonical CBOR encoding form=].
@@ -5312,7 +5316,7 @@ are converted to JavaScript values in the [=client extension outputs=].
 When the CBOR value is a byte string, it is converted to a JavaScript [=%ArrayBuffer%=]
 (rather than a base64url-encoded string).
 Otherwise, when the CBOR type corresponds to a JSON type, the conversion is done
-using the rules defined in Section 4.1 of [[!RFC7049]] (Converting from CBOR to JSON),
+using the rules defined in Section 6.1 of [[!RFC8949]] (Converting from CBOR to JSON),
 but producing outputs of JavaScript type values rather than outputs of JSON type values.
 
 Note that some clients may choose to implement this pass-through capability under a feature flag.
@@ -6619,9 +6623,9 @@ possible for [=[RPS]=] to trust any further [=attestation statements=] from the
 
 See also the related security consideration for [=[RPS]=] in [[#sctn-revoked-attestation-certificates]].
 
-
+<!-- no sec cons for clients enumerated at this time
 ## Security considerations for [=clients=] ## {#sctn-security-considerations-client}
-
+-->
 
 ## Security considerations for [=[RPS]=] ## {#sctn-security-considerations-rp}