Explicit event retention policy in event stream metadata

[ysarig1]

Related to: #106.
The SSF spec include two cases where events may be queued in an event stream:

1. When an event stream is paused (see section 7.1.2)
2. When a poll delivery method is used (see section 7.1.1)

In both cases, there is a possibility of many events queueing by the transmitter to the point that it is not practical for the transmitter to retain. We should consider adding an explicit limit to the number of events (or time?) that can be retained by the transmitter to event stream metadata.

[tulshi]

Does the new language in section 7.1.2 address this issue?

[independentid]

The Transmitter MUST NOT transmit events over the stream. The transmitter
will hold any events it would have transmitted while paused, and SHOULD
transmit them when the stream’s status becomes "enabled". If a Transmitter
holds successive events that affect the same Subject Principal, then the
Transmitter MUST make sure that those events are transmitted in the order of
time that they were generated OR the Transmitter MUST send only the last events
that do not require the previous events affecting the same Subject Principal to
be processed by the Receiver, because the previous events are either cancelled
by the later events or the previous events are outdated.

This language seems problematic for many transmitters. It would require that events be transformed cumulatively. Then the question would be how often and when. A transmitter that is detached from a generator would likely have no such ability.

Regarding "retention policy" I don't think the matter has been addressed. At minimum, there should be some considerations that spell out that it may be impossible for a transmitter to "retain" events indefinitely. The pause state should be temporary (hours) not days or more.

[ysarig1]

@tulshi I don't see any recent relevant update in 7.1.2 that addresses the event retention issue (as @independentid pointed out). This is something that need to be addressed before 1_0-ID2.
Also note that the same issue exists when doing polling (i.e., there is no guarantee that the receiver will actually do the polling which mean the transmitter will just accumulate events that need to be polled).

[tulshi]

Ok. I see the problem. The status values are repeated in 7.1.2.1, whereas they were cleaned up in 7.1.2. I will remove the ambiguity and problematice language from 7.1.2.1, since they are already specified in 7.1.2

[tulshi]

@ysarig1 is this issue closed in the latest spec? If so, could you please close this? Thanks