fix: introduce unkown filtering

src/ipips/ipip-0484.md

@@ -38,7 +38,7 @@ The term **"transport"** is overloaded in the IPFS ecosystem.
 
 In the context of this IPIP, we refer to the network layer transport protocol, e.g. TCP, QUIC, WebTransport, as **"network transport protocol"** to avoid ambiguity.
 
-**"Transfer protocol"** refers to data exchange protocols, i.e. content-addressed block retrieval format, e.g. Bitswap, GraphSync, HTTP.
+**"Transfer protocol"** refers to data transfer protocols, i.e. content-addressed block retrieval protocols, e.g. Bitswap, GraphSync, HTTP.
 
 ## Detailed design
 
@@ -51,9 +51,9 @@ The proposed change is to add a `?network-transports` parameter to the `GET /rou
 - Multiaddrs are filtered by checking if the protocol name appears in any of the multiaddrs.
 - Only multiaddrs that pass the filter are included in the response.
 - If there are no multiaddrs that match the passed transports, the provider is omitted from the response.
-- Negative filtering is done by prefixing the protocol name with `!`, e.g. `?network-transports=!webtransport`.
-- The filtering is case-insensitive.
-- If the parameter is not passed, the default behavior is to not apply filtering by network transports.
+- Negative filtering is done by prefixing the protocol name with `!`, e.g. `?network-transports=!quic-v1,!tcp`.
+- Filtering is case-insensitive.
+- If no parameter is passed, the default behavior is to not apply filtering by network transports.
 
 :::note
 Filtering out providers without any matching transport, will cause providers without any multiaddrs to be filtered out, even if they _might_ support the requested transports. This is due to the fact that provider records are independent of peer records, and it's pretty common to have provider records without up-to-date multiaddrs for that peer.
@@ -64,27 +64,26 @@ Filtering out providers without any matching transport, will cause providers wit
 The proposed change is to add a `?transfer-protocols` parameter to the `GET /routing/v1/providers/{cid}` endpoint of :cite[http-routing-v1]:
 
 - Add a `?transfer-protocols=<comma-separated-list>` optional parameter to `GET /routing/v1/providers/{CID}` that indicates which transfer protocols to return by filtering the `Protocol` field of the [Peer schema].
-- The value of the `transfer-protocols` parameter is a comma-separated list of known transfer protocol names:
-  - `transport-bitswap`
-  - `transport-graphsync-filecoinv1`
-  - `transport-ipfs-gateway-http`
-- Providers are filtered by checking if the transfer protocol name appears at least once in the `Protocols` array.
+- The `transfer-protocols` parameter is a comma-separated list of transfer protocol names, e.g. `?transfer-protocols=transport-bitswap`.
+- Transfer protocols names should be treated as opaque strings and have a max length of 63 characters. A non-exhaustive list of transfer protocols are defined per convention in the [multicodec registry](https://github.com/multiformats/multicodec/blob/3b7b52deb31481790bc4bae984d8675bda4e0c82/table.csv#L149-L151). Implementations should not break when encountering unknown transfer protocol names.
+- `unknown` can be be passed to include providers whose transfer protocol is unknown, e.g. `?transfer-protocols=unknown`. This allows filtering providers returned from the DHT that do not contain explicit transfer protocol information.
+- Providers are filtered by checking if the transfer protocol name appears in the `Protocols` array.
 - If the provider doesn't match any of the passed transfer protocols, the provider is omitted from the response.
 - Negative filtering is done by prefixing the protocol name with `!`, e.g. `?transport=!transport-graphsync-filecoinv1`.
-- The filtering is case-insensitive.
-- If the parameter is not passed, the default behavior is to not filter by transfer protocol.
-- Providers returned from the DHT, currently do not contain a `Protocol` field. In such cases, Bitswap can be implied.
+- Filtering is case-insensitive.
+- If no parameter is passed, the default behavior is to not filter by transfer protocol.
+
 
 :::note
-For legacy reasons, the transfer protocols are referred to and prefixed with `transport` in their names, e.g. `transport-bitswap`, `transport-graphsync-filecoinv1`, and `transport-ipfs-gateway-http`. This is not to be confused with the network transport protocols, which are filtered using the `network-transports` parameter.
+Even though existing transfer protocol names start with `transport`, e.g. `transport-bitswap`, `transport-graphsync-filecoinv1`, and `transport-ipfs-gateway-http`. This is not to be confused with the network transport protocols, which are filtered using the `network-transports` parameter.
 :::
 
 ## Design rationale
 
 - Using these query parameters improves cache efficiency, as the response will be smaller and more specific to the client's needs.
 - Backward compatibility by not changing the default behavior of the API.
 - Use of protocol name rather than code makes it easier for human debugging.
-- DHT providers currently do not contain any transfer protocol, even though Bitswap can be implied in all cases.
+- DHT providers currently do not contain any transfer protocol information. `unknown` can be used to filter such providers.
 
 ### User benefit