[Standards] -

Peter Saint-Andre stpeter at jabber.org
Fri Jul 6 02:08:15 UTC 2007


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.

> 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.

> 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.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070705/b3410c70/attachment.bin>


More information about the Standards mailing list