Subject: [xmpp] Roster sets - ignoring subscription types

From: Kevin Smith <[email-masked]>
Date: Wed, 21 Jul 2010 10:31:25 +0100

2.1.5.2 - There is value in loosening the MUST ignore here to a SHOULD
ignore. There are valid reasons for allowing this - for example an
admin interface allowing an administrator to edit user's rosters.

Also, in the following note, I think it is the recipient's
responsibility to verify access to roster sets - the text currently
implies that the user's server should be doing this, when it may not
be the target of the set.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 25 Jul 2010 15:26:54 +0200

> admin interface allowing an administrator to edit user's rosters.

Hmm. So you envision something like this?

Admin: <iq from=[email-masked]/foo'
           id='bar'
           to=[email-masked]'
           type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid=[email-masked]'
                subscription='both'/>
        </query>
      </iq>

I question whether this is valuable. Wouldn't the admin have some kind
of administrative interface for completing use cases like this? I'd
envision using XEP-0133 or somesuch, not the roster protocol.

>From the user's perspective, if I can tweak the subscription attribute
via the roster protocol then my client might have expectations (hey, I
don't need to use subscription-related presence stanzas anymore!) but
support for that won't be widely deployed. However, that raises an
interesting issue about how I would manage a roster using a remote
roster management system that's not connected to my server. Because
rosters and presence have traditionally been so tightly coupled in XMPP,
I see real challenges with decoupling the two (or going halfway in that
direction).

Changing MUST to SHOULD here would be a halfway measure, but it really
doesn't address the fundamental issue and might raise more questions
than it answers.

> be the target of the set.

By "recipient" do you mean "a place where a user stores a roster"?
Again, I've been avoiding going too far down that path because we have
no experience with such entities and therefore have no solid ground to
stand on.

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Wed, 28 Jul 2010 18:18:19 +0100

> envision using XEP-0133 or somesuch, not the roster protocol.

I think roster protocol is exactly the right thing to use for
modifying rosters. We've got it, it works, why define something
semantically identical because we want a different sender. Admins will
likely have interfaces for doing this, but I see no reason to prohibit
them using iq:roster to run them.

> support for that won't be widely deployed.

I'm not arguing for less than a SHOULD. If clients rely on a SHOULD
being broken without prior knowledge, they're broken, right?

> However, that raises an

What about one that's not remote, but just an admin user on the local server?

> doesn't address the fundamental issue and might raise more questions

But because it's a SHOULD, no-one is allowed to not do it unless they
understand the answers to those questions :)

> no experience with such entities and therefore have no solid ground to

You've already added a note saying "Yeah, we'll say server but it
might mean something else", I believe. I'm happy with that.

/K

---

From: "Peter Saint-Andre" <[email-masked]>
Date: Wed, 28 Jul 2010 16:20:20 -0600 (MDT)

> might mean something else", I believe. I'm happy with that.

So does the text need to change? I suppose you might not be sure, given
that I haven't yet submitted a revised version. I might do that tomorrow
so that folks can check the diff before the WG meeting.

/psa