From b259901030b2e6471d9fe2d4e4f1ea8ea4322356 Mon Sep 17 00:00:00 2001 From: Doug Davis Date: Sun, 1 Mar 2020 13:28:31 +0000 Subject: [PATCH] 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 --- amqp-protocol-binding.md | 10 ++++++++++ http-protocol-binding.md | 10 ++++++++++ kafka-protocol-binding.md | 10 ++++++++++ mqtt-protocol-binding.md | 10 ++++++++++ 4 files changed, 40 insertions(+) diff --git a/amqp-protocol-binding.md b/amqp-protocol-binding.md index 65a22a2a8..c04790d63 100644 --- a/amqp-protocol-binding.md +++ b/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 diff --git a/http-protocol-binding.md b/http-protocol-binding.md index b481e66c5..92bcc9284 100644 --- a/http-protocol-binding.md +++ b/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 diff --git a/kafka-protocol-binding.md b/kafka-protocol-binding.md index 743dc063f..4a73b0b47 100644 --- a/kafka-protocol-binding.md +++ b/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. diff --git a/mqtt-protocol-binding.md b/mqtt-protocol-binding.md index 47ea189fe..db3234eb7 100644 --- a/mqtt-protocol-binding.md +++ b/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].