Integration with CloudEvents

[mlagally]

@benfrancis suggested

Remove the sentence: "Depending on the deployment scenarios and integration requirements for existing consumers, it may be required to use specific data payload formats (e.g. Cloud Events)." (The HTTP Webhook Profile needs to define a single payload format for events in order to guarantee out-of-the-box interoperability. Compatibility with existing consumers should be a non-goal.)

[rektide]

I'd love if we could align with CloudEvents, given that it has taken over.

The change here makes me think we are removing any reference/mention of CloudEvents? Or is this topic an open topic, a suggestion/desire to better integrate?

[benfrancis]

@rektide Please see #126 and #258 for some of the extensive discussions on this topic. There is significant disagreement over whether CloudEvents provides a good choice of payload format for the HTTP Webhook Profile.

The main concerns being:

1. It is not a good fit for the WoT information model
2. It adds a lot of redundant metadata to every event payload which is already available in a Thing Description
3. It is not prescriptive enough to guarantee interoperability
4. It is not a formal standard, and therefore can not be a dependency of a W3C Recommendation

Alternatives include defining our own payload format, or no payload format at all.

There is a proposal for a CloudEvents Payload Binding as a better option for integrating with existing systems which use CloudEvents.

[benfrancis]

@rektide Out of interest, what are you using CloudEvents for, and what do you hope to use the HTTP Webhook Profile for?