From e0d8d0f8239c3c26e7be38ea804c5f9d33410072 Mon Sep 17 00:00:00 2001
From: Henrique Dias <hacdias@gmail.com>
Date: Fri, 12 May 2023 14:09:51 +0200
Subject: [PATCH] docs: editorial aspects to routing specs

---
 routing/ROUTING_V1_HTTP.md     |  3 +++
 src/architecture/principles.md |  2 +-
 src/index.html                 |  8 ++++++++
 src/ipips/ipip-0337.md         |  6 +++---
 src/routing/http-routing-v1.md | 27 ++++++++++++++-------------
 src/routing/index.html         | 14 ++++++++++++++
 6 files changed, 43 insertions(+), 17 deletions(-)
 create mode 100644 routing/ROUTING_V1_HTTP.md
 create mode 100644 src/routing/index.html

diff --git a/routing/ROUTING_V1_HTTP.md b/routing/ROUTING_V1_HTTP.md
new file mode 100644
index 00000000..d8374a45
--- /dev/null
+++ b/routing/ROUTING_V1_HTTP.md
@@ -0,0 +1,3 @@
+# Routing V1 HTTP API
+
+Moved to https://specs.ipfs.tech/routing/http-routing-v1/
diff --git a/src/architecture/principles.md b/src/architecture/principles.md
index fe4a448b..75512474 100644
--- a/src/architecture/principles.md
+++ b/src/architecture/principles.md
@@ -70,7 +70,7 @@ over arbitrary transports using a CID*. As Juan Benet once put it,
 Conversely, any system that exposes interactions with resources based on CIDs is
 an IPFS implementation. There are
 [many contexts in which CIDs can be used for addressing](https://docs.ipfs.tech/how-to/address-ipfs-on-web/)
-and [content routing delegation](https://github.com/ipfs/specs/blob/main/routing/ROUTING_V1_HTTP.md)
+and content routing delegation (:cite[http-routing-v1])
 can support a wealth of interaction options by resolving CIDs.
 
 ## Robustness
diff --git a/src/index.html b/src/index.html
index 04614c9b..761ca558 100644
--- a/src/index.html
+++ b/src/index.html
@@ -94,6 +94,14 @@ <h3><a href="/ipns/">InterPlanetary Naming System</a></h3>
         </p>
         {% include 'list.html', posts: collections.ipns %}
       </section>
+      <section>
+        <h3><a href="/routing/">Routing</a></h3>
+        <p>
+          Content routing is the way to determine where to find a given CID on the network;
+          specifically, which network peers provide specific CIDs. 
+        </p>
+        {% include 'list.html', posts: collections.routing %}
+      </section>
       <section>
         <h3><a href="/ipips/">InterPlanetary Improvement Proposals</a></h3>
         <p>
diff --git a/src/ipips/ipip-0337.md b/src/ipips/ipip-0337.md
index de3ec7a5..4438ef74 100644
--- a/src/ipips/ipip-0337.md
+++ b/src/ipips/ipip-0337.md
@@ -25,7 +25,7 @@ and supporting large content providers is a key strategy for driving down IPFS c
 These providers must handle high volumes of traffic and support many users, so leveraging industry-standard tools and services
 such as HTTP load balancers, CDNs, reverse proxies, etc. is a requirement.
 To maximize compatibility with standard tools, IPFS needs an HTTP API specification that uses standard HTTP idioms and payload encoding.
-The [Reframe spec](https://github.com/ipfs/specs/blob/main/reframe/REFRAME_PROTOCOL.md) for delegated content routing is an experimental attempt at this,
+The Reframe spec for delegated content routing is an experimental attempt at this,
 but it has resulted in a very unidiomatic HTTP API which is difficult to implement and is incompatible with many existing tools.
 The cost of a proper redesign, implementation, and maintenance of Reframe and its implementation is too high relative to the urgency of having a delegated content routing HTTP API.
 
@@ -36,13 +36,13 @@ We expect this API to be extended beyond "content routing" in the future, so add
 
 ## Detailed design
 
-See the [Delegated Content Routing HTTP API spec](../routing/DELEGATED_CONTENT_ROUTING_HTTP.md) included with this IPIP.
+See the Delegated Content Routing HTTP API spec (:cite[http-routing-v1]) included with this IPIP.
 
 ## Design rationale
 
 To understand the design rationale, it is important to consider the concrete Reframe limitations that we know about:
 
-- Reframe [method types](../reframe/REFRAME_KNOWN_METHODS.md) using the HTTP transport are encoded inside IPLD-encoded messages
+- Reframe method types using the HTTP transport are encoded inside IPLD-encoded messages
   - This prevents URL-based pattern matching on methods, which makes it hard and expensive to do basic HTTP scaling and optimizations:
     - Configuring different caching strategies for different methods
     - Configuring reverse proxies on a per-method basis
diff --git a/src/routing/http-routing-v1.md b/src/routing/http-routing-v1.md
index 4d289178..c1957218 100644
--- a/src/routing/http-routing-v1.md
+++ b/src/routing/http-routing-v1.md
@@ -1,16 +1,17 @@
-# Routing v1 HTTP API
-
-![reliable](https://img.shields.io/badge/status-reliable-green.svg?style=flat-square) Delegated Content Routing HTTP API
-
-**Author(s)**:
-
-- Gus Eggert
-
-**Maintainer(s)**:
-
-* * *
-
-**Abstract**
+---
+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
+  an HTTP API for delegated content routing.
+date: 2023-03-22
+maturity: reliable
+editors:
+  - name: Gus Eggert
+    github: guseggert 
+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.
 
diff --git a/src/routing/index.html b/src/routing/index.html
new file mode 100644
index 00000000..4a883fc4
--- /dev/null
+++ b/src/routing/index.html
@@ -0,0 +1,14 @@
+---
+title: Routing
+description: |
+  Content routing is the way to determine where to find a given CID on the network;
+  specifically, which network peers provide specific CIDs. 
+---
+
+{% include 'header.html' %}
+
+<main>
+  {% include 'list.html', posts: collections.routing %}
+</main>
+
+{% include 'footer.html' %}