From 4738c57c2c7c20c1bafd6901826bdbb0e5d7c6e3 Mon Sep 17 00:00:00 2001 From: Clemens Vasters Date: Tue, 26 Jun 2018 19:04:25 +0200 Subject: [PATCH 1/4] Qualifying-protocols-and-encodings.md Signed-off-by: Clemens Vasters --- note-qualifying-protocols-and-encodings.md | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 note-qualifying-protocols-and-encodings.md diff --git a/note-qualifying-protocols-and-encodings.md b/note-qualifying-protocols-and-encodings.md new file mode 100644 index 000000000..a67f3b91a --- /dev/null +++ b/note-qualifying-protocols-and-encodings.md @@ -0,0 +1,47 @@ +# Qualifying Protocols and Encodings + +The explicit goal of the CloudEvents effort, as expressed in the specification, is +"describing event data in a common way" and "to define interoperability of event +systems that allow services to produce or consume events, where the producer and +consumer can be developed and deployed independently". + +The foundation for such interoperability are open data formats and open protocols, +with CloudEvents aiming to provide such an open data format and projections of +its data format onto commonly used protocols and with commonly used encodings. + +While each software or service product and project can obviously make its own +choices about which form of communication it prefers, its unquestionable that +a proprietary protocol that is private to such a product or project does not +further the goal of broad interoperability across producers and consumers of +events. + +Especially in the area of messaging and eventing, the industry has made significant +progress in the last decade in developing a robust and broadly supported protocol +foundation, like HTTP 1.1 and HTTP/2 as well as WebSockets or events on the web, +or MQTT and AMQP for connection-oriented messaging and telemetry transfers. + +Some widely used protocols have become de-facto standards emerging out of strong +ecosystems of top-level multi-company consortia projects, such as Apache Kafka, +and largely in parallel to the evolution of the aforementioned standards stacks. + +The CloudEvents effort shall not become a vehicle to even implicitly endorse +or promote project- or product-proprietary protocols, because that were +counterproductive towards CloudEvents' original goals. + +For a protocol or encoding to qualify for a core CloudEvents event format or +protocol binding, the protocol must either have formal status as a standard +with a widely-recognized multi-vendor protocol standardization body (W3C, IETF, +OASIS, OMG), or in the case of ecosystem protocols, it must have "de-facto standard" +status for its ecosystem category, comparable to Apache Kafka. + +Aside from formal status, a key criterion for whether a protocol or encoding shall +qualify for a core CloudEvents event format or transport binding is whether the +working group agrees that the specification will be of sustained practical benefit +for any party that is unrelated to the product or project from which the protocol +or encoding emerged. A base requirement for this is that the protocol or encoding +is defined in a fashion that allows alternate implementations independent of the +product or project's code. + +All other protocol and encoding formats for CloudEvents are welcome to be included +in a list pointing to the CloudEvents binding information in the respective +project's own public repository or site. From aafc43146e4fddc7d094ec2dae338135dfd2f837 Mon Sep 17 00:00:00 2001 From: Clemens Vasters Date: Wed, 15 Aug 2018 07:37:30 -0700 Subject: [PATCH 2/4] updating per discussion in the PR Signed-off-by: Clemens Vasters --- note-qualifying-protocols-and-encodings.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/note-qualifying-protocols-and-encodings.md b/note-qualifying-protocols-and-encodings.md index a67f3b91a..ed8915fa1 100644 --- a/note-qualifying-protocols-and-encodings.md +++ b/note-qualifying-protocols-and-encodings.md @@ -25,14 +25,19 @@ ecosystems of top-level multi-company consortia projects, such as Apache Kafka, and largely in parallel to the evolution of the aforementioned standards stacks. The CloudEvents effort shall not become a vehicle to even implicitly endorse -or promote project- or product-proprietary protocols, because that were +or promote project- or product-proprietary protocols, because that would be counterproductive towards CloudEvents' original goals. For a protocol or encoding to qualify for a core CloudEvents event format or -protocol binding, the protocol must either have formal status as a standard -with a widely-recognized multi-vendor protocol standardization body (W3C, IETF, -OASIS, OMG), or in the case of ecosystem protocols, it must have "de-facto standard" -status for its ecosystem category, comparable to Apache Kafka. +protocol binding, it must belong to either one of the following categories: + +- The protocol has a formal status as a standard with a widely-recognized + multi-vendor protocol standardization body (e.g. W3C, IETF, OASIS, ISO) +- The protocol has a "de-facto standard" status for its ecosystem category, + which means it is used so widely that it is considered a standard for a + given application. Practically, we would like to see at least one open + source implementation and at least a dozen independent vendors using it + in their products/services. Aside from formal status, a key criterion for whether a protocol or encoding shall qualify for a core CloudEvents event format or transport binding is whether the From 4d72b608d178532855b7934b390910cda8a58cef Mon Sep 17 00:00:00 2001 From: Clemens Vasters Date: Thu, 16 Aug 2018 06:04:40 -0700 Subject: [PATCH 3/4] Adding open source organization clause for equivalence with protocol standards org clause Signed-off-by: Clemens Vasters --- note-qualifying-protocols-and-encodings.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/note-qualifying-protocols-and-encodings.md b/note-qualifying-protocols-and-encodings.md index ed8915fa1..98a257557 100644 --- a/note-qualifying-protocols-and-encodings.md +++ b/note-qualifying-protocols-and-encodings.md @@ -36,8 +36,9 @@ protocol binding, it must belong to either one of the following categories: - The protocol has a "de-facto standard" status for its ecosystem category, which means it is used so widely that it is considered a standard for a given application. Practically, we would like to see at least one open - source implementation and at least a dozen independent vendors using it - in their products/services. + source implementation under the umbrella of a vendor-neutral open-source + organization (e.g. Apache, Eclipse, CNCF, .NET Foundation) and at least + a dozen independent vendors using it in their products/services. Aside from formal status, a key criterion for whether a protocol or encoding shall qualify for a core CloudEvents event format or transport binding is whether the From 62dfff57960f07f1bb7ccafb1de96e5dc12e2705 Mon Sep 17 00:00:00 2001 From: Doug Davis Date: Thu, 16 Aug 2018 12:35:03 -0700 Subject: [PATCH 4/4] move into the primer Signed-off-by: Doug Davis --- note-qualifying-protocols-and-encodings.md | 53 -------------------- primer.md | 57 ++++++++++++++++++++++ 2 files changed, 57 insertions(+), 53 deletions(-) delete mode 100644 note-qualifying-protocols-and-encodings.md diff --git a/note-qualifying-protocols-and-encodings.md b/note-qualifying-protocols-and-encodings.md deleted file mode 100644 index 98a257557..000000000 --- a/note-qualifying-protocols-and-encodings.md +++ /dev/null @@ -1,53 +0,0 @@ -# Qualifying Protocols and Encodings - -The explicit goal of the CloudEvents effort, as expressed in the specification, is -"describing event data in a common way" and "to define interoperability of event -systems that allow services to produce or consume events, where the producer and -consumer can be developed and deployed independently". - -The foundation for such interoperability are open data formats and open protocols, -with CloudEvents aiming to provide such an open data format and projections of -its data format onto commonly used protocols and with commonly used encodings. - -While each software or service product and project can obviously make its own -choices about which form of communication it prefers, its unquestionable that -a proprietary protocol that is private to such a product or project does not -further the goal of broad interoperability across producers and consumers of -events. - -Especially in the area of messaging and eventing, the industry has made significant -progress in the last decade in developing a robust and broadly supported protocol -foundation, like HTTP 1.1 and HTTP/2 as well as WebSockets or events on the web, -or MQTT and AMQP for connection-oriented messaging and telemetry transfers. - -Some widely used protocols have become de-facto standards emerging out of strong -ecosystems of top-level multi-company consortia projects, such as Apache Kafka, -and largely in parallel to the evolution of the aforementioned standards stacks. - -The CloudEvents effort shall not become a vehicle to even implicitly endorse -or promote project- or product-proprietary protocols, because that would be -counterproductive towards CloudEvents' original goals. - -For a protocol or encoding to qualify for a core CloudEvents event format or -protocol binding, it must belong to either one of the following categories: - -- The protocol has a formal status as a standard with a widely-recognized - multi-vendor protocol standardization body (e.g. W3C, IETF, OASIS, ISO) -- The protocol has a "de-facto standard" status for its ecosystem category, - which means it is used so widely that it is considered a standard for a - given application. Practically, we would like to see at least one open - source implementation under the umbrella of a vendor-neutral open-source - organization (e.g. Apache, Eclipse, CNCF, .NET Foundation) and at least - a dozen independent vendors using it in their products/services. - -Aside from formal status, a key criterion for whether a protocol or encoding shall -qualify for a core CloudEvents event format or transport binding is whether the -working group agrees that the specification will be of sustained practical benefit -for any party that is unrelated to the product or project from which the protocol -or encoding emerged. A base requirement for this is that the protocol or encoding -is defined in a fashion that allows alternate implementations independent of the -product or project's code. - -All other protocol and encoding formats for CloudEvents are welcome to be included -in a list pointing to the CloudEvents binding information in the respective -project's own public repository or site. diff --git a/primer.md b/primer.md index 4cf10d2bb..d5c0c7fee 100644 --- a/primer.md +++ b/primer.md @@ -19,6 +19,7 @@ This document is a working draft. - [CloudEvents Concepts](#cloudevents-concepts) - [Design Goals](#design-goals) - [CloudEvent Attributes Extensions](#cloudevent-attribute-extensions) +- [Qualifying Protocols and Encodings](#qualifying-protocols-and-encodings) - [Prior Art](#prior-art) - [Roles](#roles) - [Value Proposition](#value-proposition) @@ -145,6 +146,62 @@ user-stories to explain the rationale and need for them. This supporting information will be added to the [Prior Art](#prior-art) section of this document. +## Qualifying Protocols and Encodings + +The explicit goal of the CloudEvents effort, as expressed in the specification, +is "describing event data in a common way" and "to define interoperability of +event systems that allow services to produce or consume events, where the +producer and consumer can be developed and deployed independently". + +The foundation for such interoperability are open data formats and open +protocols, with CloudEvents aiming to provide such an open data format and +projections of its data format onto commonly used protocols and with commonly +used encodings. + +While each software or service product and project can obviously make its own +choices about which form of communication it prefers, its unquestionable that +a proprietary protocol that is private to such a product or project does not +further the goal of broad interoperability across producers and consumers of +events. + +Especially in the area of messaging and eventing, the industry has made +significant progress in the last decade in developing a robust and broadly +supported protocol foundation, like HTTP 1.1 and HTTP/2 as well as WebSockets +or events on the web, or MQTT and AMQP for connection-oriented messaging and +telemetry transfers. + +Some widely used protocols have become de-facto standards emerging out of strong +ecosystems of top-level multi-company consortia projects, such as Apache Kafka, +and largely in parallel to the evolution of the aforementioned standards stacks. + +The CloudEvents effort shall not become a vehicle to even implicitly endorse +or promote project- or product-proprietary protocols, because that would be +counterproductive towards CloudEvents' original goals. + +For a protocol or encoding to qualify for a core CloudEvents event format or +protocol binding, it must belong to either one of the following categories: + +- The protocol has a formal status as a standard with a widely-recognized + multi-vendor protocol standardization body (e.g. W3C, IETF, OASIS, ISO) +- The protocol has a "de-facto standard" status for its ecosystem category, + which means it is used so widely that it is considered a standard for a + given application. Practically, we would like to see at least one open + source implementation under the umbrella of a vendor-neutral open-source + organization (e.g. Apache, Eclipse, CNCF, .NET Foundation) and at least + a dozen independent vendors using it in their products/services. + +Aside from formal status, a key criterion for whether a protocol or encoding +shall qualify for a core CloudEvents event format or transport binding is +whether the working group agrees that the specification will be of sustained +practical benefit for any party that is unrelated to the product or project +from which the protocol or encoding emerged. A base requirement for this is +that the protocol or encoding is defined in a fashion that allows alternate +implementations independent of the product or project's code. + +All other protocol and encoding formats for CloudEvents are welcome to be +included in a list pointing to the CloudEvents binding information in the +respective project's own public repository or site. + ## Prior Art This section describes some of the input material used by the working group