Move 3668 to Review (ethereum#4633)

* Move 3668 to Last-Call

* Move to review instead

* Replace simple summary with description

* Minor tweak around error response handling

EIPS/eip-3668.md

@@ -1,17 +1,15 @@
 ---
 eip: 3668
 title: "CCIP Read: Secure offchain data retrieval"
+description: CCIP Read provides a mechanism to allow a contract to fetch external data.
 author: Nick Johnson (@arachnid)
 discussions-to: https://ethereum-magicians.org/t/durin-secure-offchain-data-retrieval/6728
-status: Draft
+status: Review
 type: Standards Track
 category: ERC
 created: 2020-07-19
 ---
 
-## Simple Summary
-CCIP Read provides a mechanism to allow a contract to fetch external data.
-
 ## Abstract
 Contracts wishing to support lookup of data from external sources may, instead of returning the data directly, revert using `OffchainLookup(address sender, string[] urls, bytes callData, bytes4 callbackFunction, bytes extraData)`. Clients supporting this specification then make an RPC call to a URL from `urls`, supplying `callData`, and getting back an opaque byte string `response`. Finally, clients call the function specified by `callbackFunction` on the contract, providing `response` and `extraData`. The contract can then decode and verify the returned data using an implementation-specific method.
 
@@ -152,7 +150,7 @@ Compliant gateways MUST respond with a Content-Type of `application/json`, with
 }
 ```
 
-Unsuccessful requests MUST return the appropriate HTTP status code - for example, 404 if the `sender` address is not supported by this gateway, 400 if the `callData` is in an invalid format, 500 if the server encountered an internal error, and so forth. The Content-Type of a 4xx or 5xx response MUST also be `application/json`, with the body adhering to the following JSON schema:
+Unsuccessful requests MUST return the appropriate HTTP status code - for example, 404 if the `sender` address is not supported by this gateway, 400 if the `callData` is in an invalid format, 500 if the server encountered an internal error, and so forth. If the Content-Type of a 4xx or 5xx response is `application/json`, it MUST adhere to the following JSON schema:
 ```
 {
     "type": "object",
@@ -203,6 +201,8 @@ A client that supports CCIP read MUST make contract calls using the following pr
 
 Clients MUST handle HTTP status codes appropriately, employing best practices for error reporting and retries.
 
+Clients MUST handle HTTP 4xx and 5xx error responses that have a content type other than application/json appropriately; they MUST NOT attempt to parse the response body as JSON.
+
 This protocol can result in multiple lookups being requested by the same contract. Clients MUST implement a limit on the number of lookups they permit for a single contract call, and this limit SHOULD be at least 4.
 
 The lookup protocol for a client is described with the following pseudocode: