On 3/6/10 7:09 AM, Fabio Forno wrote: > On Fri, Mar 5, 2010 at 5:30 PM, Peter Saint-Andre <[email protected]> wrote: > >> The point of SIFT is to be flexible and extensible, which means that a >> SIFT implementation inherently has more complexity. > > That's not necessary. I may implement only presence hush and expose it > using SIFT syntax. The implementation effort is quite simple: > - answer to disco queries with the correct features > - listen for incoming SIFT packets and just look for <presence/> elements > - reply with errors for all not supported filters
Yes, I think that's true. It's not *quite* as simple as a dedicated presence-hush method, but it's not so bad. >> The SIFT command to >> hush presence is quite simple: >> >> <iq from='[email protected]/pda' >> id='uh2s64g9' >> to='[email protected]' >> type='set'> >> <sift xmlns='urn:xmpp:sift:1'> >> <presence/> >> </sift> >> </iq> >> >> The problem is that SIFT can also be used to hush messages and IQs, >> intercept or filter based on sender, etc. At a minimum, we'd need a >> better definition of error handling for any feature that a SIFTing >> server does not support. > > Uhm... error conditions are defined I see. Perhaps I just don't know > what to do when only some of the conditions in a SIFT stanza are > unsupported (I vote for doing nothing at all and send > <feature-not-implemented/>). +1 > Finally, I don't like too many ad hoc solutions and the proliferation > of namespaces for the same thing. I personally like SIFT since it > seems general enough for doing many things, and it already has support > for cleanly doing partial implementations. I hope so. > It is just not clear (for me at least) what really happens when iqs > are sifted, if it is possible for example to proxy disco#info or > #items requests, or what would happen for iq based deliveries if they > will be approved (though somebody already uses them). But I'm not > worried about this since this part of the spec could be better defined > in feature when SIFT will be really implemented Feedback and spec improvements are welcome, of course. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
