Re: [Standards] SIFT revisited
On Mon Jun 8 23:22:34 2009, Peter Saint-Andre wrote: Don't send my [outbound] presence or Don't send me [inbound] presence or both? Based on previous discussions, I assume the latter. Inbound. - or turns off that state. Nothing gets dropped, just delayed, maybe by a maximum time. IMHO, how the server gives you the most up-to-date presence information is an implementation matter. It could queue up inbound presence notifications or it could send a new probe when you ask for presence again or it could do some combination of the two (queue until the cache becomes too big, then flush the cache and probe if needed). A probe will send at least one presence stanza per contact in the roster. Sensible buffering of presence - dropping intermediate presence - will also do this. So I don't think probes are a good option, especially as you'd then have to buffer the responses up to get the compression advantage that we're after here. So presence/ gets buffered until either a message/, or an iq/, needs sending. Needs sending inbound to the client? I assume so, just making sure. That'd be the idea. The client can flush the pending presence in a number of ways, the most obvious one being simple using a XEP-0199 ping - the response being quite sufficient to flush the presence down. What exactly do you mean by flush the presence down? Do you mean that the server sends updated inbound presence to the client, or that it empties the server-side cache? Let me give a concrete example - in our implementation, stanzas are written to a buffer, and at some point, a function called xmpp_flush() is called, which runs the buffer through XEP-0138, TLS, etc, and actually calls the write() system call to send the data over the network. In a simple implementation of this presence hushing thing, we simply wouldn't call xmpp_flush() if there were only presence stanzas in that buffer, unless it got quite big. (We could be cleverer, and remove presence stanzas that were overtaken by events, etc, but that's optional). But AFAICT it doesn't address all the use cases we discussed at XMPP Summit 6. I might want my mobile device to be awakened only if I am to receive a phone call (Jingle invite) or a useful message (for some value of useful -- e.g., perhaps not some random, low-priority news headline). Phone calls are easy enough, being iq/. I would say that I'm going to push back on anything needing XPath evaluations on every stanza - I don't think any server implementor wants that - but switching off headline type messages seems reasonable. Now, the reason I don't think the rest of SIFT helps is that I'm not convinced that much unsolicited iq/ traffic actually happens, How about unsoliticited message/ traffic? I'm not talking only about PEP stuff here, but news feeds, chatroom invitations, roster item exchange messages, etc. I grant that it's difficult to sort through all those, but that's what something like SIFT would give you. However, perhaps we get the biggest bang for the buck with presence only. I have to admit, aside from headline type messages, I'm not clear what using caps to signal intent misses out. For maximal cleverness, one could conceive a server which filtered out unsupported or unrequested stanzas based on caps, but I'm not sure I'd want to do that. because well-behaved actors, at least, will check the disco#info and only send iq/ stanzas supported by the remote end. As to IQs, we'd need to look at our full protocol suite to see what's in play here (we can at least add file transfer to your list), but you might be right that well-behaved actors won't send too many extraneous requests. Right - it might well be worth using *different* caps for people in your roster vs MUC, etc, though. vcards from MUC (please, folks, fix those), What *exactly* needs fixing here? Separate thread, please. :) Done. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] SIFT revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/6/09 3:15 AM, Dave Cridland wrote: On Sat Jun 6 02:54:44 2009, Brian Cully wrote: Sorry, on my phone so I can't do proper inline replies. Maybe I'm missing something, but preserving presence on the server until a subsequent iq or message stanza leads to dos attacks via resource consumption. Is that not what you were advocating? Well, I'm assuming there's details to be worked out. That attack is instantly mitigated by allowing the server to flush down presence after a timeout, or when it becomes big, or just because. Sure, I expect that the server would always need to be Smart[tm] about how it implements any such feature. 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 iEYEARECAAYFAkotiFYACgkQNL8k5A2w/vxpXwCfcxQZs4dWjnk9RZinQuyu6YYM TA0AnRPX1hcS4Bn4ZlRTs49g75WvUJ/p =L1s4 -END PGP SIGNATURE-
Re: [Standards] SIFT revisited
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/5/09 5:29 PM, Dave Cridland wrote: On Fri Jun 5 23:57:06 2009, Peter Saint-Andre wrote: Fabio Forno has found some good results with SIFT on a mobile phone: http://blog.bluendo.com/ff/xmpp-and-compression-a-little-experiment Hmmm - I had a long chat with Forno the other evening, and I've been meaning to write it up in a more formal way for us all to share... The general idea is that instead of SIFT at all, we have a single command which simply says Don't send my presence *until* you've something else to send me. Don't send my [outbound] presence or Don't send me [inbound] presence or both? Based on previous discussions, I assume the latter. - or turns off that state. Nothing gets dropped, just delayed, maybe by a maximum time. IMHO, how the server gives you the most up-to-date presence information is an implementation matter. It could queue up inbound presence notifications or it could send a new probe when you ask for presence again or it could do some combination of the two (queue until the cache becomes too big, then flush the cache and probe if needed). So presence/ gets buffered until either a message/, or an iq/, needs sending. Needs sending inbound to the client? I assume so, just making sure. The client can flush the pending presence in a number of ways, the most obvious one being simple using a XEP-0199 ping - the response being quite sufficient to flush the presence down. What exactly do you mean by flush the presence down? Do you mean that the server sends updated inbound presence to the client, or that it empties the server-side cache? The user experience looks roughly as if presence is sometimes out of date for a short while, but if a message arrives, it would push down any delayed presence updates, so it wouldn't be often. Yes, I think that is the desired outcome w.r.t. to presence. This is, I'd note, a pretty simple protocol to implement, and the interesting thing about Fabio's experiment is that it shows it'd give benefits. But AFAICT it doesn't address all the use cases we discussed at XMPP Summit 6. I might want my mobile device to be awakened only if I am to receive a phone call (Jingle invite) or a useful message (for some value of useful -- e.g., perhaps not some random, low-priority news headline). If we want to get complicated, we can point out that if we're buffering presence anyway, we might collapse presence stanzas that are overtaken by events - so if you go away, then xa, then offline, the server *might* drop the away/xa changes, and just give the phone a single offline. I definitely think that is the desired behavior. I don't care what your presence *was* five minutes ago, I care what it is now. Now, the reason I don't think the rest of SIFT helps is that I'm not convinced that much unsolicited iq/ traffic actually happens, How about unsoliticited message/ traffic? I'm not talking only about PEP stuff here, but news feeds, chatroom invitations, roster item exchange messages, etc. I grant that it's difficult to sort through all those, but that's what something like SIFT would give you. However, perhaps we get the biggest bang for the buck with presence only. because well-behaved actors, at least, will check the disco#info and only send iq/ stanzas supported by the remote end. As to IQs, we'd need to look at our full protocol suite to see what's in play here (we can at least add file transfer to your list), but you might be right that well-behaved actors won't send too many extraneous requests. There are exceptions, such as version queries, Evil. vcards from MUC (please, folks, fix those), What *exactly* needs fixing here? Separate thread, please. :) and pings - the latter, of course, rather relies on getting through. Right. Actually *dropping* data just strikes me as poor - I think we can do much better than that. For messages, I think the spec would recommend throwing them into offline storage. FWIW, I *do* think that people want to have the concept of a session roster vs full roster, but I think that's a different problem to solve. (And one that's quite easy, too, but harder to implement). OK, thanks for the feedback! 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 iEYEARECAAYFAkotjyoACgkQNL8k5A2w/vyJrQCgt+hH7NNaHC9gPkIiOffiGVNg YE0AnA9/7Of5vD57nGEMRwBO/Tdp4QB/ =ybiw -END PGP SIGNATURE-
Re: [Standards] SIFT revisited
On Fri Jun 5 23:57:06 2009, Peter Saint-Andre wrote: Fabio Forno has found some good results with SIFT on a mobile phone: http://blog.bluendo.com/ff/xmpp-and-compression-a-little-experiment Hmmm - I had a long chat with Forno the other evening, and I've been meaning to write it up in a more formal way for us all to share... The general idea is that instead of SIFT at all, we have a single command which simply says Don't send my presence *until* you've something else to send me. - or turns off that state. Nothing gets dropped, just delayed, maybe by a maximum time. So presence/ gets buffered until either a message/, or an iq/, needs sending. The client can flush the pending presence in a number of ways, the most obvious one being simple using a XEP-0199 ping - the response being quite sufficient to flush the presence down. The user experience looks roughly as if presence is sometimes out of date for a short while, but if a message arrives, it would push down any delayed presence updates, so it wouldn't be often. This is, I'd note, a pretty simple protocol to implement, and the interesting thing about Fabio's experiment is that it shows it'd give benefits. If we want to get complicated, we can point out that if we're buffering presence anyway, we might collapse presence stanzas that are overtaken by events - so if you go away, then xa, then offline, the server *might* drop the away/xa changes, and just give the phone a single offline. Now, the reason I don't think the rest of SIFT helps is that I'm not convinced that much unsolicited iq/ traffic actually happens, because well-behaved actors, at least, will check the disco#info and only send iq/ stanzas supported by the remote end. There are exceptions, such as version queries, vcards from MUC (please, folks, fix those), and pings - the latter, of course, rather relies on getting through. Actually *dropping* data just strikes me as poor - I think we can do much better than that. FWIW, I *do* think that people want to have the concept of a session roster vs full roster, but I think that's a different problem to solve. (And one that's quite easy, too, but harder to implement). Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] SIFT revisited
Sorry, on my phone so I can't do proper inline replies. Maybe I'm missing something, but preserving presence on the server until a subsequent iq or message stanza leads to dos attacks via resource consumption. Is that not what you were advocating? -bjc On Jun 5, 2009, at 19:29, Dave Cridland d...@cridland.net wrote: On Fri Jun 5 23:57:06 2009, Peter Saint-Andre wrote: Fabio Forno has found some good results with SIFT on a mobile phone: http://blog.bluendo.com/ff/xmpp-and-compression-a-little-experiment Hmmm - I had a long chat with Forno the other evening, and I've been meaning to write it up in a more formal way for us all to share... The general idea is that instead of SIFT at all, we have a single command which simply says Don't send my presence *until* you've something else to send me. - or turns off that state. Nothing gets dropped, just delayed, maybe by a maximum time. So presence/ gets buffered until either a message/, or an iq/, needs sending. The client can flush the pending presence in a number of ways, the most obvious one being simple using a XEP-0199 ping - the response being quite sufficient to flush the presence down. The user experience looks roughly as if presence is sometimes out of date for a short while, but if a message arrives, it would push down any delayed presence updates, so it wouldn't be often. This is, I'd note, a pretty simple protocol to implement, and the interesting thing about Fabio's experiment is that it shows it'd give benefits. If we want to get complicated, we can point out that if we're buffering presence anyway, we might collapse presence stanzas that are overtaken by events - so if you go away, then xa, then offline, the server *might* drop the away/xa changes, and just give the phone a single offline. Now, the reason I don't think the rest of SIFT helps is that I'm not convinced that much unsolicited iq/ traffic actually happens, because well-behaved actors, at least, will check the disco#info and only send iq/ stanzas supported by the remote end. There are exceptions, such as version queries, vcards from MUC (please, folks, fix those), and pings - the latter, of course, rather relies on getting through. Actually *dropping* data just strikes me as poor - I think we can do much better than that. FWIW, I *do* think that people want to have the concept of a session roster vs full roster, but I think that's a different problem to solve. (And one that's quite easy, too, but harder to implement). Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] SIFT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/18/09 12:20 PM, Joe Hildebrand wrote: 2009/5/18 Jiří Zárevúcky zarevucky.j...@gmail.com: 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. Agree. The default is not to sift, and we may not have captured that adequately in the draft yet. We also need to make it explicit that you can change your sift rules at any time. There is still a use case for priority -1 presence; I'm a presence publisher that doesn't want to receive messages. The -1 here is a hint to the sender that they shouldn't expect me to get this message if they send it right now. We probably need to add text like this: If a client requests message sifting, but sends presence, it SHOULD send priority -1 as a hint to subscribers. Done. I'm also adding a bit more on the requirements per this: http://mail.jabber.org/pipermail/council/2009-May/002562.html 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 iEYEARECAAYFAkoTL+kACgkQNL8k5A2w/vyXFACg9KEYloIErxcosCXyksMlqsPq pX8AnieoBSFZVrp0z43aqmi2j6sjNVm1 =Felf -END PGP SIGNATURE-
Re: [Standards] SIFT
-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-
Re: [Standards] SIFT
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. :)
Re: [Standards] SIFT
2009/5/18 Jiří Zárevúcky zarevucky.j...@gmail.com: 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. Agree. The default is not to sift, and we may not have captured that adequately in the draft yet. We also need to make it explicit that you can change your sift rules at any time. There is still a use case for priority -1 presence; I'm a presence publisher that doesn't want to receive messages. The -1 here is a hint to the sender that they shouldn't expect me to get this message if they send it right now. We probably need to add text like this: If a client requests message sifting, but sends presence, it SHOULD send priority -1 as a hint to subscribers. -- Joe Hildebrand
Re: [Standards] SIFT
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, but is changes the meaning of available and unavailable presence stanzas. That means servers that support SIFT will understand them differently than servers that do not. 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. 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. And to be complete, I'd appreciate an example of excepting multiple payload types for IQ's. Thanks :)
Re: [Standards] SIFT
Peter Saint-Andre wrote: http://xmpp.org/extensions/inbox/sift.html I only took a quick look at the spec and maybe I missed it, but what happens to an IQ that got filtered? If a client sends an IQ it expects an answer and that answer maybe 'client not available'. What is the answer if the recipient filters the IQ? Dirk -- How can something be 'new and improved'? If it's new what was it improving on?
Re: [Standards] SIFT
Jiří Zárevúcky wrote: 2009/5/16 Dirk Meyer dme...@tzi.de: Peter Saint-Andre wrote: http://xmpp.org/extensions/inbox/sift.html I only took a quick look at the spec and maybe I missed it, but what happens to an IQ that got filtered? If a client sends an IQ it expects an answer and that answer maybe 'client not available'. What is the answer if the recipient filters the IQ? I believe server should reply with service-unavailable on behalf of the client. That way it is consistent with XMPP-CORE and doesn't introduce any security problems. Sounds good. This should be part of section 3.3 Dirk -- Time passed, which, basically, is its job. -- Terry Pratchett (in: Equal Rites)
Re: [Standards] SIFT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/16/09 6:52 AM, Dirk Meyer wrote: Jiří Zárevúcky wrote: 2009/5/16 Dirk Meyer dme...@tzi.de: Peter Saint-Andre wrote: http://xmpp.org/extensions/inbox/sift.html I only took a quick look at the spec and maybe I missed it, but what happens to an IQ that got filtered? If a client sends an IQ it expects an answer and that answer maybe 'client not available'. What is the answer if the recipient filters the IQ? I believe server should reply with service-unavailable on behalf of the client. That way it is consistent with XMPP-CORE and doesn't introduce any security problems. Sounds good. This should be part of section 3.3 That is what is meant by the server MUST respond to all IQ stanzas in a way consistent with the specification for the given payload namespace (if defined) or as specified in XMPP Core [6] or XMPP IM [7] for IQs where no full JID localp...@domain.tld/resource matches. I can add the clause ; typically that means returning a service-unavailable/ error. 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 iEYEARECAAYFAkoO2A8ACgkQNL8k5A2w/vyr7wCg28D6Di/YM8TUMfV7WxG9RsEW 4JwAoOiHWe5oMQepHtAmJ8qzhe1UnZvF =qa9T -END PGP SIGNATURE-
Re: [Standards] SIFT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/14/09 9:39 PM, Peter Saint-Andre wrote: On 5/14/09 9:24 PM, Peter Saint-Andre wrote: On 5/14/09 9:19 PM, Waqas Hussain wrote: On Fri, May 15, 2009 at 8:15 AM, Peter Saint-Andre stpe...@stpeter.im wrote: The namespace seems to have retained its roots instead of using sift. Not sure what you mean here. s/urn:xmpp:dc:0/urn:xmpp:sift:0/ under http://xmpp.org/extensions/inbox/sift.html#registrar-ns Oh, simple operator error by the spec writer. :) Fixed in version 0.0.2: http://xmpp.org/extensions/inbox/sift.html Version 0.0.3 is now available. Many details have been clarified. 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 iEYEARECAAYFAkoN7w0ACgkQNL8k5A2w/vwU0wCgtxW7A8D6bWhUqKLK26IelX8r yt4AoMy2Nj35rX6wvR97i6426JYJLm48 =70/a -END PGP SIGNATURE-
Re: [Standards] SIFT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/14/09 4:32 PM, Peter Saint-Andre wrote: Yesterday while Jack Moffitt was in Denver, Joe Hildebrand and I worked with him on a method for registering stanza handlers with the server so that the client can ask the server to deliver only certain kinds of stanzas. This could be used for the kind of hush functionality we discussed in Brussels a few months ago. A very early version is here: http://xmpp.org/extensions/inbox/sift.html The technology will be extensible, so that in the future people could add things like regular expression matching or XPath. However, those advanced methods are not yet part of the spec. Please send along your feedback! On the j...@jabber.org list, Jack Moffitt wrote... I have a few comments on http://xmpp.org/extensions/inbox/sift.html The namespace seems to have retained its roots instead of using sift. Not sure what you mean here. I think when a client registers for presence, that is the time when the server should do presence probes. You are correct. I think adding a default attribute to //register/iq is desireable, and it would work as such: default='deny' would mean that the child elements constitute a whitelist. default='allow' would mean they constitute a blacklist. If we think the blacklist use case is not very compelling, then it may be better to keep it simple. It seems to me that treating SIFT as functionally equivalent to registering a handler seems like the way to go, rather than having the kinds of zebra lists (blacklist/whitelist) that we have XEP-0016. Some note should be made that if we register for a subset of iqs, it becomes the server's rsponsibility to respond to unregistered namespaces so that we remain compliant with 3920. Naturally. I'll add a note about that. 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 iEYEARECAAYFAkoM3k8ACgkQNL8k5A2w/vxmHQCfSShV1I1OgMvk9NC0htlOE6Dw 59sAmwf+ef6bjETVQ24ljZu24I9S1Q/N =Z2bA -END PGP SIGNATURE-
Re: [Standards] SIFT
On Fri, May 15, 2009 at 8:15 AM, Peter Saint-Andre stpe...@stpeter.im wrote: The namespace seems to have retained its roots instead of using sift. Not sure what you mean here. s/urn:xmpp:dc:0/urn:xmpp:sift:0/ under http://xmpp.org/extensions/inbox/sift.html#registrar-ns
Re: [Standards] SIFT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/14/09 9:19 PM, Waqas Hussain wrote: On Fri, May 15, 2009 at 8:15 AM, Peter Saint-Andre stpe...@stpeter.im wrote: The namespace seems to have retained its roots instead of using sift. Not sure what you mean here. s/urn:xmpp:dc:0/urn:xmpp:sift:0/ under http://xmpp.org/extensions/inbox/sift.html#registrar-ns Oh, simple operator error by the spec writer. :) 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 iEYEARECAAYFAkoM4IMACgkQNL8k5A2w/vyWcwCg+SG6wTVtFWPAbhKElushhzmG AvsAoM19L2zdUFHGX9Tpuu01NXidxbzt =ITVq -END PGP SIGNATURE-
Re: [Standards] SIFT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/14/09 9:24 PM, Peter Saint-Andre wrote: On 5/14/09 9:19 PM, Waqas Hussain wrote: On Fri, May 15, 2009 at 8:15 AM, Peter Saint-Andre stpe...@stpeter.im wrote: The namespace seems to have retained its roots instead of using sift. Not sure what you mean here. s/urn:xmpp:dc:0/urn:xmpp:sift:0/ under http://xmpp.org/extensions/inbox/sift.html#registrar-ns Oh, simple operator error by the spec writer. :) Fixed in version 0.0.2: http://xmpp.org/extensions/inbox/sift.html 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 iEYEARECAAYFAkoM4+cACgkQNL8k5A2w/vyC/wCfTGkonF+JjjiJ45Wwf/R7EtrB 3JcAoNbiaD8tnv0PekpwXghrVh9fSYeM =idqv -END PGP SIGNATURE-
