Why does the HTTP binding for batch require the same spec version for all events in the batch?

[jskeet]

From https://github.com/cloudevents/spec/blob/v1.0.1/http-protocol-binding.md#33-batched-content-mode:

All batched CloudEvents MUST have the same specversion attribute

Shouldn't this be up to the event format to decide? (It would be reasonable for a batch event format to dictate that, or to leave it open... but I don't see why the HTTP binding should care.)

If we want to keep this, I think we should provide some justification in the spec.

[cneijenhuis]

If I'm not mistaken, the HTTP Binding is versioned alongside with the spec. So if we'd make a change to the HTTP Binding in version x.y, and the body would contain events of both x.y-1 and x.y, it wouldn't be clear what version of the HTTP Binding to use.

Also (and maybe more importantly) I think for the consumers it's much simpler if it's all fixed. E.g. I have a single JSON Schema I can use to validate or parse the input. It's certainly not impossible to handle that case, but it seems to add a lot of accidental complexity. Do you think that'd be worth it?

[jskeet]

It's certainly not impossible to handle that case, but it seems to add a lot of accidental complexity. Do you think that'd be worth it?

From an SDK perspective I expect the validation of "only one spec version" to add complexity which wouldn't be present otherwise, to be honest.

It's not clear to me what a different spec version will actually mean, or when we'd release one. We're currently on 1.0.1, but it's only 1.0 as an attribute value... when would we go for 1.1, and would we really expect that to break anything if a mixture of 1.0 and 1.1 CloudEvents were included in the same HTTP message?

It's always hard to reason about whether versioning decisions are good or not until we've got evidence, unfortunately... while we don't know what can change, we can't tell whether it makes sense to prohibit mixing or not.

Personally I think it would make more sense for the individual batch format to decide whether or not to allow mixing, not the HTTP binding. The HTTP binding is really just saying "The content contains the batch" - the only header that's relevant is the content-type.

[cneijenhuis]

We had/have 0.1, and (having implemented both) I don't think it's a good idea to mix it with 1.0 😉

[jskeet]

Pre-1.0, I think that made sense, but I suspect we'll be significantly more careful having reached 1.0. It might make sense for the 2.0 version of the HTTP binding to prohibit mixing different major version numbers (which we'll only know when we get there) but I suspect that if we have a 1.1 with some new optional but standardized attributes (for example), it will be pointlessly restrictive to prohibit mixing 1.0 and 1.1... and again, I'd suggest that should be up to the batch format rather than the HTTP binding.

Anyway, let's talk about it more in the working group.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.