[Standards] -

Mridul Muralidharan mridul at sun.com
Fri Jul 6 02:17:00 UTC 2007


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='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 
> 
> 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
> 




More information about the Standards mailing list