Merge pull request #593 from interledger/chj/fix-broken-links

chore: fix broken links on specs
interledger · Apr 30, 2024 · 3e6f066 · 3e6f066
2 parents 340a922 + 8ce0fee
commit 3e6f066
Show file tree

Hide file tree

Showing 7 changed files with 194 additions and 183 deletions.
diff --git a/0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md b/0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md
@@ -158,7 +158,7 @@ We assume that the SPSP Client knows the SPSP Server's SPSP Endpoint (see [Payme
    - The `destination_account` MUST be used as the STREAM `destinationAccount`.
    - The `shared_secret` MUST be decoded from base64 and used as the STREAM `sharedSecret`.
 
-   It MAY respond with additional information if it is an invoice server or a pull payment server. For more information, see [SPSP Invoices](../deprecated/0037-spsp-invoices/0037-spsp-invoices.md) and [SPSP Pull Payments](../deprecated/0036-spsp-pull-payments/0036-spsp-pull-payments.md).
+   It MAY respond with additional information if it is an invoice server or a pull payment server. For more information, see [SPSP Invoices](../0037-spsp-invoices/0037-spsp-invoices.md) and [SPSP Pull Payments](../0036-spsp-pull-payments/0036-spsp-pull-payments.md).
 
 3. The SPSP Client establishes a STREAM connection to the SPSP Server using the SPSP Server's ILP address and shared secret.
 

diff --git a/0023-bilateral-transfer-protocol/0023-bilateral-transfer-protocol.md b/0023-bilateral-transfer-protocol/0023-bilateral-transfer-protocol.md
@@ -56,15 +56,15 @@ spec](https://github.com/interledger/rfcs/blob/master/asn1/BilateralTransferProt
 
 - The **Bilateral Ledger** is the ledger which the peers on a BTP connection
   are keeping track of. When a peer keeping Authoritative State receives a BTP
-packet, they process it and adjust their copy of the bilateral ledger. The
-bilateral ledger is not to be confused with the Underlying Ledger.
+  packet, they process it and adjust their copy of the bilateral ledger. The
+  bilateral ledger is not to be confused with the Underlying Ledger.
 
 - **Authoritative State** is the authoritative view of the Bilateral Ledger's
   state, maintained by one or both of the peers. Because both peers on a BTP
-connection can keep authoritative state, they can get into dispute if they
-disagree on the state of a transfer. This usually happens when network latency
-causes the peers to disagree about expiries. If one party keeps authoritative
-state, the other party must trust them not to tamper with it.
+  connection can keep authoritative state, they can get into dispute if they
+  disagree on the state of a transfer. This usually happens when network latency
+  causes the peers to disagree about expiries. If one party keeps authoritative
+  state, the other party must trust them not to tamper with it.
 
 - A request is **In-Flight** if the request has been sent out, but no response
   has been received yet.
@@ -108,34 +108,34 @@ don't have `Packet Specific Data` section:
 ```
 
 1. **Type**: A 1-byte value describing what type of BTP packet this is.
-The values are described below, in [BTP Type IDs](#btp-type-ids).
+   The values are described below, in [BTP Type IDs](#btp-type-ids).
 
 2. **Request ID**: A random 4-byte value used to correlate requests
-and responses. This value MAY be sequential instead of random, but care must
-be taken so that duplicate IDs are never in-flight at the same time.
+   and responses. This value MAY be sequential instead of random, but care must
+   be taken so that duplicate IDs are never in-flight at the same time.
 
 3. **Length Prefix**: A 1-byte (if under 128) or 2-byte value, containing the
-combined length of the packet-specific data and protocol data sections.
+   combined length of the packet-specific data and protocol data sections.
 
 4. **Packet-Specific Data:** Fields specific to the type of BTP packet. Variable
-length. Some types don't have this section. See [ASN.1 definitions](../asn1/BilateralTransferProtocol.asn) for details.
+   length. Some types don't have this section. See [ASN.1 definitions](../asn1/BilateralTransferProtocol.asn) for details.
 
 5. **Sub-Protocol Count:** Variable-length integer containing the number of
-sub-protocols carried by this packet.
+   sub-protocols carried by this packet.
 
-5. **Sub-Protocol Data:** A list of protocols, containing a string (the protocol's name), a 1-byte flag (containing the MIME type), and a length-prefixed octet string (containing the protocol's data). Exact description is below in [Sub-Protocol Data Format](#sub-protocol-data-format).
+6. **Sub-Protocol Data:** A list of protocols, containing a string (the protocol's name), a 1-byte flag (containing the MIME type), and a length-prefixed octet string (containing the protocol's data). Exact description is below in [Sub-Protocol Data Format](#sub-protocol-data-format).
 
 ### BTP Type IDs
 
-| ID | Type | Request/Response |
-|:--|:--|:--|
-| 1 | `Response` | Response |
-| 2 | `Error` | Response |
-| 3 | (not used) |  |
-| 4 | (not used) |  |
-| 5 | (not used) |  |
-| 6 | `Message` | Request |
-| 7 | `Transfer` | Request |
+| ID  | Type       | Request/Response |
+| :-- | :--------- | :--------------- |
+| 1   | `Response` | Response         |
+| 2   | `Error`    | Response         |
+| 3   | (not used) |                  |
+| 4   | (not used) |                  |
+| 5   | (not used) |                  |
+| 6   | `Message`  | Request          |
+| 7   | `Transfer` | Request          |
 
 ### Sub-Protocol Data Format
 
@@ -173,10 +173,10 @@ The server responds with a `Response` or `Error` as appropriate. Again, the
 `protocolData` field there MAY be used to send additional information to
 the client. To be clear, the server responds with an `Error` if:
 
-* any other packet is sent before the auth data
-* the provided authentication data is invalid or incorrect
-* any of the other protocol rules are violated (e.g. having two subprotos with the same name)
-* it takes too long before the authentication data is sent.
+- any other packet is sent before the auth data
+- the provided authentication data is invalid or incorrect
+- any of the other protocol rules are violated (e.g. having two subprotos with the same name)
+- it takes too long before the authentication data is sent.
 
 If the server sent an `Error`, it subsequently closes the connection.
 If the server sent a `Response`, the BTP connection is open, until either
@@ -222,7 +222,7 @@ There are also a couple of tricky cases to handle:
 - If an unexpected BTP packet is received, no response should be sent. An unexpected BTP packet is a response for which a request was not sent, or a response for a request which has already been responded to.
 - If an unreadable BTP packet is received, no response should be sent. An unreadable BTP packet is one which is structurally invalid, i.e. terminates before length prefixes dictate or contains illegal characters.
 
-These behaviors are important for preventing accidental feedback loops.  If an
+These behaviors are important for preventing accidental feedback loops. If an
 unexpected packet triggered an error, that error may be unexpected to the
 sender. The sender would reply with another unexpected error, causing an
 infinite loop. Unreadable packets must be ignored too. If an application got
@@ -239,17 +239,17 @@ Message ::= SEQUENCE {
 ```
 
 `Message` is used for sending information to the peer. It contains no
-packet-specific data, only protocol data. [ILP](https://github.com/interledger/rfcs/blob/master/0003-interledger-protocol/0003-interledger-protocol.md#ilp-payment-packet-format) packets are attached under the
+packet-specific data, only protocol data. [ILP](../0003-interledger-protocol/0003-interledger-protocol.md#ilp-payment-packet-format) packets are attached under the
 protocol name `ilp` with content-type `application/octet-stream`.
 
 - `Response` is returned if the peer acknowledges the `Message`. If the peer
   has data to send in reply (e.g. a quote response), it is carried in the
-protocol data.
+  protocol data.
 
 - `Error` is returned if the peer is not able to process the `Message`, or there
   was an unexpected error and further `Message`s should not be sent. This does
-not include ILP errors such as "No quote found", only the cases in which the
-`Message` cannot be sent/processed at all.
+  not include ILP errors such as "No quote found", only the cases in which the
+  `Message` cannot be sent/processed at all.
 
 ### Error
 
@@ -270,7 +270,7 @@ Error ::= SEQUENCE {
 
 `Error` is a response-type message, returned when an error occurs on the BTP
 level. It has packet-specific data which resembles the [ILP Error
-format](https://github.com/interledger/rfcs/blob/master/0003-interledger-protocol/0003-interledger-protocol.md#ilp-error-format),
+format](../0003-interledger-protocol/0003-interledger-protocol.md#ilp-error-format),
 but irrelevant fields have been taken off and new error codes have been
 written:
 
@@ -281,17 +281,17 @@ Errors marked with a `T` are temporary, and can be retried after a short
 SHOULD wait longer before trying again. Errors marked with `F` are final, and
 the same request MUST NOT be retried.
 
-| Code | Name | Description |
-|:--|:--|:--|
-| **T00** | UnreachableError | Temporary error, indicating that the connector cannot process this request at the moment. Try again later. |
-| **F00** | NotAcceptedError | Data were symantically invalid. |
-| **F01** | InvalidFieldsError | At least one field contained structurally invalid data, e.g. timestamp full of garbage characters. |
-| **F03** | TransferNotFoundError | The transferId included in the packet does not reference an existing transfer. |
-| **F04** | InvalidFulfillmentError | The fulfillment included in the packet does not match the transfer's condition. |
-| **F05** | DuplicateIdError | The transferId and method match a previous request, but other data do not. |
-| **F06** | AlreadyRolledBackError | The transfer cannot be fulfilled because it has already been rejected or expired. |
-| **F07** | AlreadyFulfilledError | The transfer cannot be rejected because it has already been fulfilled. |
-| **F08** | InsufficientBalanceError | The transfer cannot be prepared because there is not enough available liquidity. |
+| Code    | Name                     | Description                                                                                                |
+| :------ | :----------------------- | :--------------------------------------------------------------------------------------------------------- |
+| **T00** | UnreachableError         | Temporary error, indicating that the connector cannot process this request at the moment. Try again later. |
+| **F00** | NotAcceptedError         | Data were symantically invalid.                                                                            |
+| **F01** | InvalidFieldsError       | At least one field contained structurally invalid data, e.g. timestamp full of garbage characters.         |
+| **F03** | TransferNotFoundError    | The transferId included in the packet does not reference an existing transfer.                             |
+| **F04** | InvalidFulfillmentError  | The fulfillment included in the packet does not match the transfer's condition.                            |
+| **F05** | DuplicateIdError         | The transferId and method match a previous request, but other data do not.                                 |
+| **F06** | AlreadyRolledBackError   | The transfer cannot be fulfilled because it has already been rejected or expired.                          |
+| **F07** | AlreadyFulfilledError    | The transfer cannot be rejected because it has already been fulfilled.                                     |
+| **F08** | InsufficientBalanceError | The transfer cannot be prepared because there is not enough available liquidity.                           |
 
 ### Transfer
 
@@ -310,9 +310,9 @@ previous settlement state), in a unit that was agreed out-of-band.
 
 - `Response` is returned if the peer acknowledges the `Transfer`. This means
   the transfer is now completed and has been applied to the balance. If a
-`Response` has been returned, balances MUST have been updated.
+  `Response` has been returned, balances MUST have been updated.
 
 - `Error` is returned if the peer does not accept the transfer. This could be
   because some protocol data are malformed, or because the peer believes that
-the sender's balance is insufficient. If an `Error` has been returned, the peer
-MUST NOT have updated their balance.
+  the sender's balance is insufficient. If an `Error` has been returned, the peer
+  MUST NOT have updated their balance.