> > You are raising the scenario of the stream dying right after the server > sends 303. I'm saying that client 1 MUST NOT consider itself to be up to > date when it receives 303, because the server has already told it that > the latest version is 305. Therefore, when the client reconnects it MUST > behave as if it never received the roster push for version 303 and > instead send the exact same roster get it sent when it came back online > (i.e., 299). >
Client does not consider itself up-to-date but it would retrieve a complete state if it starts retrieving again from that particular point. So it could save the interim pushes as they arrive (if we disregard the last change to the spec, which was based on wrong assumptions). That could make a huge difference if the client is on very low bandwidth, or expensive connection based on transfered data (which for example GPRS on mobile phones).
