Update EIP based on PR comments

EIPS/EIP-X-add-token-uri-kylanhurt.md → EIPS/EIP-961.md

@@ -1,13 +1,11 @@
-## Preamble
-
-    EIP: <to be assigned>
-    Title: URL Format for Tokens
-    Author: Kylan Hurt <[email protected]>, Eliran Zach <[email protected]>
-    Type: Standard Track
-    Category: ERC
-    Status: Draft
-    Created: 2018-04-01
-    Requires: 20, 831
+---
+    eip: 961
+    title: URL Format for Tokens
+    status: Active
+    type: Standards Track
+    author: Kylan Hurt <[email protected]>, Eliran Zach <[email protected]>
+    created: 2018-04-01
+---
 
 ## Simple Summary
 A standard way of representing token information, facilitating the process of adding ERC #20 tokens as URLs on the application layer.
@@ -24,7 +22,7 @@ The convenience of representing payment requests by standard URLs has been a sig
 ### Syntax
 Token data URLs contain "ethereum" in their schema (protocol) part and are constructed as follows:
 
-    request                 = "ethereum" ":" [ "token-" ]target_address [ "@" chain_id ] [ "?" parameters ]
+    request                 = "ethereum" ":" "token_info-" target_address [ "@" chain_id ] [ "?" parameters ]
     target_address          = ethereum_address
     chain_id                = 1*DIGIT
     ethereum_address        = ( "0x" 40*40HEXDIG ) / ENS_NAME
@@ -42,18 +40,18 @@ Where all of the key + value pairs are optional, allowing for maximum flexibilit
 
 `chain_id` is optional and contains the decimal chain ID, such that transactions on various test- and private networks can be requested. If no `chain_id` is present, the client's current network setting remains effective.
 
-If using ENS names instead of hexadecimal addresses, the resolution is up to the payer, at any time between receiving the URL and sending the transaction. Hexadecimal addresses always take precedence over ENS names, i. e. even if there exists a matching ENS name consisting of 40 hexadecimal digits, it should never be resolved. Instead, the hexadecimal address should be used directly.
+If using ENS names instead of hexadecimal addresses, the resolution is up to the payer, at any time between receiving the URL and sending the transaction. Hexadecimal addresses always take precedence over ENS names, i.e. even if there exists a matching ENS name consisting of 40 hexadecimal digits, it should never be resolved. Instead, the hexadecimal address should be used directly.
 
-* `symbol` (optional) is the token symbol (STRING) - Defaults to "SYM"
-* `decimals` (optional) is a whole number between 0 and 18 (inclusive) - Defaults to 18
-* `name` (optional) is a more user-friendly name (STRING) for the token, typically the name of the project that generated the tokens - Defaults to the value of symbol
-* `type` (optional) is the type of token (STRING), eg "ERC20". - Defaults to "ERC20"
+1. `symbol` (optional) is the token symbol (STRING) - Defaults to "SYM"
+2. `decimals` (optional) is a whole number between 0 and 18 (inclusive) - Defaults to 18
+3. `name` (optional) is a more user-friendly name (STRING) for the token, typically the name of the project that generated the tokens - Defaults to the value of symbol
+4. `type` (optional) is the type of token (STRING), e.g. "ERC20". - Defaults to "ERC20"
 
 ## Rationale
 The proposed format is chosen to resemble `ethereum:pay` URLs as closely as possible, as both users and application programmers are already familiar with that format. Individuals generating these URLs are free to add and remove arbitrary parameters as they see fit.
 
 ## Compatibility and Versioning
-Future upgrades that are partially or fully incompatible with this proposal must use a prefix other than `token-` that is separated by a dash (`-`) character from whatever follows it, as specified by ERC #831.
+Future upgrades that are partially or fully incompatible with this proposal must use a prefix other than `token_info-` that is separated by a dash (`-`) character from whatever follows it, as specified by ERC #831.
 
 ## Copyright