what does optional mean for receivers of CloudEvents

[duglin]

On the 2/14/2019 call a question arose around what "OPTIONAL" meant in the spec. For example, does it mean it is OPTIONAL for a sender of a CloudEvent to use that feature, or that it is OPTIONAL for a receiver of the CloudEvent to support that feature.

IMO, unless otherwise specified, OPTIONAL means "optional for senders to use, but required for receivers to support". However, we should clarify this some place in our docs (spec or primer).

[clemensv]

I really think OPTIONAL means "optional to send, optional to handle". Take the schemaUrl, for instance. You can include JSON schema reference, but what does "required to support" mean then if the receiver runs some dynamic code that makes some assumption about the shape of the payload without ever consulting that schema? With OPTIONAL, you're optionally offering the receiver some metadata that MAY make it easier/clearer to handle the event, but due to its optional nature, that metadata is not and cannot be required.

[n3wscott]

But middleware can't drop OPTIONAL fields, right? They are not optional to forward.

[JemDay]

I'd concur with @n3wscott .... intermediaries MUST propagate optional attributes.

[markpeek]

Agreed with @n3wscott and @JemDay. Producers and consumers MAY add or interpret optional attributes. Middleware MUST propagate optional attributes. Middleware that does not should be considered both a consumer and a producer per the primer.

@duglin your comment above states "OPTIONAL means...but required for receivers to support...". Looking at time as an optional attribute, a receiver could function fine without it.

[duglin]

Sorry, I was too sloppy with my wording.... I meant that a receiver can not reject a message due to the presence of an OPTIONAL attribute. Whether it chooses to act upon/support an OPTIONAL attribute is its choice, but if it does then it is bound by the semantics defined by our spec. So, for example, it could reject the message due to that attribute IF it contained an invalid value (per the spec), but I don't think it can reject it if the value is valid.

Trying to remember the semantics of: https://www.ietf.org/rfc/rfc2119.txt
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality.

[duglin]

A while ago we added this:

---

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.

---

and I think that address this issue so I'm going to close it.