[Standards] XEP-0047 (Flow rate control for IBB)
mridul at sun.com
Fri Jul 20 03:02:24 UTC 2007
William Voorsluys wrote:
>> > Justin, what say you?
>> I'm against adding redundant information like this into the stanzas.
>> Maybe William can explain what he means by "filtering" and how this is
> This is really an implementation issue and is more related to parsing.
> Suppose I need both 'sid' and 'seq' to be included in the response.
> Without child elements I would use an 'id' like "sid001_10". Since the
> values I need are not as an XML structure, I need to create a special
> "ID parser" that would break the id into pieces and deliver the values
> to the application.
> This is needed because we want to create Packet Filters in the Smack
> library that only match a specific session id. Messages of the
> different sessions are delivered to different Objects (the Packet
> Listeners or Packet Collectors). If I don't break the 'id' and get
> 'sid' to use as the argument input, I have to create one Packet
> Collector for each message sent, using the full 'id' as the filter
> argument, so that the correct sender will receive the message
> As I said, this is an implementation issue and we could cope with
> using just 'id' for tracking packets, even though it makes the
> implementation harder.
For xmpp, iq response (result/error) and requests are to be associated
based on [from, to, id] tuple - nothing else. So expecting or relying on
other additional information will not work across usecases or clients.
And it makes no sense to duplicate this in other forms when it is
possible to make this associated unambiguously.
For example, the response need not contain the namespace element to
which the request was sent to, but can be a bare response (<iq
from="dest at dm" id="reqid" type="result" />). I have seen libraries
assuming recommended behavior as though it was MUST and not handling
More information about the Standards