Isn't this what you meant?
The client is not sending out multiple <iq/>s with the same id to all the services, just one <iq/> to one service, but multiple results from multiple services to one client.
--
Sebastiaan
Peter Saint-Andre wrote:
Hmm, does this technique rely on sending multiple IQ results with the same 'id' attribute? If so, that's in violation of the XMPP core doc, which specifies that the value of an ID must be unique within a stream (this is consistent with the XML spec).Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php On Sun, 8 Dec 2002, Sebastiaan 'CBAS' Deckers wrote:Is there any implementation of a public service using this technique?
My client supports these sequential results however I could never test this in the real world.
This is an interesting protocol design choice, but it raises security concerns. When all you have to rely on is the "id" attribute, how much chance is there that someone can spoof results? Or even by accident, as most libraries don't generate random id's.
--
Sebastiaan
Peter Saint-Andre wrote:
If you have implemented jabber:iq:search in your software AND you are
using the feature that enabled you so receive multiple IQs for large result sets, I would appreciate it if you could let me know. When I
documented jabber:iq:search in JEP-0055, I left this out because I have
not been able to find implementations. But if there are implementations, I
may add it in.
Thanks.
Peter
--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
