Removing effective_at

[appsdesh]

SET reports the facts of the past. effective_at is redundant as event_timestamp provides the same understanding. CAEP uses the same convention

[identitymonk]

Hi @appsdesh

this is not true, we could report that an Anchor has been created now which is represented by the timestamp of event_timestamp while it could on be considered active in the future which is what effective_at is about.

Is it clearer this way?

[appsdesh]

@identitymonk

SET is expected to represent a historic event

a SET represents something that has already occurred and is historical in nature.

imo, by adding any future messaging in the event, we are adding a burden on the receivers/implementers to maintain the state. The receiver may need to "remember" when this will be effective. I don't see a mechanism in the profile to indicate whether the future event is canceled, i.e., to reset the remembered state.

I suggest we stick to the notion of historic events to make interoperability easier; receivers should not need to maintain state for specific profiles.

Also, note that SET already defines toe time of event claim, maybe that could be used instead of defining a new claim with an updated understanding.

[identitymonk]

thanks for the details @appsdesh I will process that