[Standards] PAM Source Selection

Kevin Smith kevin.smith at isode.com
Wed Sep 7 09:18:22 UTC 2016


On 7 Sep 2016, at 10:07, Dave Cridland <dave at cridland.net> wrote:
> 
> In the xsf@ chatroom, Georg Lukas, Ralph Meijer, Kevin Smith, and I had a quick discussion on how clients might interact with PAM in order to select and filter based on information type and source.
> 
> A suggestion that morphed from this discussion (mostly from Georg and Kev) looks roughly like the following, applied through a lens of my own creation:
> 
> 1) During connect, a PAM-aware client will send an IQ containing a "caps like" hash:
> 
> <iq type='set' id='pam'><select hash='some hash'/></iq>
> 
> It can do this before presence; PAM will not send anything to unavailable clients (perhaps).
> 
> 2) If PAM doesn't recognise the hash, it can request it:
> 
> <iq type='get' id='pam2'><select hash='some hash'/></iq>
> 
> <iq type='result' id='pam2'>
>   <select hash='some hash'>
>     <mix jid='some mix channel'><!-- Specific MIX channel -->
>       <node>urn:xmpp:mix:...</node>
>       <node>etc</node>
>     </mix>
>    <any-mix><!-- Default MIX -->
>      <node>...</node>
>   </any-mix>
>   <any-pep><!-- Default PEP - what +notify does now -->
>     <node>...</node>
>   </any-pep>
> </select>
> </iq>
> 
> 3) PAM then does The Right Thing.
> 
> * PAM will have to inject +notify into caps? (Maybe?)
> * PAM will filter out notifications.
> * PAM adjusts subscriptions?
> 
> 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).

/K


More information about the Standards mailing list