Clarify event retention in section 7.1.2.1
Closed this issue · 2 comments
Background
The spec defines a status for a stream, and it provide for the possibility of a stream being “paused”. In that case, it says the following about the “paused” status (in section 7.1.2): “A Receiver MUST assume that events may have been lost during the time when the event stream was paused”. In section 7.1.2.1, the following is said about the returned “paused” status (bold is my emphasis): “The transmitter will hold any events it would have transmitted while paused and SHOULD transmit them when the stream's status becomes "enabled".”
So, section 7.1.2 say that the receiver should expect event to be lost while the stream is paused while section 7.1.2.1 seems to assume that the transmitters is going to holds all the events that occurred while the stream was paused and that it should send them (or an abbreviated list of them) to the receiver.
Requirements
The spec shouldn’t assume that the transmitter can hold all events so the following statement in section 7.1.2.1 "Transmitter will hold..." should be: "Transmitter SHOULD hold..."
When the SECEVENT WG discussed this, the retention during pause was always a best effort. We had discussed that pausing for half a day or so was reasonable.
The issue is that some event issuers might have so many receivers that retention for an extended period is unreasonable.
The max retention period might be something that could be discovered, or set in the stream configuration by the publisher so the receiver can find out.
I think this language has been updated. Please check the new language, and re-open this issue if you think it still needs to be addressed.