docs: editorial aspects to routing specs

Author: hacdias

routing/ROUTING_V1_HTTP.md

@@ -0,0 +1,3 @@
+# Routing V1 HTTP API
+
+Moved to https://specs.ipfs.tech/routing/http-routing-v1/

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

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>

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

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' %}

src/routing/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.