Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forwarding OPTIONAL attributes #461

Merged
merged 4 commits into from
Jun 26, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions primer.md
Original file line number Diff line number Diff line change
Expand Up @@ -200,7 +200,7 @@ The CloudEvents specification does not mandate any particular pattern to be
used, or even the use of version strings at all. This decision is up to each
event producer. However, when a version-specific string is included, care should
be taken whenever its value changes as event consumers might be reliant on the
existing value and thus a change could be interpretted as a "breaking change".
existing value and thus a change could be interpreted as a "breaking change".
Some form of communication between producers and consumers should be established
to ensure the event consumers know what possible values might be used. In
general, this is true for all CloudEvents attributes as well.
Expand Down Expand Up @@ -569,9 +569,11 @@ including being both a producer and a consumer of events.
Whether its events are available for consumption via a middleware is a
delegation choice of the producer.

In practice, middleware can take on role of a producer when it changes the
semantic meaning of an event, a consumer when it takes action based on an
event, or middleware when it routes events without making semantic changes.
In practice, middleware can take on the role of a
[Producer](spec.md#producer) when it changes the semantic meaning of an
event, a [Consumer](spec.md#consumer) when it takes action based on an event,
or [Intermediary](spec.md#intermediary) when it routes events without making
semantic changes.

4. Frameworks and other abstractions make interactions with event platform
infrastructure simpler, and often provide common API surface areas for
Expand Down
13 changes: 7 additions & 6 deletions spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -51,12 +51,13 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).

For clarity, when a feature is marked as "OPTIONAL" this means that it is
OPTIONAL for both the sender and receiver of a message to support that feature.
In other words, a sender can choose to include that feature in a message if it
wants, and a receiver can choose to support that feature if it wants. A receiver
that does not support that feature will then silently ignore that part of the
message. The sender needs to be prepared for the situation where a receiver
ignores that feature.
OPTIONAL for both the [Producer](#producer) and [Consumer](#consumer) of a
message to support that feature. In other words, a producer can choose to
include that feature in a message if it wants, and a consumer can choose to
support that feature if it wants. A consumer that does not support that feature
will then silently ignore that part of the message. The producer needs to be
prepared for the situation where a consumer ignores that feature. An
[Intermediary](#intermediary) SHOULD forward OPTIONAL attributes.

### Attribute Naming Convention

Expand Down