Skip to content

Commit

Permalink
Qualifying-protocols-and-encodings.md (cloudevents#254)
Browse files Browse the repository at this point in the history
* Qualifying-protocols-and-encodings.md

Signed-off-by: Clemens Vasters <[email protected]>

* updating per discussion in the PR

Signed-off-by: Clemens Vasters <[email protected]>

* Adding open source organization clause for equivalence with protocol standards org clause

Signed-off-by: Clemens Vasters <[email protected]>

* move into the primer

Signed-off-by: Doug Davis <[email protected]>
  • Loading branch information
clemensv authored and zpencer committed Aug 22, 2018
1 parent 217db0e commit 4d120b7
Showing 1 changed file with 57 additions and 0 deletions.
57 changes: 57 additions & 0 deletions primer.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down Expand Up @@ -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
Expand Down

0 comments on commit 4d120b7

Please sign in to comment.