resend... -------- Original Message -------- Subject: Re: [Standards] LAST CALL: XEP-0237 (Roster Versioning) Date: Tue, 14 Apr 2009 09:15:47 -0600 From: Peter Saint-Andre <[email protected]> To: XMPP Standards <[email protected]>
On 4/14/09 3:06 AM, Jiří Zárevúcký wrote: > But I realized there is a rare scenario where it could really cause problem. > > <query ver="300"> > <item jid="[email protected]" subscription="none" /> > </query> > > <query ver="301"> > <item jid="[email protected]" subscription="none" /> > </query> > > <query ver="302"> > <item jid="[email protected]" name="Bob" subscription="none" /> > </query> > > <query ver="303"> > <item jid="[email protected]" subscription="to" /> > </query> > > <query ver="304"> > <item jid="[email protected]" name="Bob" subscription="from" /> > </query> > > <query ver="305"> > <item jid="[email protected]" name="Bob" subscription="none" /> > </query> > > Client knows 300. The roster would send 303 first, and 305 second. If > connection failed after sending 303, client would next request 303+, > but never received 302 in the first place. There seems to be some confusion about how roster versioning works. Perhaps the spec needs to describe this all in a lot more detail. However, I'll do that here first. Let's say you have two clients, 1 and 2. 1 is up to date as of ver='299' and then goes offline. 2 stays online and completes some roster management tasks. Then 1 comes back online. 1: <iq type='get'> <query xmlns='jabber:iq:roster'> </iq> S: <iq type='result'> <query xmlns='jabber:iq:roster' ver='299'> <item jid='ji�...@čechy.cz'/> </query> </iq> 1: </presence> [first roster update from client 2, with Set and Push] 2: <iq type='set'> <query> <item jid="[email protected]" subscription="none" /> </query> </iq> S: <iq type='set'> <query ver="300"> <item jid="[email protected]" subscription="none" /> </query> </iq> [second roster update from client 2, with Set and Push] 2: <iq type='set'> <query> <item jid="[email protected]" subscription="none" /> </query> </iq> S: <iq type='set'> <query ver="301"> <item jid="[email protected]" subscription="none" /> </query> </iq> [third roster update from client 2, with Set and Push] 2: <iq type='set'> <query> <item jid="[email protected]" name="Bob" subscription="none" /> </query> </iq> S: <iq type='set'> <query ver="302"> <item jid="[email protected]" name="Bob" subscription="none" /> </query> </iq> [Alice approves subscription request from user] S: <iq type='set'> <query ver="303"> <item jid="[email protected]" subscription="to" /> </query> </iq> [client 2 approves subscription request from Bob] S: <iq type='set'> <query ver="304"> <item jid="[email protected]" name="Bob" subscription="from" /> </query> </iq> [Bob sends unsubscribe] S: <iq type='set'> <query ver="305"> <item jid="[email protected]" name="Bob" subscription="none" /> </query> </iq> Now the user comes back online with client 1. 1: <iq type='get'> <query xmlns='jabber:iq:roster' ver='299'/> </iq> So the server needs to send what's changed to client 1. It does this, not by sending 300, 301, 302, 303, 304, and 305, but by sending the effective difference between 299 and 305. First it tells client 1 that there are changes: S: <iq type='result'> <query xmlns='jabber:iq:roster' ver='305'/> </iq> That means "the latest version is no longer 299 but I'm going to send you the changes as roster pushes -- when you receive a push numbered 305 then you know you're up to date". Now the server sends two roster pushes: one related to Alice (303) and one related to Bob (305): S: <iq type='set'> <query ver="303"> <item jid="[email protected]" subscription="to" /> </query> </iq> S: <iq type='set'> <query ver="305"> <item jid="[email protected]" name="Bob" subscription="none" /> </query> </iq> Therefore client 1 knows that it's up to date, and it has received the most recent information about each roster item that was changed while it was offline. 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). > Now (only) in case the server checks the last state client should > know, it will find out it doesn't need to send the push since there is > the same state as in 302. Client wouldn't receive bob's name until > next change. > > That is easily fixed by disallowing servers such checks. Sure. Perhaps we need an implementation note for servers, which says: "basically, you need to keep a record of each roster item that has changed since the last roster get(s) for this account, but you don't need to keep a record of each change, only the last state related to each changed item". Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
