Apply suggestions from code review

Co-authored-by: Marcin Rataj <lidel@lidel.org>

src/ipips/ipip-0484.md

@@ -1,5 +1,5 @@
 ---
-title: 'IPIP-0484: Delegated Routing V1 Support for Querying Specific Network Transport and Transfer Protocols'
+title: 'IPIP-0484: Opt-in Provider and Peer Filtering in Routing V1 HTTP API'
 date: 2024-09-03
 ipip: proposal
 editors:
@@ -58,23 +58,23 @@ The proposed change is to add a `?filter-addrs` parameter to the `GET /routing/v
 - If there are no multiaddrs that match the passed transports, the provider is omitted from the response.
 - Filtering is case-insensitive.
 
-### Transfer Protocol Filtering
+### IPFS Protocol Filtering
 
 The proposed change is to add a `?filter-protocols` parameter to the `GET /routing/v1/providers/{cid}` and `GET /routing/v1/peers/{peer-id}` endpoints of :cite[http-routing-v1]:
 
 - Add a `?filter-protocols=<comma-separated-list>` optional parameter to `GET /routing/v1/providers/{CID}` to filter providers based on the `Protocol` field of the [Peer schema].
 - The `filter-protocols` parameter is a comma-separated list of transfer protocol names, e.g. `?filter-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 MUST ignore unknown transfer protocol names.
-- `unknown` can be be passed to include providers whose transfer protocol is unknown, e.g. `?filter-protocols=unknown`. This allows filtering providers returned from the DHT that do not contain explicit transfer protocol information.
+- Implementations MUST preserve all transfer protocol names when returning a positive result that matches one or more of them.
+- A special `unknown` name can be be passed to include providers whose transfer protocol list is empty (unknown), e.g. `?filter-protocols=unknown`. This allows for including 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 (logical OR).
 - If the provider doesn't match any of the passed transfer protocols, the provider is omitted from the response.
 - If a provider passes the filter, it is returned unchanged, i.e. the full set of protocols is returned including protocols that not included in the filter. (note that this is different from `filter-addrs` where only the multiaddrs that pass the filter are returned)
 - Filtering is case-insensitive.
 - If no parameter is passed, the default behavior is to not filter by transfer protocol.
 
 :::note
-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 `filter-addrs` parameter.
+Even though some of existing IPFS transfer protocol names start with `transport`, e.g. `transport-bitswap`, `transport-graphsync-filecoinv1`, and `transport-ipfs-gateway-http`, they should not to be confused with the network transport protocols used in peer addresses, which are filtered using the `filter-addrs` parameter.
 :::
 
 ## Design rationale