Clarify interoperability of extensions (cloudevents#508)

Minor clarification to #type-system.

Deleted confusing and non-normative section on extension serialization.
The discussion of "serialization locations" and "general patterns of extension
serialization" is specific to the HTTP, AMQP and JSON bindings/formats and may
not apply to future bindings/formats.

An event serialization MUST describe how to encode/decode an abstract event
correctly, that's all. This spec should not constrain what that looks like on
the wire. It's up to other specs (HTTP, AMQP etc.) to do that.

Signed-off-by: Alan Conway <aconway@redhat.com>

spec.md

@@ -210,13 +210,15 @@ string-encoding for each type that MUST be supported by all implementations.
 - `Timestamp` - Date and time expression using the Gregorian Calendar.
   - String encoding: [RFC 3339](https://tools.ietf.org/html/rfc3339).
 
-All context attributes MUST be of scalar type (e.g. string, integer) that have a
-string-encoding defined. They MUST NOT be of complex type (e.g. structures,
-map).
+All context attribute values MUST be of one of the types listed above.
 
-A strongly-typed programming model that represents a CloudEvent or any extension
-MUST be able to convert from and to the canonical string-encoding to the
-runtime/language native type that best corresponds to the abstract type.
+A programming model that represents a CloudEvent or any extension MUST be able
+to convert between the canonical string-encoding and the runtime/language native
+type that best corresponds to the abstract type.
+
+Attribute values MAY be presented as native types or canonical strings.
+Extension attribute values presented as strings MUST use the canonical
+string-encoding to avoid potential ambiguity with other string encodings.
 
 For example, the `time` attribute might be represented by the language's native
 _datetime_ type in a given implementation, but it MUST be settable providing an
@@ -235,7 +237,7 @@ language/runtime types at the producer and consumer ends, and never materialize
 as a string.
 
 The choice of serialization mechanism will determine how the context attributes
-and the event data will be materialized. For example, in the case of a JSON
+and the event data will be serialized. For example, in the case of a JSON
 serialization, the context attributes and the event data might both appear
 within the same JSON object.
 
@@ -438,27 +440,31 @@ extension authors SHOULD check the
 extensions - not just for possible name conflicts but for extensions that might
 be of interest.
 
-Each specification that defines how to serialize a CloudEvent will define how
-extension attributes will appear.
+#### Guidance for binding specifications
+
+Each specification that defines how to serialize a CloudEvent MUST define how to
+serialize extension attributes. The following are some guidelines.
 
-Extension attribtue MUST be serialized using the same general pattern as all
-CloudEvents context attributes. For example, in binary HTTP, that means they
-MUST appear as HTTP headers with the `ce-` prefix. The specification of an
-attribute MAY define a secondary serialization where the data is duplicated in
-some other location within the message.
+Unless there is reason to do otherwise, extension attributes are serialized in
+the same way as standard attributes. For example the HTTP binding encodes both
+as HTTP headers with a "ce-" prefix. There can be exceptions, for example the
+`datacontentype` attribute is stored in the standard HTTP `Content-Type` header
+so that it is visible to other HTTP processes.
 
-In cases where a secondary serialization is defined, the extension specification
-MUST also state what a receiver of the CloudEvent is to do if the data differs
-between those two serialization locations. Additionally, senders need to be
-prepared for intermediaries, and receivers, to not know about their extension
-and therefore the specialized serialization version will most likely not be
-processed as a CloudEvent extension attribute.
+A binding MAY serialize the same attribute value to multiple locations in a
+message. For example HTTP tracing repeats some attribute values in "ce-" headers
+and in other headers examined by tracing agents. Such bindings MUST specify how
+receivers should handle conflicting values for duplicated attributes, and how
+senders should format messages to ensure that the desired attribute value is
+transmitted.
 
 Many protocols support the ability for senders to include additonal metadata,
 for example as HTTP headers. While a CloudEvents receiver is not mandated to
 process and pass them along, it is RECOMMENDED that they do so via some
 mechanism that makes it clear they are non-CloudEvents metadata.
 
+#### Example
+
 Here is an example that illustrates the need for additional attributes. In many
 IoT and enterprise use cases, an event could be used in a serverless application
 that performs actions across multiple types of events. To support such use