[Standards] PAM Source Selection

Dave Cridland dave at cridland.net
Wed Sep 7 09:22:08 UTC 2016


On 7 Sep 2016 11:18, "Kevin Smith" <kevin.smith at isode.com> wrote:
>
> 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).

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.

>
> /K
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160907/fbd0cbe3/attachment-0001.html>


More information about the Standards mailing list