How to determine binary CE vs random non-CE message

Add some guidance for how to determine when an incoming message is a binary
CE vs some random non-CE message. The same receiver might accept CE and non-CE
messages so we should have an interoperable way for them to know what they're
getting

Signed-off-by: Doug Davis <dug@us.ibm.com>

amqp-protocol-binding.md

@@ -115,6 +115,16 @@ If a receiver detects the CloudEvents media type, but with an event format that
 it cannot handle, for instance `application/cloudevents+avro`, it MAY still
 treat the event as binary and forward it to another party as-is.
 
+When the `content-type` message property is not prefixed with the CloudEvents
+media type, being able to know when the message ought to be attempted to be
+parsed as a CloudEvent can be a challenge. While this specification can not
+mandate that senders do not include any of the CloudEvents message properties
+when the message is not a CloudEvent, it would be reasonable for a receiver
+to assume that if the message has all of the mandatory CloudEvents attributes
+as message properties then it's probably a CloudEvent. However, as with all
+CloudEvent messages, if it does not adhere to all of the normative language of
+this specification then it is not a valid CloudEvent.
+
 ### 3.1. Binary Content Mode
 
 The _binary_ content mode accommodates any shape of event data, and allows for

http-protocol-binding.md

@@ -147,6 +147,16 @@ If a receiver detects the CloudEvents media type, but with an event format that
 it cannot handle, for instance `application/cloudevents+avro`, it MAY still
 treat the event as binary and forward it to another party as-is.
 
+When the `Content-Type` header is not prefixed with the CloudEvents media type,
+being able to know when the message ought to be attempted to be parsed as a
+CloudEvent can be a challenge. While this specification can not mandate that
+senders do not include any of the CloudEvents HTTP headers when the message
+is not a CloudEvent, it would be reasonable for a receiver to assume that if
+the message has all of the mandatory CloudEvents attributes as HTTP headers
+then it's probably a CloudEvent. However, as with all CloudEvent messages, if
+it does not adhere to all of the normative language of this specification
+then it is not a valid CloudEvent.
+
 ### 3.1. Binary Content Mode
 
 The _binary_ content mode accommodates any shape of event data, and allows for

kafka-protocol-binding.md

@@ -117,6 +117,16 @@ event format that it cannot handle, for instance
 `application/cloudevents+avro`, it MAY still treat the event as binary and
 forward it to another party as-is.
 
+When the `content-type` header is not prefixed with the CloudEvents
+media type, being able to know when the message ought to be attempted to be
+parsed as a CloudEvent can be a challenge. While this specification can not
+mandate that senders do not include any of the CloudEvents headers
+when the message is not a CloudEvent, it would be reasonable for a receiver
+to assume that if the message has all of the mandatory CloudEvents attributes
+as headers then it's probably a CloudEvent. However, as with all
+CloudEvent messages, if it does not adhere to all of the normative language of
+this specification then it is not a valid CloudEvent.
+
 If the `content-type` header is not present then the receiver uses
 _structured_ mode with the JSON event format.
 

mqtt-protocol-binding.md

@@ -128,6 +128,16 @@ If a receiver finds a CloudEvents media type as per the above rule, but with an
 event format that it cannot handle, for instance `application/cloudevents+avro`,
 it MAY still treat the event as binary and forward it to another party as-is.
 
+When the `Content Type` property is not prefixed with the CloudEvents
+media type, being able to know when the message ought to be attempted to be
+parsed as a CloudEvent can be a challenge. While this specification can not
+mandate that senders do not include any of the CloudEvents properties
+when the message is not a CloudEvent, it would be reasonable for a receiver
+to assume that if the message has all of the mandatory CloudEvents attributes
+as message properties then it's probably a CloudEvent. However, as with all
+CloudEvent messages, if it does not adhere to all of the normative language of
+this specification then it is not a valid CloudEvent.
+
 With MQTT 3.1.1, the content mode is always _structured_ and the message payload
 MUST use the [JSON event format][json-format].