[Standards] 'from' address on roster push
stpeter at jabber.org
Thu Jul 5 22:31:45 UTC 2007
Tomasz Sterna wrote:
> Dnia 27-06-2007, śro o godzinie 16:50 -0600, Peter Saint-Andre
>> So I propose the following text:
>> A server MUST ignore any 'to' address on a roster set, and MUST
>> treat any roster "set" as applying to the sender. A server MUST
>> NOT include a 'from' address on a roster push. If a roster push
>> includes a 'from' address then the client SHOULD ignore the
> Is it backwards compatible?
RFC 3921 talks only about what the client must do with regard to the
'from' address on a roster push:
a client SHOULD check the "from" address of a "roster push" (incoming
IQ of type "set" containing a roster item) to ensure that it is from
a trusted source; specifically, the stanza MUST either have no 'from'
attribute (i.e., implicitly from the server) or have a 'from'
attribute whose value matches the user's bare JID (of the form
<user at domain>) or full JID (of the form <user at domain/resource>);
otherwise, the client SHOULD ignore the "roster push".
If a bis-compliant server never includes a 'from' address on a roster
push, a 3921-compliant client will not break.
However, a bis-compliant client might ignore roster pushes from a
3921-compliant server, since a 3921-compliant server might include a
'from' address whose value is the bare JID or full JID of the user.
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.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards