[Standards] -

Mridul Muralidharan mridul at sun.com
Thu Jul 5 23:27:58 UTC 2007


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='user at host/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='user at host/res1' to='user at host/res1' type='set'>
>   <query xmlns='jabber:iq:roster'>.....</query>
> </iq>
> 
> <iq from='user at host/res1' to='user at host/res2' type='set'>
>   <query xmlns='jabber:iq:roster'>.....</query>
> </iq>
> 
> <iq from='user at host/res1' to='user at host/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='user at host/res1' to='user at host/res1' type='result'>
>   <query xmlns='jabber:iq:roster'>.....</query>
> </iq>
> 
> <iq from='user at host/res2' to='user at host/res1' type='result'>
>   <query xmlns='jabber:iq:roster'>.....</query>
> </iq>
> 
> <iq from='user at host/res3' to='user at host/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



More information about the Standards mailing list