Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
Now, a 'from' address of the full JID seems odd to me. What if I send an
IQ-set from one of my resources to another? Does that mean I can do
roster pushes directly from one resource to another without updating the
roster on the server? Does the server deliver the IQ-result packets from
all interested resources to the initiating resource for the roster set?
That seems wrong to me (i.e., I think it's a spec bug in RFC 3921).
A bare JID makes more sense because IQs sent to the bare JID are handled
by the server. But in that case, the server can't perform the usual
swapping of 'from' and 'to' addresses anyway, so it seems easier to not
include the 'from' address.
In our case, server handles roster iq's, irrespective of destination
specified in stanza and will always be processed for the sender.
Here's what I'm talking about:
1. res1 sends a roster set:
<iq from='[EMAIL PROTECTED]/res1' type='set'>
<query xmlns='jabber:iq:roster'>.....</query>
</iq>
2. Server processes the set and sends out roster pushes to res1, res2,
and res3:
<iq from='[EMAIL PROTECTED]/res1' to='[EMAIL PROTECTED]/res1' type='set'>
<query xmlns='jabber:iq:roster'>.....</query>
</iq>
<iq from='[EMAIL PROTECTED]/res1' to='[EMAIL PROTECTED]/res2' type='set'>
<query xmlns='jabber:iq:roster'>.....</query>
</iq>
<iq from='[EMAIL PROTECTED]/res1' to='[EMAIL PROTECTED]/res3' type='set'>
<query xmlns='jabber:iq:roster'>.....</query>
</iq>
3. In accordance with RFC 3920 and RFC 3921, all three resources process
the roster push and return IQ-result:
<iq from='[EMAIL PROTECTED]/res1' to='[EMAIL PROTECTED]/res1' type='result'>
<query xmlns='jabber:iq:roster'>.....</query>
</iq>
<iq from='[EMAIL PROTECTED]/res2' to='[EMAIL PROTECTED]/res1' type='result'>
<query xmlns='jabber:iq:roster'>.....</query>
</iq>
<iq from='[EMAIL PROTECTED]/res3' to='[EMAIL PROTECTED]/res1' type='result'>
<query xmlns='jabber:iq:roster'>.....</query>
</iq>
4. In accordance with RFC 3920, server routes all three IQ-results to
res1 -- it does not process them itself because IQs addressed to full
JIDs are delivered to the client, not processed by the server. So as a
result, the client running at res1 receives 3 IQ-results.
Is that desired behavior? I think not. The server doesn't process the
IQ-results (were they received?) and the res1 client is going to be
confused.
Or so it seems to me.
I say we didn't specify this fully or carefully enough in RFC 3921 and
should fix it.
Peter
I was describing about how our server processes roster requests.
In our case the 'from' gets set to the bare jid of the user before the
roster push - so this problem particular problem you describe is not
present.
That being said, this is an implementation detail and you are right that
this must be specified more clearly in the bis spec.
But specifying that 'from' should not be present for roster push might
not be a good idea ...
What about just stating that :
a) from == null || bareJid(from) == user.bareJid for all roster push.
b) the client response must be to == user.bareJid or no 'to'.
This would make it backwardly compatible while avoiding the problem we
have above.
And since the roster push was from the server (and not from a client),
(b) makes logical sense though it might be violating strict iq
requirements (result.to != request.from) - tightening would make it
incompatible with existing deployments which use full jid's for 'from'.
Regards,
Mridul
