[Standards] SIFT

Peter Saint-Andre stpeter at stpeter.im
Mon May 18 16:07:04 UTC 2009

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

> 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 Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Standards mailing list