Rename example extension IDs and provide guidance about dot-notation

In response to Vijay's note about extension names[1], I've renamed the example
extensions (correcting a CBOR mismatch in the process). I also noted in section
7.1, Extension identifiers, that  "Use of dot-separated notation here does not
imply an object hierarchy.", and provided a counterexample of a differently-
separated, versioned id: `mycompany- myextension_v01`. None of the pre-defined
extensions were modified.

1) https://lists.w3.org/Archives/Public/public-webauthn/2016Jul/0046.html

index.bs

@@ -1410,10 +1410,12 @@ authenticator. Since all extensions are optional, this will not cause a function
 Extensions are identified by a string, chosen by the extension author. Extension identifiers should aim to be globally unique,
 e.g., by using reverse domain-name of the defining entity such as `com.example.webauthn.myextension`.
 
+Note: Use of dot-separated notation here does not imply an object hierarchy.
+
 Extensions that may exist in multiple versions should take care to include a version in their identifier. In effect, different
-versions are thus treated as different extensions.
+versions are thus treated as different extensions, e.g., `mycompany-myextension_v01`
 
-Extensions defined in this specification use a fixed prefix of `webauthn` for the extension identifiers. This prefix should not
+Extensions defined in this specification use a fixed prefix of `webauthn.` for the extension identifiers. This prefix should not
 be used for extensions not defined by the W3C.
 
 
@@ -1442,7 +1444,7 @@ A [RP] simultaneously requests the use of an extension and sets its client argum
 
 <pre class="example highlight">
     var assertionPromise = credentials.getAssertion(..., /* extensions */ {
-        "com.example.webauthn.foobar": 42
+        "webauthn-example.foobar": 42
     });
 </pre>
 
@@ -1492,15 +1494,15 @@ authenticator data value of each extension as the value.
 To illustrate the requirements above, consider a hypothetical extension "Geo". This extension, if supported, lets both clients
 and authenticators embed their geolocation in assertions.
 
-The extension identifier is chosen as `com.example.webauthn.geo`. The client argument is the constant value `true`, since the
+The extension identifier is chosen as `webauthn-example.geo`. The client argument is the constant value `true`, since the
 extension does not require the <a>[RP]</a> to pass any particular information to the client, other than that it requests the use
 of the extension. The [RP] sets this value in its request for an assertion:
 
 <pre class="highlight">
     var assertionPromise =
         credentials.getAssertion("SGFuIFNvbG8gc2hvdCBmaXJzdC4",
             {}, /* Empty filter */
-            { 'com.example.webauthn.geo': true });
+            { 'webauthn-example.geo': true });
 </pre>
 
 The extension defines the additional client data to be the client's location, if known, as a GeoJSON [[GeoJSON]] point. The
@@ -1510,7 +1512,7 @@ client constructs the following client data:
     {
         ...,
         'extensions': {
-            'com.example.webauthn.geo': {
+            'webauthn-example.geo': {
                 'type': 'Point',
                 'coordinates': [65.059962, -13.993041]
             }
@@ -1529,8 +1531,10 @@ authenticator does this by including it in the `authenticatorData`. As an exampl
     81 (hex)                                    -- Flags, ED and TUP both set.
     20 05 58 1F                                 -- Signature counter
     A1                                          -- CBOR map of one element
-        6C                                      -- Key 1: CBOR text string of 12 bytes
-            77 65 62 61 75 74 68 6E 2E 67 65 6F -- "webauthn.geo" UTF-8 string
+        74                                      -- Key 1: CBOR text string of 20 bytes
+            77 65 62 61 75 74 68 6e 2d 65 78
+            61 6d 70 6c 65 2e 67 65 6f          -- "webauthn-example.geo" UTF-8 string
+
         82                                      -- Value 1: CBOR array of two elements
             FA 42 82 1E B3                      -- Element 1: Latitude as CBOR encoded float
             FA C1 5F E3 7F                      -- Element 2: Longitude as CBOR encoded float