URI reference for event type

[krispenner]

The spec currently encourages but doesn't force the use of a reverse-DNS name for the event type and the examples only use dot notation.

type

• Type: String
• Description: This attribute contains a value describing the type of event related to the originating occurrence. Often this attribute is used for routing, observability, policy enforcement, etc. The format of this is producer defined and might include information such as the version of the type - see Versioning of CloudEvents in the Primer for more information.
• Constraints:
  • REQUIRED
  • MUST be a non-empty string
  • SHOULD be prefixed with a reverse-DNS name. The prefixed domain dictates the organization which defines the semantics of this event type.
• Examples
  • com.github.pull_request.opened
  • com.example.object.deleted.v2

I'm curious if there has been any discussions for using a URI reference for the event type similar to the type attribute in Problem Details of rfc7807?

a "problem detail" is a way to carry machine-readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.

3.1. Members of a Problem Details Object

A problem details object can have the following members:

o "type" (string) - A URI reference [RFC3986] that identifies the problem type. This specification encourages that, when dereferenced, it provide human-readable documentation for the problem type (e.g., using HTML [W3C.REC-html5-20141028]). When this member is not present, its value is assumed to be "about:blank".

For our solution I would like that these be consistent and allow the user to dereference the URI for either which would provide a web page with a description of the event type or error type.

Cloud Events Type: https://docs.example.com/reference/events#customer_created

Problem Details Type: https://docs.example.com/reference/errors#customer_not_found

So a couple questions I have are:

1. Would using a URI reference for the event type which doesn't follow the SHOULD be prefixed with a reverse-DNS name. constraint be frowned upon or have any possible issues later with interoperability?
2. Would you consider adding a URI reference as a possible example of an event type to the spec?

Thank you for your time.

[duglin]

Just my 2 cents: 1 - I think using a URL reference is fine. One of the reasons it's a SHOULD instead of a MUST is because there may be good reasons for not following our guidance. And if you want to start a viral movement to promote the use of URIs, go for it :-) 2 - I'm not sure that our examples should promote something that goes against our recommendation. Feels a little inconsistent to me.

[adgerrits]

Another 2 cents: there are several ways to uniquely characterize events but as reverse-DNS names are a common and simple way of eliminating namespace collisions I would stay with the advice to use it so it can become the default ('should') way. In line with the 'less is more' philosophy of CloudEvents, I think that links to meta information are better included through extension attributes.

[krispenner]

Thank you both for your comments. I actually wish the Problem Details spec I referenced would allow for reverse-DNS style format of their type attribute. I would prefer to use that format for both and then as @adgerrits suggested, add a custom attribute like docref or something for a document reference URI.

While the Problem Detail RFC does not use the word MUST when dictating a URI reference for type, it also doesn't suggest I can use anything else there instead. So I may post on their spec about that. I'd just like the two to be a bit consistent, but obviously they are two very different standards. I was also thinking I could just return a Cloud Event for an error from our REST API wrapped in the HTTP binding instead of a Problem Detail... Anyways, will close this now.

Thanks again for your thoughts.