Discussion of the meaning of optional

[jskeet]

I was alarmed to see this in the spec:

For clarity, when a feature is marked as "OPTIONAL" this means that it is OPTIONAL for both the Producer and 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 is free to take any action it wishes, including no action or generating an error, as long as doing so does not violate other requirements defined by this specification. However, the RECOMMENDED action is to ignore it. The producer SHOULD be prepared for the situation where a consumer ignores that feature. An Intermediary SHOULD forward OPTIONAL attributes.

To my mind, this conflates "optional data" with "optional functionality". I believe all receivers should understand optional attributes and act accordingly (including validating them). This is particularly important for datacontenttype which can affect how formats behave.

Let's discuss it.

[jskeet]

Quick audit of the use of "optional" within the cloudevents directory of this repo:

• Lots of descriptions of what OPTIONAL means
• Support for any extension is optional
• WebHook-Request-Callback header is optional
• Description of various attributes as optional
• JSON numbers have an optional - prefix (optional in terms of syntax only, of course - required for negative numbers!)
• Whitespace is optional around header values in HTTP and NATS
• Kafka: "This spec provides an OPTIONAL definition to map the key section of the Kafka record, without constraining the user to implement it nor use it." (Would need to look more carefully to see what that means)
• Data element being optional in XML format

So I think it would be reasonably straightforward to tweak the spec to use "optional" only in terms of "this aspect of data may be present or absent" and use MAY to define features that conformant implementations don't have to implement.

[jskeet]

My next step will be to create a draft PR to separate optionality of data from optionality of implementation, but I haven't made any progress on this yet.

[github-actions]

This issue is stale because it has been open for 30 days with no
activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.

[jskeet]

/remove-lifecycle stale

[github-actions]

This issue is stale because it has been open for 30 days with no
activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.

[jskeet]

/remove-lifecycle stale

[github-actions]

This issue is stale because it has been open for 30 days with no
activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.