Subject: [xmpp] Routing of IQs to full JIDs - special cases?

From: Matthew Wild <[email-masked]>
Date: Fri, 26 Jun 2009 02:54:26 +0100

Hi all,

I promised Peter to post this issue here for discussion, so here we go.

The other day it was brought to my attention that RFC3921bis has this
to say about roster sets in 2.1.3:

   3. The server MUST ignore any 'to' address specified on the IQ

This conflicts with the server's duty to route IQs to full JIDs to
connected clients or remote servers, for example RFC3920bis section
11.2.3.3:

   If the JID contained in the 'to' attribute is of the form
   <node@domain/resource> and there is a connected resource that exactly
   matches the full JID, the server SHOULD deliver the stanza to that
   connected resource.

I don't like this special-casing of roster sets. For example it makes
no sense to ignore the 'to' attribute if the stanza came from an s2s
connection. What to do then? If the protection is to prevent users
modifying others' rosters then I believe the protection to be in the
wrong place. A server needs to verify that the sender is authorised to
perform the action in any case, and reply appropriately if not.

I propose that point 3 of section 2.1.3 be dropped, and possibly in
its place some text to advise that the server should verify that the
sender is permitted to modify the roster, otherwise the appropriate
auth error be bounced.

Note that I personally wouldn't like wording suggesting that the
server must check the roster is actually the sender's - for example an
implementation might choose to allow a trusted local component to
modify users' rosters using roster sets.

I look forward to hearing the opinion of others on this,
Matthew

---

From: Dave Cridland <[email-masked]>
Date: Fri, 26 Jun 2009 09:58:56 +0100

>    matches the full JID, the server SHOULD deliver the stanza to  
FWIW, we don't ignore the to attribute - specifically, if someone  
sends us a roster set, we will route it like any other <iq/>.

> modify users' rosters using roster sets.
Entirely and whole-heartedly agreed.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Remko Tronçon <[email-masked]>
Date: Fri, 26 Jun 2009 12:56:12 +0200

> I look forward to hearing the opinion of others on this,

+1 for me.

cheers,
Remko

---

From: Kevin Smith <[email-masked]>
Date: Fri, 26 Jun 2009 11:57:17 +0100

Sorry about this, I'm having huge trouble with my incompetence^wmail
client today. This mail was meant for the xmpp wg list, not
standards@:

On Fri, Jun 26, 2009 at 11:20 AM, Kevin Smith<[email-masked]> wrote:
> On Fri, Jun 26, 2009 at 2:54 AM, Matthew Wild<[email-masked]> wrote:
> Sounds right to me.
> /K

---

From: Pedro Melo <[email-masked]>
Date: Fri, 26 Jun 2009 12:58:06 +0100

Hi,

> sender is permitted to modify the roster, otherwise the appropriate

+1.

Special cases should be avoided as much as possible.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [email-masked]
Use XMPP!

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 26 Jun 2009 08:55:08 -0600

>    matches the full JID, the server SHOULD deliver the stanza to that

It's not clear to me how a client would handle a roster set from another
resource (client-to-client roster management?). But in general I agree
that it would be good to avoid special-casing.

> connection. 

If all servers follow RFC 3920, that would not happen. But then you're
depending on remote servers to do the right thing, which they might not
do...

> What to do then? If the protection is to prevent users

Right.

+1.

> modify users' rosters using roster sets.

I think that would be a smart default, in the absence of a protocol that
defines access controls over rosters.

Peter

- --
Peter Saint-Andre
https://stpeter.im/