-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/16/09 6:45 AM, Jiří Zárevúcky wrote: > Hello. The filtering/intercepting functionality seems nice for IQ > stanzas, but I have doubts about some of the use cases. > > "Invisibility" as defined by this spec would certainly ease it's > handling by both client and server,
Simplification is a good thing, no? (Aside from the fact that invisibility is stupid, if we're going to support it then we might as well support it in the simplest way possible.) > but is changes the meaning of > available and unavailable presence stanzas. How so? <presence/> still means "tell my contacts that I'm online". <presence type='unavailable'/> still means "tell my contacts that I'm offline". > That means servers that > support SIFT will understand them differently than servers that do > not. Yes, SIFT separates presence probing and inbound presence delivery from the sending of outbound presence notifications. I don't yet see any major problems with that, because the client will discover whether the server supports SIFT before it starts sending presence. > Also, if I understand it correctly, the empty sift query means > "don't filter anything" and not "send me all now". If you use it as an > "on" switch, you are overloading it's functionality. How so? 1. I log in. 2. I discover that my server supports SIFT. 3. I send empty <sift/>. 4. Server sends me offline messages and probes my contacts. Why does empty <sift/> need to mean either "don't filter anything" or "sync me up" but not both? > The second (possible) problem is that when you use it to filter > messages (which you can do by negative priority), your contacts > wouldn't know it. If you have negative priority, everyone sees you > can't receive messages. That is not the case here. I think the spec > should at least define an error response to notify sender the entity > can't receive messages. The intent is that SIFT removes the need for negative priorities. Why is it necessary to advertise the fact that the client doesn't want to receive messages addressed to the bare JID? And what would a contact do wtih that information? In general we recommend that you send a message to the bare JID when you want to initiate a chat, not send to the full JID of a particular resource. I don't see a big (or even any) problem here. > And to be complete, I'd appreciate an example of "excepting" multiple > payload types for IQ's. Thanks :) Done in 0.0.4. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRh6gACgkQNL8k5A2w/vxLgACfbQ4ZbyvFvbod0NNNnLrLTsh8 QzoAoO8dFXC/oEU6JAo/FjXciM5tc2V7 =DQKt -----END PGP SIGNATURE-----
