path/trustless gateway spec: take review comments.

Co-Authored-By: Marcin Rataj <lidel@lidel.org>

Author: hsanjuan

src/http-gateways/path-gateway.md

@@ -389,8 +389,8 @@ This error response SHOULD include
 [`Retry-After`](#retry-after-response-header) HTTP header to indicate how long
 the client should wait before retrying.
 
-Gateways MUST return `404` instead of `502` when the content is known to be
-unretrivable: for example, when the Gateway is
+Gateways SHOULD return `404` instead of `502` when the content is known to be
+unretrievable: for example, when the Gateway is
 [non-recursive](#recursive-vs-non-recursive-gateways) and the content is known
 to not be available.
 
@@ -408,12 +408,11 @@ This error response SHOULD include
 [`Retry-After`](#retry-after-response-header) HTTP header to indicate how long
 the client should wait before retrying.
 
-Gateways MUST return `404` instead of `504` when the content is known to be
-unretrivable: for example, when the Gateway is
+Gateways SHOULD return `404` instead of `504` when the content is known to be
+unretrievable: for example, when the Gateway is
 [non-recursive](#recursive-vs-non-recursive-gateways) and the content is known
 to not be available.
 
-
 ## Response Headers
 
 ### `Etag` (response header)
@@ -888,7 +887,7 @@ suggest that clients retry failed requests later via `502` and `504` respones
 status codes.
 
 A *non-recursive Gateway* is gateway which accesses a known content-set and,
-under normal operation conditions, knows with certainity whether content
+under normal operation conditions, knows with certainty whether content
 requested can be obtained or not. Non-recursive gateways SHOULD prevent
 unnecessary retries from clients when the content is known to be unavailable
 by returning `404`.

src/http-gateways/trustless-gateway.md

@@ -47,13 +47,13 @@ Optional `path` is permitted for requests that specify CAR format (`?format=car`
 
 For block requests (`?format=raw` or `Accept: application/vnd.ipld.raw`), only `GET /ipfs/{cid}[?{params}]` is supported.
 
-It is RECOMMENDED to additionally implement the [`GET` probe path](#dedicated-probe-paths).
+Client and Server implementations SHOULD include support for the [`GET` probe path](#dedicated-probe-paths).
 
 ## `HEAD /ipfs/{cid}[/{path}][?{params}]`
 
 Same as GET, but does not return any payload.
 
-It is RECOMMENDED to additionally implement the [`HEAD` probe path](#dedicated-probe-paths).
+Client and Server implementations SHOULD include support for the [`HEAD` probe path](#dedicated-probe-paths).
 
 ## `GET /ipns/{key}[?{params}]`
 
@@ -456,15 +456,13 @@ Trustless gateways SHOULD provide probing endpoints as described below.
 `bafkqaaa` is the identity empty CID. This endpoint can be used to probe that
 that the endpoint corresponds to a trustless gateway.
 
-For block requests (`?format=raw`), when supported, it must return `200 OK`
+For block requests (`?format=raw`), when supported, it MUST return `200 OK`
 and an empty body.
 
-For CAR requests (`?format=car`), when supported, it must return `200 OK` and
-CAR file with root set to `bafkqaaa` and a single `bafkqaaa` block (which is
-empty).
+For CAR requests (`?format=car`), when supported, it MUST return `200 OK` and a valid CAR file with CAR Header `roots` set to `bafkqaaa`. Identity block MAY be skipped in the CAR Data section.
 
-We recommend supporting only this specific identity CID and not random
-identity CIDs.
+This specific identity CID is special for probing. Other random
+identity CIDs SHOULD not be handled.
 
 ### `HEAD /ipfs/bafkqaaa`
 
@@ -473,5 +471,5 @@ MUST support [`HEAD` requests](#head-ipfs-cid-path-params).
 
 It must return `200 OK` in all cases.
 
-We recommend supporting only this specific identity CID and not random
-identity CIDs.
+This specific identity CID is special for probing. Other random
+identity CIDs SHOULD not be handled.