Merge branch 'links-to-props' into 'main'

Add links from tor-spec to proposals

See merge request tpo/core/torspec!224

4 files changed, 48 insertions, 28 deletions

diff --git a/spec/tor-spec/create-created-cells.md b/spec/tor-spec/create-created-cells.md
index b5cf224..8975cca 100644
--- a/spec/tor-spec/create-created-cells.md
+++ b/spec/tor-spec/create-created-cells.md
@@ -605,12 +605,12 @@ Currently supported extensions are:
   
    Contains an empty payload.  Signifies that the client
    wants to use the extended congestion control described
-   in proposal 324.
+   in [proposal 324].
   
  * 2 -- `CC_FIELD_RESPONSE` \[Server to client\]
   
    Indicates that the relay will use the congestion control
-   of proposal 324, as requested by the client.  One byte
+   of [proposal 324], as requested by the client.  One byte
    in length:
   
    `sendme_inc        [1 byte]`
@@ -618,4 +618,7 @@ Currently supported extensions are:
  * 3 -- Subprotocol Request \[Client to Server\]
   
    (RESERVED) Tells the endpoint what protocol version to use on the
-   circuit (prop346).
+   circuit ([proposal 346]).
+
+[proposal 324]: ../proposals/324-rtt-congestion-control.txt
+[proposal 346]: ../proposals/346-protovers-again.md
diff --git a/spec/tor-spec/flow-control.md b/spec/tor-spec/flow-control.md
index 91c04e3..e0f7ad1 100644
--- a/spec/tor-spec/flow-control.md
+++ b/spec/tor-spec/flow-control.md
@@ -24,7 +24,9 @@ a high-priority (non-relayed) cell. If it's been less than N seconds
 (currently N=30), we give the whole connection high priority, else we
 give the whole connection low priority. We also give low priority
 to reads and writes for connections that are serving directory
-information. See proposal 111 for details.
+information. See [proposal 111] for details.
+
+[proposal 111]: ../proposals/111-local-traffic-priority.txt
 
 <a id="tor-spec.txt-7.2"></a>
 
diff --git a/spec/tor-spec/relay-cells.md b/spec/tor-spec/relay-cells.md
index 3f0c3a7..5de6d90 100644
--- a/spec/tor-spec/relay-cells.md
+++ b/spec/tor-spec/relay-cells.md
@@ -44,18 +44,18 @@ The relay commands are:
 | 13      | RELAY_BEGIN_DIR | forward             |
 | 14      | RELAY_EXTEND2   | forward             | control
 | 15      | RELAY_EXTENDED2 | backward            | control
-| 16..18  | Reserved for UDP; Not yet in use, see [prop339][prop339].
-| 19..22  | Reserved for Conflux, see [prop329][prop329].
-| 32..40  | Used for hidden services; see the [rendezvous spec][rend-spec].
-| 41..42  | Used for circuit padding; see ["Circuit-level padding"][circ-padding] in the padding spec.
-| 43      | XON  (See Sec 4 of [prop324][prop324])  | forward or backward |
-| 44      | XOFF (See Sec 4 of [prop324][prop324])  | forward or backward |
+| 16..18  | Reserved for UDP; Not yet in use, see [prop339].
+| 19..22  | Reserved for Conflux, see [prop329].
+| 32..40  | Used for hidden services; see the [rendezvous spec].
+| 41..42  | Used for circuit padding; see ["Circuit-level padding"] in the padding spec.
+| 43      | XON  (See Sec 4 of [prop324])  | forward or backward |
+| 44      | XOFF (See Sec 4 of [prop324])  | forward or backward |
 
 [prop324]: ../proposals/324-rtt-congestion-control.txt
 [prop329]: ../proposals/329-traffic-splitting.md
 [prop339]: ../proposals/339-udp-over-tor.md
-[rend-spec]: ../rend-spec/index.md
-[circ-padding]: ../padding-spec/circuit-level-padding.md#circuit-level-padding
+[rendezvous spec]: ../rend-spec/index.md
+["Circuit-level padding"]: ../padding-spec/circuit-level-padding.md#circuit-level-padding
 
 Commands labelled as "forward" must only be sent by the originator
 of the circuit. Commands labelled as "backward" must only be sent by
@@ -108,7 +108,9 @@ bytes for other cell types; see [Cell Packet format](./cell-packet-format.md#cel
 
 <span id="relay-cell-padding">The
 'Padding' field is used to make relay cell contents unpredictable, to
-avoid certain attacks (see proposal 289 for rationale). Implementations
+avoid certain attacks (see
+[proposal 289](../proposals/289-authenticated-sendmes.txt)
+for rationale). Implementations
 SHOULD fill this field with four zero-valued bytes, followed by as many
 random bytes as will fit.  (If there are fewer than 4 bytes for padding,
 then they should all be filled with zero.</span>
diff --git a/spec/tor-spec/subprotocol-versioning.md b/spec/tor-spec/subprotocol-versioning.md
index 82b25c4..8d241cc 100644
--- a/spec/tor-spec/subprotocol-versioning.md
+++ b/spec/tor-spec/subprotocol-versioning.md
@@ -85,7 +85,7 @@ Current versions are:
 
  * "1" is the RSA link authentication described in [Link authentication type 1: RSA-SHA256-TLSSecret](./negotiating-channels.md#RSA-SHA256-TLSSecret).
 
- * "2" is unused, and reserved by proposal 244.
+ * "2" is unused, and reserved by [proposal 244].
 
  * "3" is the ed25519 link authentication described in [Link authentication type 3: Ed25519-SHA256-RFC5705](./negotiating-channels.md#Ed25519-SHA256-RFC5705).
 
@@ -155,14 +155,15 @@ Current versions are as follows.
      * react to consensuses recommending or requiring support for
        "Relay=3".
 
-   This subprotocol version is described in proposal 311, and
-   implemented in Tor 0.4.5.1-alpha.
+   This subprotocol version is described in
+   [proposal 311], and implemented in Tor 0.4.5.1-alpha.
 
  * "4" -- support the ntorv3 (version 3) key exchange and all features in
-   0.4.7.3-alpha. This adds a new CREATE2 cell type. See proposal 332
+   0.4.7.3-alpha. This adds a new CREATE2 cell type. See [proposal 332]
    and [The "ntor-v3" handshake](./create-created-cells.md#ntor-v3) for more details.
 
- * "5" -- \[RESERVED\] support the ntorv3 subprotocol request extension (prop346)
+ * "5" -- \[RESERVED\] support the ntorv3 subprotocol request extension
+   ([proposal 346])
    allowing a client to request what features to be used on a circuit.
 
 <a id="tor-spec.txt-9.4"></a>
@@ -171,11 +172,10 @@ Current versions are as follows.
 
 The "HSIntro" protocol handles introduction points.
 
- * "3" -- supports authentication as of proposal 121 in Tor
-   0.2.1.6-alpha.
+ * "3" -- supports authentication as of [proposal 121] in Tor 0.2.1.6-alpha.
 
  * "4" -- support ed25519 authentication keys which is defined by the HS v3
-   protocol as part of proposal 224 in Tor 0.3.0.4-alpha.
+   protocol as part of [proposal 224] in Tor 0.3.0.4-alpha.
 
  * "5" -- support ESTABLISH_INTRO cell DoS parameters extension for onion
    service version 3 only in Tor 0.4.2.1-alpha.
@@ -202,7 +202,7 @@ of URLs available to fetch them.
  * "1" -- supports all features in Tor 0.2.0.10-alpha.
 
  * "2" -- support ed25519 blinded keys request which is defined by the HS v3
-   protocol as part of proposal 224 in Tor 0.3.0.4-alpha.
+   protocol as part of [proposal 224] in Tor 0.3.0.4-alpha.
 
 <a id="tor-spec.txt-9.7"></a>
 
@@ -271,7 +271,7 @@ Describes the padding capabilities of the relay.
    circuit-level padding. Advertised by Tor versions from
    tor-0.4.0.1-alpha and only up to and including tor-0.4.1.4-rc.
 
- * "2" -- Relay supports the HS circuit setup padding machines (proposal 302).
+ * "2" -- Relay supports the HS circuit setup padding machines ([proposal 302]).
    Advertised by Tor versions from tor-0.4.1.5 and onwards.
 
 <a id="tor-spec.txt-9.12"></a>
@@ -282,11 +282,11 @@ Describes the flow control protocol at the circuit and stream level. If
 there is no FlowCtrl advertised, tor supports the unauthenticated flow
 control features (version 0).
 
- * "1" -- supports authenticated circuit level SENDMEs as of proposal 289 in
+ * "1" -- supports authenticated circuit level SENDMEs as of [proposal 289] in
    Tor 0.4.1.1-alpha.
 
  * "2" -- supports congestion control by the Exits which implies a new SENDME
-   format and algorithm. See proposal 324 for more details. Advertised
+   format and algorithm. See [proposal 324] for more details. Advertised
    in tor 0.4.7.3-alpha.
 
 ## "Conflux"
@@ -295,7 +295,7 @@ Describes the communications mechanisms used to bundle circuits together,
 in order to split traffic across multiple paths.
 
 > TODO: This is not yet described here. For details see
-> [Proposal 329](../proposals/329-traffic-splitting.txt).
+> [proposal 329].
 
 <a id="tor-spec.txt-9.13"></a>
 
@@ -304,5 +304,18 @@ in order to split traffic across multiple paths.
 Describes the UDP protocol capabilities of a relay.
 
  * "1" -- \[RESERVED\] supports UDP by an Exit as in the relay command
-   CONNECT_UDP, CONNECTED_UDP and DATAGRAM. See proposal
-   339 for more details. (Not yet advertised, reserved)
+   CONNECT_UDP, CONNECTED_UDP and DATAGRAM. See [proposal 339] for more details.
+   (Not yet advertised, reserved)
+
+[proposal 121]: ../proposals/121-hidden-service-authentication.txt
+[proposal 224]: ../proposals/224-rend-spec-ng.txt
+[proposal 244]: ../proposals/244-use-rfc5705-for-tls-binding.txt
+[proposal 289]: ../proposals/289-authenticated-sendmes.txt
+[proposal 302]: ../proposals/302-padding-machines-for-onion-clients.txt
+[proposal 311]: ../proposals/311-relay-ipv6-reachability.txt
+[proposal 324]: ../proposals/324-rtt-congestion-control.txt
+[proposal 329]: ../proposals/329-traffic-splitting.txt
+[proposal 332]: ../proposals/332-ntor-v3-with-extra-data.md
+[proposal 339]: ../proposals/339-udp-over-tor.md
+[proposal 346]: ../proposals/346-protovers-again.md
+