diff --git a/http-transport-binding.md b/http-transport-binding.md
index 637ee3d01..aee84c373 100644
--- a/http-transport-binding.md
+++ b/http-transport-binding.md
@@ -168,18 +168,14 @@ Examples:
     * `eventID` maps to `CE-EventID`
     * `cloudEventsVersion` maps to `CE-CloudEventsVersion`
 
-For the `extensions` attribute, each entry of the `extensions` map
-is mapped to a separate HTTP header. The `extensions` attribute itself is
-not mapped to a header.
-
-The naming convention for the `extensions` header mapping of attributes is:
-
-    * Each map entry name MUST be prefixed with "CE-X-"
+For other attributes not explicitly defined in the [spec](spec.md), each
+attribute will be mapped to a separate HTTP header in the same way as the
+predefined attributes.
 
 Examples:
 
-    * `example` maps to `CE-X-Example`
-    * `testExtension` maps to `CE-X-TestExtension`
+    * `example` maps to `CE-Example`
+    * `testExtension` maps to `CE-TestExtension`
 
 Note: per the [HTTP](https://tools.ietf.org/html/rfc7230#section-3.2)
 specification, header names are case-insensitive.
diff --git a/json-format.md b/json-format.md
index af0e97cb6..24fec0e5d 100644
--- a/json-format.md
+++ b/json-format.md
@@ -87,7 +87,6 @@ The following table shows exemplary mappings:
 | eventID            | String   | "1234-1234-1234"
 | eventTime          | Timestamp| "2018-04-05T17:31:00Z"
 | contentType        | String   | "application/json"
-| extensions         | Map      | { "extA" : "vA", "extB", "vB" }
 | data               | String   | "<much wow=\"xml\"/>"
 | data               | Binary   | "Q2xvdWRFdmVudHM="
 | data               | Map      | { "objA" : "vA", "objB", "vB" }
@@ -142,10 +141,8 @@ Example event with `String`-valued `data`:
     "source" : "/mycontext",
     "eventID" : "A234-1234-1234",
     "eventTime" : "2018-04-05T17:31:00Z",
-    "extensions" : {
-      "comExampleExtension" : "value"
-    },
     "contentType" : "text/xml",
+    "comExampleExtension" : "value",
     "data" : "<much wow=\"xml\"/>"
 }
 ```
@@ -160,10 +157,8 @@ Example event with `Binary`-valued data
     "source" : "/mycontext",
     "eventID" : "B234-1234-1234",
     "eventTime" : "2018-04-05T17:31:00Z",
-    "extensions" : {
-      "comExampleExtension" : "value"
-    },
     "contentType" : "application/vnd.apache.thrift.binary",
+    "comExampleExtension" : "value",
     "data" : "... base64 encoded string ..."
 }
 ```
@@ -179,10 +174,8 @@ a `Map` or [JSON data](#31-special-handling-of-the-data-attribute) data:
     "source" : "/mycontext",
     "eventID" : "C234-1234-1234",
     "eventTime" : "2018-04-05T17:31:00Z",
-    "extensions" : {
-      "comExampleExtension" : "value"
-    },
     "contentType" : "application/json",
+    "comExampleExtension" : "value",
     "data" : {
         "appinfoA" : "abc",
         "appinfoB" : 123,
diff --git a/spec.md b/spec.md
index 2b33daab0..2d1c8762d 100644
--- a/spec.md
+++ b/spec.md
@@ -298,6 +298,12 @@ attributes and the event data will be materialized. For example, in the case
 of a JSON serialization, the context attributes and the event data might
 both appear within the same JSON object.
 
+Note that the enumeration of the following attributes SHALL NOT be construed
+as an enumeration of all allowed context attributes; additional producer or
+middleware extensions (of any type) may be stored on attribute names not
+defined below. It is expected that this mechanism will be used to test new
+attributes before standardizing.
+
 ### eventType
 * Type: `String`
 * Description: Type of occurrence which has happened. Often this
@@ -372,20 +378,6 @@ both appear within the same JSON object.
     [RFC 2046](https://tools.ietf.org/html/rfc2046)
 * For Media Type examples see [IANA Media Types](http://www.iana.org/assignments/media-types/media-types.xhtml)
 
-### extensions
-* Type: `Map`
-* Description: This is for additional metadata and this does not have a
-  mandated structure. This enables a place for custom fields a producer or
-  middleware might want to include and provides a place to test metadata before
-  adding them to the CloudEvents specification.
-  See the [Extensions](extensions.md) document for a list of possible
-  properties.
-* Constraints:
-  * OPTIONAL
-  * If present, MUST contain at least one entry
-* Examples:
-  * authorization data
-
 ## Data Attribute
 
 As defined by the term [Data](#data), CloudEvents MAY include domain-specific