docs: merge ipns routing with routing v1 spec

src/ipips/ipip-0379.md

@@ -30,7 +30,7 @@ The performance of naming system over the IPFS DHT can suffer from long delays d
 
 ## HTTP API Specification
 
-See :cite[http-ipns-routing] specification.
+See :cite[http-routing-v1] specification.
 
 ## Design rationale
 

src/routing/http-routing-v1.md

@@ -1,33 +1,37 @@
 ---
 title: Routing V1 HTTP API
 description: >
-  Delegated content routing is a mechanism for IPFS implementations to use for
-  offloading content routing to another process. This specification describes
+  Delegated routing is a mechanism for IPFS implementations to use for offloading
+  content routing and naming to another process/server. This specification describes
   an HTTP API for delegated content routing.
 date: 2023-03-22
 maturity: reliable
 editors:
   - name: Gus Eggert
-    github: guseggert 
+    github: guseggert
+  - name: Masih H. Derkani
+    github: masih
+xref:
+  - ipns-record
 order: 0
 tags: ['routing']
 ---
 
-"Delegated content routing" is a mechanism for IPFS implementations to use for offloading content routing to another process/server. This spec describes an HTTP API for delegated content routing.
+Delegated routing is a mechanism for IPFS implementations to use for offloading content routing and naming to another process/server. This specification describes an HTTP API for delegated content routing.
 
 ## API Specification
 
-The Delegated Content Routing Routing HTTP API uses the `application/json` content type by default.
+The Routing HTTP API uses the `application/json` content type by default. For :ref[IPNS Names], the verifiable [`application/vnd.ipfs.ipns-record`](https://www.iana.org/assignments/media-types/application/vnd.ipfs.ipns-record content type is used.
 
-As such, human-readable encodings of types are preferred. This spec may be updated in the future with a compact `application/cbor` encoding, in which case compact encodings of the various types would be used.
+As such, human-readable encodings of types are preferred. This specification may be updated in the future with a compact `application/cbor` encoding, in which case compact encodings of the various types would be used.
 
 ## Common Data Types
 
 - CIDs are always string-encoded using a [multibase](https://github.com/multiformats/multibase)-encoded [CIDv1](https://github.com/multiformats/cid#cidv1).
 - Multiaddrs are string-encoded according to the [human-readable multiaddr specification](https://github.com/multiformats/multiaddr#specification)
 - Peer IDs are string-encoded according [PeerID string representation specification](https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#string-representation)
 - Multibase bytes are string-encoded according to [the Multibase spec](https://github.com/multiformats/multibase), and *should* use base64.
-- Timestamps are Unix millisecond epoch timestamps
+- Timestamps are Unix millisecond epoch timestamps.
 
 Until required for business logic, servers should treat these types as opaque strings, and should preserve unknown JSON fields.
 
@@ -63,11 +67,19 @@ Where:
 
 Specifications for some transfer protocols are provided in the "Transfer Protocols" section.
 
+### IPNS Records
+
+:ref[IPNS Records] are serialized using the verifiable [`application/vnd.ipfs.ipns-record`](https://www.iana.org/assignments/media-types/application/vnd.ipfs.ipns-record) format. For more details, read the specification :cite[ipns-record].
+
 ## API
 
-### `GET /routing/v1/providers/{CID}`
+### `GET /routing/v1/providers/{cid}`
+
+#### Path Parameters
 
-#### Response codes
+- `cid` is the [CID](https://github.com/multiformats/cid) to fetch provider records for.
+
+#### Response Status Codes
 
 - `200` (OK): the response body contains 0 or more records
 - `404` (Not Found): must be returned if no matching records are found
@@ -77,20 +89,64 @@ Specifications for some transfer protocols are provided in the "Transfer Protoco
 
 ```json
 {
-    "Providers": [
-        {
-            "Protocol": "<protocol_name>",
-            "Schema": "<schema>",
-            ...
-        }
-    ]
+  "Providers": [
+    {
+      "Protocol": "<protocol_name>",
+      "Schema": "<schema>",
+      ...
+    }
+  ]
 }
 ```
 
 Response limit: 100 providers
 
 Each object in the `Providers` list is a *read provider record*.
 
+### `GET /routing/v1/ipns/{name}`
+
+#### Path Parameters
+
+- `name` is the :ref[IPNS Name] to resolve.
+
+#### Response Status Codes
+
+- `200` (OK): indicates that the response body containing the IPNS record that corresponds to the
+  IPNS name.
+- `404` (Not Found): indicates that no matching records are found.
+- `400` (Bad Request): indicates that the given IPNS name is not valid.
+- `429` (Too Many Requests): indicates that the caller is issuing requests too many request and may
+  retry after the time specified
+  at [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) response
+  header has elapsed.
+- `501` (Not Implemented): indicates that the server does not support resolution of IPNS records
+
+#### Response Body
+
+The response body contains a [`application/vnd.ipfs.ipns-record`](https://www.iana.org/assignments/media-types/application/vnd.ipfs.ipns-record) serialized :ref[IPNS Record].
+
+### `PUT /routing/v1/ipns/{name}`
+
+#### Path Parameters
+
+- `name` is the :ref[IPNS Name] to publish.
+
+#### Request Body
+
+The content body must be a [`application/vnd.ipfs.ipns-record`](https://www.iana.org/assignments/media-types/application/vnd.ipfs.ipns-record) serialized :ref[IPNS Record], which matches the `name` path parameter.
+
+#### Response Status Codes
+
+- `200` (OK): indicates that the response body containing the IPNS record that corresponds to the
+  IPNS name.
+- `404` (Not Found): indicates that no matching records are found.
+- `400` (Bad Request): indicates that the given IPNS record is not valid.
+- `429` (Too Many Requests): indicates that the caller is issuing requests too many request and may
+  retry after the time specified
+  at [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) response
+  header has elapsed.
+- `501` (Not Implemented): indicates that the server does not support publication of IPNS records
+
 ## Pagination
 
 This API does not support pagination, but optional pagination can be added in a backwards-compatible spec update.
@@ -136,10 +192,10 @@ Specification: [ipfs/specs/BITSWAP.md](https://github.com/ipfs/specs/blob/main/B
 
 ```json
 {
-    "Protocol": "transport-bitswap",
-    "Schema": "bitswap",
-    "ID": "12D3K...",
-    "Addrs": ["/ip4/..."]
+  "Protocol": "transport-bitswap",
+  "Schema": "bitswap",
+  "ID": "12D3K...",
+  "Addrs": ["/ip4/..."]
 }
 ```
 
@@ -159,13 +215,13 @@ Specification: [ipfs/go-graphsync/blob/main/docs/architecture.md](https://github
 
 ```json
 {
-    "Protocol": "transport-graphsync-filecoinv1",
-    "Schema": "graphsync-filecoinv1",
-    "ID": "12D3K...",
-    "Addrs": ["/ip4/..."],
-    "PieceCID": "<cid>",
-    "VerifiedDeal": true,
-    "FastRetrieval": true
+  "Protocol": "transport-graphsync-filecoinv1",
+  "Schema": "graphsync-filecoinv1",
+  "ID": "12D3K...",
+  "Addrs": ["/ip4/..."],
+  "PieceCID": "<cid>",
+  "VerifiedDeal": true,
+  "FastRetrieval": true
 }
 ```