Sorry, I already wanted to draft a reply last week. I hope it helps.

CloudEvents isn't finished, but we want to ship production software in 2019. In theory, the working group could do a wholesale redesign of the attributes at any time. Can any organization plausibly claim to "Support CloudEvents" at this stage in history? It's not obvious to me how.

Well, an organization can claim to support CloudEvents at a specific version. E.g. Azure supports 0.1 currently.

CloudEvents could consider freezing the field names. I.e. adopt some sort of policy that whereas new attributes may be added, there's a commitment not to change the names of the ones that exist.

The policy (semver) is hidden in here: https://github.com/cloudevents/spec/blob/master/GOVERNANCE.md#release-process-and-versioning (Took me a while to find the place as well 😉)
1.0 will do what you ask for.

Fields in AWS Events not in CloudEvents: region, account, resources.

I'd argue that in CloudEvents lingo, they should be part of the source.
E.g. the (ce-)source is /region/account/resource/(aws-)source

At the very least we could ship libraries that transcode between AWS Events and CloudEvents. Would that be enough to make users happy?

I'd think that would be a good first step. Even better if the transcoding can be enabled at service level (i.e. I can ask S3 to release CloudEvents instead of AWS Events. BTW: This would also be a good place to do the versioning. I could ask S3 to do CE 1.0, 0.3 or (at some point...) 2.0.

If I'm getting you correctly, when you talk about AWS support for CloudEvents, you talk about the events that AWS produces. This is certainly important.
However, at least as important (to me) is that the eventing/messaging products that AWS has natively support CloudEvents.
E.g. for SNS it'd be great if I could filter on CloudEvents attributes (at least the standard ones such as source and types)
It would also be great if SNS supports the HTTP transport binding for publishing and receiving events.

Anyway, AWS producing CloudEvents would already be a great first step!

Eventbridge yeah? Looks like a platform that ought to support the spec, at least, users would be looking for it at some point

@jordo1138 Came here to say the same thing 😉

@timbray Do you have plans to support CloudEvents at EventBridge soon-ish? If not/if later, is it ok if I go ahead and create a proprietary transport?

As for a proprietary transport, the AWS CloudWatch Events format is already documented on that page, and EventBridge is continuing to use it, so I think we're covered. As I said at the top of this thread, I'd like to figure out a good way for AWS to be in the community, and I'm happy the group is converging on a stable 1.0, which will make it easier.

Hey @cneijenhuis , thanks for the note. I believe pretty strongly that once 1.0 gets announced, if it gets any adoption, it'll become difficult to extend and change and further version. I speak from experience as one who is running $BIG_NUMBER events/second through a bus and has $BIG_NUMBER of customers processing them. Nobody wants to do any versioning on this stuff once it's running. Note to self: Ping @clemensv to figure out if Azure's going to migrate from 0.1 to 1.0. If they're not, it might make more sense for us to stick with 0.1.

Interesting points about the value of "source"; at first glance I think I might agree.

@timbray I tend to agree on the versioning.

With Clemens on vacation - I think he mentioned on a call that Azure is planning to support 1.0. I don't know if they'll migrate, or if they'll support both side-by-side for some time.

As for a proprietary transport, the AWS CloudWatch Events format is already documented on that page

Are you referring to https://github.com/cloudevents/spec/blob/master/adapters/aws-s3.md ?

I'll try to find some time to get some hands-on experience with EventBridge at the end of next week (independently of CloudEvents). My gut-feeling is that what we've defined as an adapter in https://github.com/cloudevents/spec/blob/master/adapters/aws-s3.md works for AWS-produced CloudWatch Event -> CloudEvent, but doesn't scale to Any CloudEvent -> CloudWatch Event -> CloudEvent (with the original and the "transported" CloudEvent being unchanged)... but maybe I'm simply looking at the wrong file?

Thanks! That doesn't define a mapping from/to CloudEvents, though - which is what I'd be interested in, but I may just be too impatient 😉

@timbray I would like to highlight what @cneijenhuis said about AWS support - it would be good to define how to use CloudEvents with AWS services like SNS/SQS.

1. whether you prefer to add support for HTTP transport binding (https://github.com/cloudevents/spec/blob/master/http-transport-binding.md#314-examples), e.g. as dedicated SNS endpoint to publish messages in that form and then to support it for HTTP endpoint delivery
2. or just write down SNS transport binding, e.g. similar to https://github.com/cloudevents/spec/blob/master/kafka-transport-binding.md#325-example

@timbray is there anything we need to do on this one? Should we close it?

I've reopened the issue, but I'm wondering what the action would be for the CE group. This feels more like an AWS issue than a CE issue at this point. Unless there's some collaboration we need to help kick-off??

Thx. ACK, I might get back to you at some point with some advice, but currently there's no AI on the CE side. Let's keep this open for some time and close if there's no further interactions from user(s).

Now that CE is officially "graduated", maybe this can be looked at again

Now that CE is officially "graduated", maybe this can be looked at again

@j-fulbright a small step, but we're moving into the right direction: https://aws.amazon.com/about-aws/whats-new/2024/02/amazon-eventbridge-api-destinations-content-type-header-customization/

Happy to discuss the topic in the greater AWS (EventBridge) scheme. Feel free to connect.

AWS EventBridge now supports CE: https://aws.amazon.com/about-aws/whats-new/2024/02/amazon-eventbridge-api-destinations-content-type-header-customization/

I'm going to propose that we close this issue on tomorrow's call... if anyone objects please speak up here or on the call

FWIW, we also wrote a blog post to explain the current integration possibilities: https://aws.amazon.com/blogs/compute/sending-and-receiving-cloudevents-with-amazon-eventbridge/

Hey Michael,

Under "Publishing CloudEvents using Amazon EventBridge", is the value of the data.dataschema field really right? Why go through the console?

Hey Michael,

Hi Tim, great to see you around!

Under "Publishing CloudEvents using Amazon EventBridge", is the value of the data.dataschema field really right? Why go through the console?

Good catch! Let me file with the author and get this fixed!

@timbray just FYI:

@duglin Um sorry, I see you were trying to comment on my blog. For some reason, my anti-spam system decided erroneously that you were a Bad Person, and when it does that it retreats behind a cloud of almost-plausible error messages - refresh https://www.tbray.org/atompub/ouch a few times to see the effect. Amazingly effective at deterring spammers. My apologies on behalf of my anti-spam system; its memory is only 15 minutes long, so if you try again you'll probably get through.

Agreed to CWNA on the 3/21 call

@duglin Um sorry, I see you were trying to comment on my blog. For some reason, my anti-spam system decided erroneously that you were a Bad Person, and when it does that it retreats behind a cloud of almost-plausible error messages - refresh https://www.tbray.org/atompub/ouch a few times to see the effect. Amazingly effective at deterring spammers. My apologies on behalf of my anti-spam system; its memory is only 15 minutes long, so if you try again you'll probably get through.

I do enjoy reading them - still doesn't like me:

any way to know why? I'm leaving "web address" blank

@duglin This is probably not of general interest but I would like to figure out what's going wrong. Maybe shoot me an email, same handle at gmail, and I can ask a couple questions?