Consider a fallback ID mechanism for SSE events

[benfrancis]

Architecture call 3/8

PR #119 added an assertion which says it's recommended that the id field of events in SSE is a timestamp.

In the feedback on the PR it was suggested there might be a fallback mechanism for devices without a clock, such as an incrementing number.

[benfrancis]

Some background:

1. My original idea for IDs was that they should be an integer set to the number of milliseconds since the epoch, since it would be easy to compare timestamps to find which event is newer
2. We eventually decided to use ISO 8601 timestamps instead because of an assertion elsewhere in the specification that says all datetime values should be represented that way, and the fact that SSE only really treats IDs as strings when comparing them
3. The assertion was made RECOMMENDED rather than a MUST because some devices may not have a real time clock

Note that ISO 8601 timestamps are also used in the ActionStatus Object in the HTTP Baseline Profile, and in that profile there is a Note which says:

It is possible that a Thing's clock may not be set to the correct time. If timings are important then a Consumer may therefore choose to treat the timeEnded member of an ActionStatus object as being relative to the timeRequested member, but not necessarily as relative to its own internal clock, or the clocks of other Things.

I personally don't think we need to define a fallback, since this is just a recommendation and in practice developers can use whatever IDs they want.

However, some options to address the feedback:
1. Add the same note to events as we have in actions to warn that timestamps may not be accurate but can be treated as relative to each other.

Advantages:

• This accounts for the use case of no real time clock (or a clock set to the wrong time)
• Keeps timestamp metadata where available
• It's very common practice in SSE to use a timestamp as the value of the id field
• It's an easy change to make to the specification

Disadvantages:

• Timestamps may not continue to be relative to each other after a reboot
• Doesn't guarantee interoperability since it's only a recommendation

2. Add a fallback which says that if the device doesn't have a real time clock, to use an incrementing integer instead of a timestamp.

Advantages:

• Doesn't require a real time clock
• Keeps timestamp metadata where available

Disadvantages:

• Requires non-volatile storage to keep track of IDs over reboots
• Adds the complexity of two different ID schemes
• Doesn't guarantee interoperability since it's only a recommendation

3. Change the recommendation to say "The id field MUST be set to a UUID (Version 4)", which is a scheme that's also used in WoT Discovery

Advantages:

• Doesn't require a real time clock
• Doesn't require non-volatile storage
• Guarantees interoperability

Disadvantages:

• Requires a source of entropy sufficient for generating unique IDs
• Loses timestamp metadata

4. Replace the current recommendation with two assertions: "The id field MUST be set to an integer value, where the id of each event is greater than the ids of any preceding events. It is RECOMMENDED that if a real time clock is available to the Web Thing, the id should be set to the number of milliseconds past the epoch"

Advantages:

• Doesn't require a real time clock
• Guarantees interoperability in so far as ids it will always be an incrementing integer
• Keeps timestamp metadata where available

Disadvantages:

• It may be tricky to tell when the ID is a timestamp
• Requires either a real-time clock, or non-volatile storage

I actually think option 4 is quite neat, but option 1 would be a simpler change and it's at least easier to detect when the ID is a timestamp.

At the end of the day, IDs just need to be unique strings. When resuming a connection an SSE client just tells the server which was the ID of the last event it received. Ideally the Web Thing keeps an ordered log of events so it knows where to start from once the connection is resumed. Including timestamp metadata in that ID is just a bonus, which makes me think we should therefore probably just go with option 1.

[mlagally]

@benfrancis
This is a great analysis and proposal(s).

I think we should separate the two requirements:

1. id: unambiguously identifying and distinguishing events (even when they occur at exactly the same time)
2. timestamp: communicating the time when the event occurred

These are two different requirements and should be separated in different fields of event message.

The https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md
has a clear separation of these concerns, see the description of id and timestamp.

[benfrancis]

These are two different requirements and should be separated in different fields of event message.

Separating timestamp and ID into two separate fields is very different to the original request at the top of this issue.

The problem with doing that is that SSE does not natively have a separate field for timestamps in its payload format. That means that adding a timestamp field would require adding a wrapper object to the content of the data field, for metadata. That would either mean:

1. The event data no longer matches the data schema of the event in the TD (see similar issue relating to actions in Is it OK to not have output specified in a profile TD #259)
2. Every event affordance of every compliant TD would have to define the event wrapper format in its data schema, creating a lot of unecessary redundancy

I think that would make for an SSE protocol binding which is far less clean, and having a separate timestamp field isn't worth it.

The https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md
has a clear separation of these concerns, see the description of id and timestamp.

This again...