Apply suggestions from code review

Co-authored-by: Marcin Rataj <[email protected]>

src/ipips/ipip-0484.md

@@ -7,10 +7,10 @@ editors:
     github: 2color
     affiliation:
       name: Shipyard
-      url: https://www.ipshipyard.com/
+      url: https://ipshipyard.com
 relatedIssues:
   - https://github.com/ipfs-shipyard/someguy/issues/13
-order: 483
+order: 484
 tags: ['ipips']
 ---
 
@@ -30,7 +30,7 @@ For instance, web browsers are limited to a specific set of network transport pr
 
 Moreover, [Helia](https://github.com/ipfs/helia/), the most actively maintained browser IPFS implementation, supports block retrieval by CID with Bitswap and Trustless Gateways, but does not support GraphSync.
 
-This means that returning providers that only support GraphSync from the Delegated Routing API is not useful for browser clients, and results in unnecessary network traffic for browser clients.
+This means that returning providers that only support raw TCP, raw UDP/QUIC, or GraphSync from the Delegated Routing API is not useful for browser clients, and results in unnecessary network traffic for browser clients.
 
 ## Note on terminology
 
@@ -48,7 +48,7 @@ The proposed change is to add a `?network-transports` parameter to the `GET /rou
 
 - Add a `?network-transports=<comma-separated-list>` optional parameter to `GET /routing/v1/providers/{CID}` that indicates which network transports to return by filtering the multiaddrs in the `Addrs` field of the [Peer schema].
 - The value of the `network-transports` parameter is a comma-separated list of network transport protocol _name strings_ as defined in the [multiaddr protocol registry](https://github.com/multiformats/multiaddr/blob/master/protocols.csv), e.g. `?network-transports=webtransport`.
-- Multiaddrs are filtered by checking if the protocol name appears in any of the multiaddrs.
+- Multiaddrs are filtered by checking if the protocol name appears in any of the multiaddrs (logical OR).
 - 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=!quic-v1,!tcp`.
@@ -63,7 +63,7 @@ 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].
+- 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] (logical OR).
 - 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.