Automatically merged updates to draft EIP(s) 634 (#3226)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft, Review, or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-634.md

@@ -26,6 +26,7 @@ associate arbitrary key-value text.
 ## Specification
 
 ### Resolver Profile
+
 A new resolver interface is defined, consisting of the following method:
 
     function text(bytes32 node, string key) constant returns (string text);
@@ -36,36 +37,80 @@ The `text` data may be any arbitrary UTF-8 string. If the key is not present, th
 must be returned.
 
 
-### Initial Recommended Keys
+### Global Keys
 
-Keys must be made up of lowercase letters, numbers and the hyphen (-). Vendor specific
-services must be prefixed with `vnd.`.
+Global Keys must be made up of lowercase letters, numbers and
+the hyphen (-).
 
-- **email** - an e-mail address
-- **url** - a URL
 - **avatar** - a URL to an image used as an avatar or logo
 - **description** - A description of the name
-- **notice** - A notice regarding this name; 
+- **display** - a canonical display name for the ENS name; this MUST match the ENS name when its case is folded, and clients should ignore this value if it does not (e.g. `"ricmoo.eth"` could set this to `"RicMoo.eth"`)
+- **email** - an e-mail address
 - **keywords** - A list of comma-separated keywords, ordered by most significant first; clients that interpresent this field may choose a threshold beyond which to ignore
+- **mail** - A physical mailing address
+- **notice** - A notice regarding this name
+- **location** - A generic location (e.g. `"Toronto, Canada"`)
+- **phone** - A phone number as an [E.164](https://en.wikipedia.org/wiki/E.164) string
+- **url** - a website URL
 
-- **vnd.github** - a GitHub username
-- **vnd.peepeth** - a peepeth username
-- **vnd.twitter** - a twitter username
+### Service Keys
+
+Service Keys must be made up of a *reverse dot notation* for
+a namespace which the service owns, for example, DNS names
+(e.g. `.com`, `.io`, etc) or ENS name (i.e. `.eth`). Service
+Keys must contain at least one dot.
+
+This allows new services to start using their own keys without
+worrying about colliding with existing services and also means
+new services do not need to update this document.
+
+The following services are common, which is why recommendations are
+provided here, but ideally a service would declare its own key.
+
+- **com.github** - a GitHub username
+- **com.peepeth** - a Peepeth username
+- **com.linkedin** - a LinkedIn username
+- **com.twitter** - a Twitter username
+- **io.keybase** - a Keybase username
+- **org.telegram** - a Telegram username
+
+This technique also allows for a service owner to specify a hierarchy
+for their keys, such as:
+
+- **com.example.users**
+- **com.example.groups**
+- **com.example.groups.public**
+- **com.example.groups.private**
 
 
-Usernames SHOULD not be prefixed with the @ symbol.
+### Legacy Keys
+
+The following keys were specified in earlier versions of this EIP,
+which is still in draft.
+
+Their use is not likely very wide, but applications attempting
+maximal compatibility may wish to query these keys as a fallback
+if the above replacement keys fail.
+
+- **vnd.github** - a GitHub username (renamed to `com.github`)
+- **vnd.peepeth** - a peepeth username (renamced to `com.peepeth`)
+- **vnd.twitter** - a twitter username (renamed to `com.twitter`)
+
 
 ## Rationale
 
 ### Application-specific vs general-purpose record types
+
 Rather than define a large number of specific record types (each for generally human-readable
 data) such as `url` and `email`, we follow an adapted model of DNS's `TXT` records, which allow
 for a general keys and values, allowing future extension without adjusting the resolver, while
 allowing applications to use custom keys for their own purposes.
 
+
 ## Backwards Compatibility
 Not applicable.
 
+
 ## Test Cases
 TBD