Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to determine binary CE vs random non-CE message #577

Merged
merged 1 commit into from
Mar 26, 2020
+40 −0
Merged

How to determine binary CE vs random non-CE message #577

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions amqp-protocol-binding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
10 changes: 10 additions & 0 deletions http-protocol-binding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Member

@slinkydeveloper slinkydeveloper Mar 5, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if it doesn't have all of the mandatory attributes? Should be considered non-event or not valid event? Maybe is it more convenient to state: if a request has the spec version attribute, then it should be handled as event (even not valid one)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the incoming message doesn't have all (4) required attributes then it is not a valid CE. While SDKs might choose to treat it as a CE but flag it as "incomplete", that is there choice. But from a spec perspective I don't think we can say anything other than all 4 are required to be a CE, anything else isn't a CE.

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
Expand Down
10 changes: 10 additions & 0 deletions kafka-protocol-binding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
10 changes: 10 additions & 0 deletions mqtt-protocol-binding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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].

Expand Down