more removals; more concise request spec

EIPS/eip-1193.md

@@ -311,16 +311,11 @@ The Provider is said to be "disconnected" when it cannot service RPC requests to
 
 ### API
 
-The Provider API is specified using TypeScript.
+> The Provider API is specified using TypeScript.
+> The authors encourage implementers to declare their own types and interfaces, using the ones in this section as a basis.
 
 The Provider **MUST** implement and expose the API defined in this section. All API entities **MUST** adhere to the types and interfaces defined in this section.
 
-> The TypeScript `interface` declarations are designed to be minimal and extensible.
-> The authors encourage implementers to make syntactically valid extensions of interfaces when necessary.
->
-> Furthermore, an `unknown` type indicates that the possible values depend on information external to this specification.
-> The authors encourage implementers to replace instances of `unknown` with more specific types in their own type definitions, if the possible values can be known at compile time.
-
 #### request
 
 > The `request` method is intended as a transport- and protocol-agnostic wrapper function for Remote Procedure Calls (RPCs).
@@ -334,14 +329,13 @@ interface RequestArguments {
 Provider.request(args: RequestArguments): Promise<unknown>;
 ```
 
-> In practice, it is likely possible to enumerate the possible types of `params` at compile time, with reference to the Provider implementation's [Supported RPC Methods](#supported-rpc-methods).
+The Provider **MUST** identify the requested RPC method by the value of `RequestArguments.method`.
 
-The `request` method **MUST** send a properly formatted request to the Provider's Ethereum client.
-Requests **MUST** be handled such that, for a given set of arguments, the returned Promise either resolves with a value per the RPC method's specification, or rejects with an error.
+If the requested RPC method takes any parameters, the Provider **MUST** accept them as the value of `RequestArguments.params`.
 
-If resolved, the Promise **MUST NOT** resolve with any RPC protocol-specific response objects, unless the RPC method's return type is so defined by its specification.
+RPC requests **MUST** be handled such that the returned Promise either resolves with a value per the requested RPC method's specification, or rejects with an error.
 
-If resolved, the Promise **MUST** resolve with a result per the RPC method's specification.
+If resolved, the Promise **MUST** resolve with a result per the RPC method's specification. The Promise **MUST NOT** resolve with any RPC protocol-specific response objects, unless the RPC method's return type is so defined.
 
 If the returned Promise rejects, it **MUST** reject with a `ProviderRpcError` as specified in the [RPC Errors](#rpc-errors) section below.
 
@@ -370,11 +364,6 @@ All supported RPC methods **MUST** be identified by unique strings.
 
 Providers **MAY** support whatever RPC methods required to fulfill their purpose, standardized or otherwise.
 
-If a Provider supports a method defined in a finalized EIP, the Provider's implementation of this method **MUST** adhere to the method's specification. This includes:
-
-- The method name, given as the value of `RequestArguments.method`
-- The method parameters, given as the value of `RequestArguments.params`
-
 If an RPC method defined in a finalized EIP is not supported, it **SHOULD** be rejected with a `4200` error per the [Provider Errors](#provider-errors) section below, or an appropriate error per the RPC method's specification.
 
 #### RPC Errors