Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
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
I wouldn't quite call it an implementation detail. Usually an
implementation detail is something that doesn't get spec'ed out.
I think I did not phrase that properly.
I meant, what I described above was our implementation detail; and yes,
it needs to be spec'ed out properly :-)
and you are right that
this must be specified more clearly in the bis spec.
I'm saying that a full JID is bad here. A bare JID is harmless. We
didn't see the problems with a full JID when we wrote RFC 3921 because
we didn't think about the case of multiple resources (or we specified
things such that the full JID would be the JID of the connected resource
for each push, i.e., the 'from' in the above examples would be res1 when
sending the push to res1, res2 when sending the push to res2, etc.,
which is a lot of work for no gain, and in fact for quite a bit of
potential confusion).
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.
No 'to' or to='bareJID' is fine by me. It's the full JID case that seems
problematic.
Yes, makes sense.
Why ... below
b) the client response must be to == user.bareJid or no 'to'.
Most XMPP software just swaps the 'from' and the 'to' when sending an
IQ-result or IQ-error. So I think we really need to specify only part
(a) here. Part (b) is just normal XMPP processing.
I mentioned that for bis clients talking to 3920/3921 servers.
A bis compliant server would do the right thing (no to/to == bareJid).
Mridul
Peter
