Event Producers should have single required encoding and transport

[derekcollison]

Event-based systems, especially one like CloudEvents that strive for interoperability, need to define a single encoding and transport for all producers. This gives the best interoperability for all consumers from any cloud provider or ecosystem.

For instance, say the spec requires JSON and HTTP 1.1/2 (Although some challenges with true push using HTTP) for all producers. Any consumer in any environment could consumer events in a singular fashion.

Note this would not preclude specialized consumers and gateways or multi-headed producers that utilize alternative encodings or transports.

Any provider could produce events in different encodings and transports, but to be compliant they must produce via HTTP and JSON (Or whatever the chosen encoding and transport shall be).

For instance, Google may choose to honor the spec and publish all events via the standard, but also publish the same events in parallel via gRPC and ProtoBufs. These alternatives could be referenced in the spec based on status and use in the broader ecosystem.

[clemensv]

We already have a conformance rule in the main spec that states that all implementations must support the JSON event format.

That leaves whether we need a compliance rule that all conformant producer implementations must support HTTPS.

That might be tough on the low end of the IoT spectrum where people are greedy with adding transport stacks based on kilobytes of library footprint. If a device generally only communicates via MQTT and its events shared with other systems are always routed through a gateway, does it need to add an HTTPS stack purely for CloudEvents conformance in spite of the consumers consuming its events via a middleware that might speak HTTPS on its behalf?

Would it be sufficient to say that
a) all consumer implementations MUST support JSON
b) all producers MUST be configurable to emit JSON
c) all producers SHOULD be configurable to send to an HTTPS endpoint

[derekcollison]

I think a common transport supported by all spec compliant producers should be required. Notice I do not say consumers, they are free to consume how they best want to and may be specific to multi-headed producers, gateways or repeaters that offer other transports and encodings. The event format is a great start, but without a default required transport the end user, usually a consumer, who is trying to consume events from multiple providers or ecosystems will be frustrated IMO.

Also I mentioned HTTP since it fits the least common denominator, but do not believe it is a good match for push based high volume systems.

[jdstuart]

@derekcollison . I would disagree and the argument can easily be turned around as well. The producer that operates within an organization where something like MQTT has been chosen as transport will be frustrated to have to support HTTP when it will never be used.

I believe the minimum supported transport falls outside the remit of CloudEvents, but CloudEvents definites if HTTP is chosen, then this is how is done. If MQTT is chosen, here's the specification for that transport layer.

Forcing a minimum transport layer can be good for consumers, but in my opinions, producers won't implement it cause it adds additional complexity. I know I certainly won't add support for a transport layer I know my consumers will never listen on.

[derekcollison]

You are referencing legacy producers, and IMO they can utilize a gateway to be compliant both with the payload and transport. Again if people want to consume directly from the legacy producer they can do so like they do today, but to be compliant they would need to have the gateway.

[JemDay]

I would tend to agree with @jdstuart, as soon as you start mandating particular transports you run the risk of disenfranchising a whole bunch of potential users.

[duglin]

All - please think about and comment on this one. We need to decide what to do with this before v1.0

[duglin]

@derekcollison any more thoughts on this one? Do you still want to push for this? If so, would you be willing to talk to this on our next call?

just my 2 cents... I've been thinking more and more that we shouldn't necessarily mandate one particular transport but we should mandate "binary" support. Meaning "structured" would be optional. I say this because I really like the idea that existing event flows don't really need to change much other than to add 4 more bits of metadata (our 4 required attributes). That seems like a pretty minimal bar for support. I know this doesn't address what I think you were looking for, which is interop at the transport level by mandating everyone support at least one common one, but that seems like a pretty high bar since some folks just don't want (or can't) to use http. But it is a nice goal :-)

[derekcollison]

I can understand both sides. I think orgs will define a standard transport for their implementation. I also believe they will continue to push for transport agnostic event handlers (e.g. serverless). With that they may need to understand the encoding, but maybe not. Same layer that hides the transport could hide encoding and deliver the structure to the application directly.

I think the properties and semantics of the events in a broad sense are most important. Will close this issue.