2009/5/18 Peter Saint-Andre <stpe...@stpeter.im>: > -----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.) >
Sure. >> 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. > Well, until now I believed that "unavailable" presence doesn't mean "show me offline", but "make me unavailable for presence exchange and messaging". But you're right, it doesn't really matter. Anyway, if SIFT capable client went invisible mid-session, it could do so by sending unavailable presence. But possibly without any prior SIFT command. So I think it should be noted that either supporting client must use sift to initiate it's "SIFT based session" prior to using such invisibility, or the server must not terminate the communication availability even when there was no explicit SIFT. If it is not specified, the first possibility should be implicit for the client developer to avoid problems, but I'm afraid not everyone would realize that. >> 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? > It's actually not said that the request also means "start sending everything that's not to be intercepted". It's only implied by the business rules. I think it should be added to the definition. >> 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. > Oh, sorry. I thought the rule applies to any message, even specifically addressed. I have to read more carefully next time. >> And to be complete, I'd appreciate an example of "excepting" multiple >> payload types for IQ's. Thanks :) > > Done in 0.0.4. > > Peter > You've forgotten to update human language "translation". :)
