[Standards] PAM Source Selection

Kevin Smith kevin.smith at isode.com
Wed Sep 7 09:27:54 UTC 2016


On 7 Sep 2016, at 10:22, Dave Cridland <dave at cridland.net> wrote:
> > > If this seems right, I'll write this up formally into the XEP and go from there.
> >
> > It’s not clear to me that another stanza is necessary, and that this can’t come out of normal caps handling by the server. It’s probably not the end of the world to have one, but I think I would be inclined to start investigating things in terms of the traditional caps mechanism, and then upgrade to a new stanza when we find it’s needed. I’m relatively low-F on this (maybe 4ish).
> 
> Placing them into "actual" caps and disco means either:
> 
> * they're exposed globally.
> * clients have to respond to disco in different ways depending on the requestor.
> 
> The former seems bad, the latter seems like error cases would be both easy and bad.

I think there’s two blocks of data. One is capabilities, which we already have a mechanism for sorting out, so I think it’d make sense to re-use here (and this is already public).

The second is the effective blocklist. It’s clear this shouldn’t go into presence.

Perhaps the ‘blocklist’ stanza can come first, so the blocklists are prepopulated for the session when presence is then (immediately, presumably) received and the capability-based stuff kicks in.

My reasoning is based on two things:

1) I firmly believe that the common case is that if a user wants to be in a particular MIX, they want to see it on all of their clients that are capable of seeing it.
2) Where we already have a mechanism for advertising client capabilities, I think we should reuse it.

and going from there.

/K


More information about the Standards mailing list