ipip-378: clarify string values

#378 (comment)

Author: lidel

src/routing/http-routing-v1.md

@@ -119,7 +119,7 @@ server SHOULD be no more than 100 `Providers` per `application/json` response.
 
 :::
 
-#### `POST` Response codes
+#### `POST` Response Status Codes
 
 - `200` (OK): the server processed the full list of provider records (possibly unsuccessfully, depending on the semantics of the particular records)
 - `400` (Bad Request): the server deems the request to be invalid and cannot process it
@@ -198,7 +198,7 @@ Each object in the `Peers` list is a *write peer record* entry.
 
 Server SHOULD accept writes represented with [Announcement Schema](#announcement-schema).
 
-#### `POST` Response codes
+#### `POST` Response Status Codes
 
 - `200` (OK): the server processed the full list of provider records (possibly unsuccessfully, depending on the semantics of the particular records)
 - `400` (Bad Request): the server deems the request to be invalid and cannot process it
@@ -392,10 +392,12 @@ The `announcement` schema can be used in `POST` operations to announce content p
   }
 ```
 
+
 - `Schema`: tells the server to interpret the JSON object as announce provider
-- `Payload`: is a DAG-JSON-compatible object with a subset of the below fields
+- `Payload`: is a map object with a subset of the below fields.
+  - All keys and values in `Payload` map are strings to remove ambiguity of how `Signature` is calculated.
   - `CID` is the CID being provided (`/routing/v1/providers` only).
-    - This field is not presend when used for `POST /routing/v1/peers`
+    - This field is not present when used for `POST /routing/v1/peers`
   - `Scope` is an optional hint that provides semantic meaning about CID (`/routing/v1/providers` only):
     - `block` announces only the individual block (this is the implicit default if `Scope` field is not present).
     - `entity` announces CIDs required for enumerating entity behind the CID (e.g.: all blocks for UnixFS file or a minimum set of blocks to enumerate contents of HAMT-sharded UnixFS directory, only top level of directory tree, etc).
@@ -418,9 +420,10 @@ The `announcement` schema can be used in `POST` operations to announce content p
     - ED25519 and other small public keys MUST be inlined inside of the `ID` field with the identity multihash type.
     - Key types that exceed 42 bytes (e.g. RSA) SHOULD NOT be inlined, the `ID` field should only include the multihash of the key. The key itself SHOULD be obtained out-of-band (e.g. by fetching the block via IPFS) and cached.
       If support for big keys is needed in the future, this spec can be updated to allow the client to provide the key and key type out-of-band by adding optional `PublicKey` fields, and if the Peer ID is a CID, then the server can verify the public key's authenticity against the CID, and then proceed with the rest of the verification scheme.
-  - A [400 Bad Request](https://httpwg.org/specs/rfc9110.html#status.400)  response code SHOULD be returned if the `Signature` check fails.
 
-Server SHOULD return HTTP 400 Bad Request when announcement `Payload` serizalized to DAG-CBOR is bigger than 2MiB.
+ A [400 Bad Request](https://httpwg.org/specs/rfc9110.html#status.400)  response code SHOULD be returned if either
+ - `Signature` is not valid
+ - `Payload` serialized to DAG-CBOR is bigger than 2MiB
 
 #### Use in POST responses