CloudEvents `source` property - clarification and use in event subscriptions

[rartych]

Problem description
CloudEvents specs define source property:

Type: URI-reference

Description: Identifies the context in which an event happened. Often this will include information such as the type of the event source, the organization publishing the event or the process that produced the event. The exact syntax and semantics behind the data encoded in the URI is defined by the event producer.

Producers MUST ensure that source + id is unique for each distinct event.

An application MAY assign a unique source to each distinct producer, which makes it easy to produce unique IDs since no other producer will have the same source. The application MAY use UUIDs, URNs, DNS authorities or an application-specific scheme to create unique source identifiers.

A source MAY include more than one producer. In that case the producers MUST collaborate to ensure that source + id is unique for each distinct event.

Constraints:

• REQUIRED
• MUST be a non-empty URI-reference
• An absolute URI is RECOMMENDED

Examples
Internet-wide unique URI with a DNS authority.
https://github.com/cloudevents
mailto:cncf-wg-serverless@lists.cncf.io
Universally-unique URN with a UUID:
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
Application-specific identifiers
/cloudevents/spec/pull/123
/sensors/tn-1234567/alerts
1-555-123-4567

The content is defined by event producer.

However, CloudEvents Subscriptions API adds source as optional subscription parameter to subscription request.

Type: URI-reference - a CloudEvents source value

Description: Indicates the source to which the subscription is related. When present on a subscribe request, all events generated due to this subscription MUST have a CloudEvents source property that matches this value. If this property is not present on a subscribe request then there are no constraints placed on the CloudEvents source property for the events generated.

TODO: add something to discovery to indicate if manager supports this

Constraints:
OPTIONAL
If present, MUST be a non-empty URI

Examples:
/sensors/tn-1234567/alerts

This way the event subscriber can control the content of the source property returned in each event notification.

Current CAMARA definition in CAMARA_event_common.yaml follows CloudEvents specs and source parameter is not present in event subscription template.

Possible evolution
No change, only clarification on the content of source property in CAMARA , beyond the current example:

example: "https://notificationSendServer12.example.com"

Alternative solution

Adding source parameter to event subscription.
Possible uses:

• Namespacing in multi-tenant scenarios: the subscriber instructs the manager to stamp events with a specific source URI that identifies the subscriber's own domain or context, so events are recognizable when received or forwarded downstream
• Controlling source+id uniqueness space: since the core spec requires source + id to be globally unique per event, a subscriber specifying source could be helping define the uniqueness namespace — ensuring generated events don't collide with events from other subscriptions
• other ...

Additional context
The comment in the subscription spec itself — "TODO: add something to discovery to indicate if manager supports this" — suggests this feature is underspecified and not fully thought through even by the spec authors.

Would it be valuable in aggregator scenario for events?