Forwarding OPTIONAL attributes (#461)

* Intermediaries MUST forward OPTIONAL attributes, if the want to ignore them.

Signed-off-by: Klaus Deissner <[email protected]>

* line wrap to 80 characters

Signed-off-by: Klaus Deissner <[email protected]>

* Correct relative links

Signed-off-by: Klaus Deissner <[email protected]>

* Change from MUST to SHOULD

Signed-off-by: Klaus Deissner <[email protected]>

primer.md

@@ -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.
@@ -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

spec.md

@@ -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