mention all required attrs and shorten a bit

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

http-protocol-binding.md

@@ -148,15 +148,14 @@ 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 distinguish between a _binary_ CloudEvent and a non-CloudEvent
-message can be a challenge. While this specification can not mandate that
+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 a reasonable assumption for a receiver
-to assume that if the message has the `ce-specversion` HTTP header then
-it is a CloudEvent. Note, that the presence of this header does not guarantee
-that the message is _binary_ instead of _structured_ since this specification
-allows for _structured_ CloudEvent metadata to be copied into HTTP headers,
-so the `Content-Type` header would still need to be used for that.
+is not a CloudEvent, it would be a reasonable for a receiver to assume that if
+the message has all of the mandatory CloudEvents attributes as HTTP headers
+then it 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