Fix spelling mistakes and use IPNS terminology

IPIP/0337-delegated-routing-http-api.md

@@ -70,7 +70,7 @@ So this API proposal makes the following changes:
   - Multiaddrs use the [human-readable format](https://github.com/multiformats/multiaddr#specification) that is used in existing tools and Kubo CLI commands such as `ipfs id` or `ipfs swarm peers`
   - Byte array values, such as signatures, are multibase-encoded strings (with an `m` prefix indicating Base64)
 - The "Identify" method and "message groups" are not included
-- The "GetIPNS" and "PutIPNS" methods are not included. Instead, a separate Delegated Naming HTTP API aims to firstly facilitate naming system delegation, and secondly, pave the way for future iterations of IPNS with less interdependency with content routing. For more information, see [Delegated Naming HTTP API](0379-delegated-naming-http-api.md).
+- The "GetIPNS" and "PutIPNS" methods are not included. Instead, a separate Delegated IPNS HTTP API aims to firstly facilitate naming system delegation, and secondly, pave the way for future iterations of IPNS with less interdependency with content routing. For more information, see [Delegated IPNS HTTP API](0379-delegated-ipns-http-api.md).
 
 ### User benefit
 

IPIP/0379-delegated-naming-http-api.md → IPIP/0379-delegated-ipns-http-api.md

@@ -1,4 +1,4 @@
-# IPIP-379: Delegated Naming HTTP API
+# IPIP-379: Delegated IPNS HTTP API
 
 - Start Date: 2023-02-13
 - Related Issues:
@@ -8,7 +8,7 @@
 
 ## Summary
 
-This IPIP specifies a set of HTTP APIs to offload naming system onto aother process or server.
+This IPIP specifies a set of HTTP APIs to offload naming system onto another process or server.
 
 ## Motivation
 
@@ -21,13 +21,13 @@ See [Delegated Naming HTTP API](../routing/DELEGATED_NAMING_HTTP.md) specificati
 
 ## Design rationale
 
-The rationale for delegated naming over HTTP APIs closely follows the reasoning listed in [IPIP-337](0337-delegated-routing-http-api.md#design-rationale).
+The rationale for delegated IPNS over HTTP APIs closely follows the reasoning listed in [IPIP-337](0337-delegated-routing-http-api.md#design-rationale).
 
 The document proposes the following:
 - Use of HTTP semantics for publication and resolution of naming records.
 - Preference for human-readable request and response encoding, such as JSON format
-- Optional backward compatibility support for the existing ProtocolBuffer format using `Content-Type: application/x-protobuf; messageType="IpnsEntry"`
-- Use of extra headers in `OPTIONS` response to communicate the supported cpabilities and limitations, namely:
+- Optional backward compatibility support for the existing ProtocolBuffer format using `Content-Type: application/vnd.ipfs.ipns-record`
+- Use of extra headers in `OPTIONS` response to communicate the supported capabilities and limitations, namely:
   - `X-Ipns-Allow-Max-Size` -- to signal maximum supported IPNS record size
   - `X-Ipns-Allow-Protobuf` -- to signal whether the server supports ProtocolBuffer formatted records.
 - Streaming interaction is not supported.
@@ -48,8 +48,7 @@ One of the motivations of this document is to introduce simple to use HTTP APIs
 Further, interoperability across the existing and HTTP APIs is also desirable in order to reduce the barrier for adoption of the delegated HTTP APIs.
 
 The specification here maintains backwards compatibility in terms of record serialisation, with preference for human-readable formats such as JSON.
-To maintain backwards compatibility, the implementers of the HTTP API should accept requests with following `Content-Type` header:
-- `application/x-protobuf; messageType="IpnsEntry"`
+To maximize interoperability with existing ecosystem, the canonical [IPNS record serialization format](../ipns/IPNS.md#record-serialization-format) (`0x0300`) can be requested with content type `application/vnd.ipfs.ipns-record`.
 
 ##### Reframe