[JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
Jim, Well, my idea was that this kind of xml would be interpreted as 1- I, as the query originating user, don't want to have anything to do with [EMAIL PROTECTED] , hence the "deny" without any kind of sub elements in the tag, 2- [EMAIL PROTECTED] will be denied to receive/send any and (as specified by the tags contained in the element) from the originating user (the one that is seting-up the list) 3- [EMAIL PROTECTED] will be allowed to receive/send (as specified by the tag contained in the element) to the originating user. If filtering specific namespaces comes into the picture, I gather the easiest way to transcribe this kind of constraint would be to include tags inside the tag, as most namespaces in Jabber are used by info queries. A possible use could be jabber:iq:browse jabber:iq:oob which could be interpreted as [EMAIL PROTECTED] is denied to receive/send any packets that pertain to the jabber:iq:browse and jabber:iq:oob namespaces, and may receive/send other iq packet to the originating user. This is obviously not a real life case, just a way to show how the xml tags would look like. As to why I propose this xml syntax rather than modifying the element, I tend to agree with Peter in that we should keep the protocol from going in too many directions. The element doesn't provide any support for attributes outside the xmlns. To keep some kind of consitency in the way we build new xml snippets, it is probably best to achieve the requested result by specifying differently the inner elements, like the tag. Now the way this would work in practice is a matter of : 1- agreement of what the defaul behaviour must be 2- implementation at the server level. A possible combined white/black list could be to say that anybody not in the blacklist is automatically "allowed". Some others may like the oposite, where anything which is not in the whitelist is automatically black listed, and probably the best (IMHO) appraoch would be to have the choice of the default server behaviour by setting some switch in the configuration file (note that this last approach would certainly require that the client be able to query what the defaul behaviour of the server is). As to the way this should be implemented at the server level is at this stage a bit premature. But I would think that having this information arranged as "attributes" of a user profile that would be interpreted by a rule engine could be a way to go. Coming to the relation that may exists between the privacy namespace and the "invisible" attribute in the presence tag, my understanding is that the "invisible" state is a transient user status, i.e. something that is only valid for the duration of it being set in a user session, whereas the privacy namespace manages a persistent state that should be enforced every time the user logs in and create a user session. Again what the server should do is a matter of agreement, but I would be thinking that if you have denied somebody to receive your presence information at the level of the privacy namespace this will take precedence on any subsequent change to "invisible" status, as the server should not relay that presence info anyway. Does it make sense? Jean-Louis > Message: 7 > To: [EMAIL PROTECTED] > Subject: Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny) > Date: Sun, 17 Mar 2002 10:50:59 -0500 (EST) > From: [EMAIL PROTECTED] (Jim Seymour) > Reply-To: [EMAIL PROTECTED] > > "Jean Louis Seguineau" <[EMAIL PROTECTED]> wrote: > > > [snip] > > What I meant was to use > > something like: > > > > > > > > > > > > > > > > > > > > > > > > > > > [snip] > > Forgive me if my comments are nonsense. I'm relatively new at Jabber > and XML. > > It seems to me the above doesn't work. How would a combined deny/allow > list work in practice? Specifically: what should the server do in the > presence of both, but the absence of a particular JID on either list? > Allow? Deny? And in the above scenario, what should the server do? > First JID match wins or last JID match over-rides? > > Here are my thoughts, such as they are and keeping the caveat I > mentioned above in mind. > > First of all: I believe "whitelisting" support needs to happen at the > start. Particularly if the goal is to provide support similar to that > of AIM. What I'm mainly working on is Jabber support in Gaim, so both > "blacklisting" and "whitelisting" capability would make things > considerably easier for consistency's sake. > > I'm wondering if something more like this wouldn'
Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
"Jean Louis Seguineau" <[EMAIL PROTECTED]> wrote: > [snip] > What I meant was to use > something like: > > > > > > > > > > > > > [snip] Forgive me if my comments are nonsense. I'm relatively new at Jabber and XML. It seems to me the above doesn't work. How would a combined deny/allow list work in practice? Specifically: what should the server do in the presence of both, but the absence of a particular JID on either list? Allow? Deny? And in the above scenario, what should the server do? First JID match wins or last JID match over-rides? Here are my thoughts, such as they are and keeping the caveat I mentioned above in mind. First of all: I believe "whitelisting" support needs to happen at the start. Particularly if the goal is to provide support similar to that of AIM. What I'm mainly working on is Jabber support in Gaim, so both "blacklisting" and "whitelisting" capability would make things considerably easier for consistency's sake. I'm wondering if something more like this wouldn't work better (warning: possibly completely brain-dead XML follows): Which would provide for: Then an empty "deny" list would be "permit everybody" and an empty "permit" list would be a "deny everybody". Admittedly: I'm not sure how this would work in conjunction with "Client Requests to Filter a Specific IQ Namespace" (in the proposal). I'm wondering what the thoughts are wrt interaction between "privacy," subscription requests, presence and the new "invisible" stuff in 1.4.2? Would privacy "trump" these? In other words: if a JID was denied (or not allowed--same thing): would/should the server automatically not propagate subscription requests from the denied JID to the client? And/or should it not propagate presence info back to the denied JID? Regards, Jim -- Jim Seymour | PGP Public Key available at: [EMAIL PROTECTED] | http://www.uk.pgp.net/pgpnet/pks-commands.html http://jimsun.LinxNet.com| ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
[JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
Peter, I think we are on the same page :) My comment was not to change the use of the tag (which keep some consistency with other constructs), but only the type attribute of that same tag (what you expressed in your second point). What I meant was to use something like: where the type attribute of the tag which is only presented as "block" in the JEP becomes either "deny" for black list and "allow" for white list. This way, we should be able to bring all privacy management under a single umbrella, with an adequate granularity. Jean-Louis > Message: 12 > From: "Peter Millard" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny) > Date: Tue, 12 Mar 2002 09:38:39 -0700 > Reply-To: [EMAIL PROTECTED] > > I used as the tag for a few reasons: > > 1) It keeps consistancy w/ the roster protocol. > 2) It allows the type attribute to be used for: allow|deny|remove. Using > allow and deny as the element names would mean we'd have to come up w/ a new > way of removing items from the list. > > Otherwise, I find that often this is just a XML syntax "religious" issue :) > If we just needed allow & deny, I'd agree to use the element names. But the > removal issue is the big reason I went with a generic tag. > > Peter M. > > - Original Message - > From: "Jean Louis Seguineau" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, March 12, 2002 8:58 AM > Subject: Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny) > > > > Peter > > > > After looking again at JEP-0016: Server-Based Privacy Rules > > (jabber:iq:privacy), wouldn't it be interresting to use "allow"/"deny" as > > type instead of "block" in the item tag. This way the namespace would be > > able to manage both the blacklist and the whitelist in a single process. > > > > Jean-Louis > ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
I used as the tag for a few reasons: 1) It keeps consistancy w/ the roster protocol. 2) It allows the type attribute to be used for: allow|deny|remove. Using allow and deny as the element names would mean we'd have to come up w/ a new way of removing items from the list. Otherwise, I find that often this is just a XML syntax "religious" issue :) If we just needed allow & deny, I'd agree to use the element names. But the removal issue is the big reason I went with a generic tag. Peter M. - Original Message - From: "Jean Louis Seguineau" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 12, 2002 8:58 AM Subject: Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny) > Peter > > After looking again at JEP-0016: Server-Based Privacy Rules > (jabber:iq:privacy), wouldn't it be interresting to use "allow"/"deny" as > type instead of "block" in the item tag. This way the namespace would be > able to manage both the blacklist and the whitelist in a single process. > > Jean-Louis ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
Peter After looking again at JEP-0016: Server-Based Privacy Rules (jabber:iq:privacy), wouldn't it be interresting to use "allow"/"deny" as type instead of "block" in the item tag. This way the namespace would be able to manage both the blacklist and the whitelist in a single process. Jean-Louis > From: "Peter Millard" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny) > Date: Mon, 11 Mar 2002 11:00:50 -0700 > Reply-To: [EMAIL PROTECTED] > > Jim - > > For those of us not some intimately familiar with the AIM client, perhaps > you could explain in more "jabber-ish" terms what these modes mean. Are they > "presence modes" (ie, determining who gets you presence info) or "message > modes" where you can determine who can send you messages?? > > More comments inline below: > > - Original Message - > From: "Jim Seymour" <[EMAIL PROTECTED]> > [STUFF MUNCHED] > > With server release 1.4.1, I found this model difficult to achieve, at > > best. (At least not w/o maintaining a lot of local state information. > > E.g.: who you've denied in the past so if you later want to permit > > them, you can make the appropriate presence/roster changes.) > > > > This JEP was brought to my attention > > > > JEP-0016: Server-Based Privacy Rules (jabber:iq:privacy) > > http://www.jabber.org/jeps/jep-0016.html > > > > I had considered submitting comments to the author. (For example: > > "white- listing" needs to go in right at the start, IMHO.) In the > > mean-time, server 1.4.2 has been released. In the docs for that I find > > > > JEP-0018: Presence > > http://www.jabber.org/jeps/jep-0018.html > > > > This seems to duplicate/trump/obsolete/whatever, JEP-0016, in a way? > > Not at all.. Blacklisting + Whitelisting are VERY different from invisible > mode. JEP 16 deals with how clients can control what packets the server > (jabberd) delivers to it. JEP 18 deals with how the user can control WHO can > see them online (their availability information). > > > As you might imagine, I'm wondering what to think of all this. > > > > Lastly, in any event, it seems to me the client code will have to know > > what version of the server it's dealing with so it can know what is > > supported and what is not. (E.g.: 1.4.1 won't support "invisible," > > 1.4.2 does.) Is there a way to fetch the server's release level? > > Servers that do NOT support invisible mode will return a presence error. > This is pretty easy for the client to trap and then send a normal > "available" packet and notify the user that the server doesn't support > invisible mode. You can try this against any 1.4.1 or JCS install. > > Hope this helps. > > Peter M. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
"Peter Millard" <[EMAIL PROTECTED]> wrote: > > Jim - > > For those of us not some intimately familiar with the AIM client, perhaps > you could explain in more "jabber-ish" terms what these modes mean. Are they > "presence modes" (ie, determining who gets you presence info) or "message > modes" where you can determine who can send you messages?? I *think* they're both. I'm not much familiar with AIM clients myself. I do know that when you deny or not-allow someone, they can no longer "see" you. > > More comments inline below: Likewise :-) > > - Original Message - > From: "Jim Seymour" <[EMAIL PROTECTED]> [snip] > > > > This seems to duplicate/trump/obsolete/whatever, JEP-0016, in a way? > > Not at all.. Blacklisting + Whitelisting are VERY different from invisible > mode. JEP 16 deals with how clients can control what packets the server > (jabberd) delivers to it. JEP 18 deals with how the user can control WHO can > see them online (their availability information). Ok. (I may have more thoughts on this later. I need go cogitate on it a bit.) > > > As you might imagine, I'm wondering what to think of all this. > > > > Lastly, in any event, it seems to me the client code will have to know > > what version of the server it's dealing with so it can know what is > > supported and what is not. (E.g.: 1.4.1 won't support "invisible," > > 1.4.2 does.) Is there a way to fetch the server's release level? > > Servers that do NOT support invisible mode will return a presence error. > This is pretty easy for the client to trap and then send a normal > "available" packet and notify the user that the server doesn't support > invisible mode. You can try this against any 1.4.1 or JCS install. I was thinking of just not "trying it" on servers that don't support it. Call it "bandwidth conservation" ;-). > > Hope this helps. It does. Thanks. Regards, Jim -- Jim Seymour | PGP Public Key available at: [EMAIL PROTECTED] | http://www.uk.pgp.net/pgpnet/pks-commands.html http://jimsun.LinxNet.com| ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
Jim - For those of us not some intimately familiar with the AIM client, perhaps you could explain in more "jabber-ish" terms what these modes mean. Are they "presence modes" (ie, determining who gets you presence info) or "message modes" where you can determine who can send you messages?? More comments inline below: - Original Message - From: "Jim Seymour" <[EMAIL PROTECTED]> [STUFF MUNCHED] > With server release 1.4.1, I found this model difficult to achieve, at > best. (At least not w/o maintaining a lot of local state information. > E.g.: who you've denied in the past so if you later want to permit > them, you can make the appropriate presence/roster changes.) > > This JEP was brought to my attention > > JEP-0016: Server-Based Privacy Rules (jabber:iq:privacy) > http://www.jabber.org/jeps/jep-0016.html > > I had considered submitting comments to the author. (For example: > "white- listing" needs to go in right at the start, IMHO.) In the > mean-time, server 1.4.2 has been released. In the docs for that I find > > JEP-0018: Presence > http://www.jabber.org/jeps/jep-0018.html > > This seems to duplicate/trump/obsolete/whatever, JEP-0016, in a way? Not at all.. Blacklisting + Whitelisting are VERY different from invisible mode. JEP 16 deals with how clients can control what packets the server (jabberd) delivers to it. JEP 18 deals with how the user can control WHO can see them online (their availability information). > As you might imagine, I'm wondering what to think of all this. > > Lastly, in any event, it seems to me the client code will have to know > what version of the server it's dealing with so it can know what is > supported and what is not. (E.g.: 1.4.1 won't support "invisible," > 1.4.2 does.) Is there a way to fetch the server's release level? Servers that do NOT support invisible mode will return a presence error. This is pretty easy for the client to trap and then send a normal "available" packet and notify the user that the server doesn't support invisible mode. You can try this against any 1.4.1 or JCS install. Hope this helps. Peter M. ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
On Mon, Mar 11, 2002 at 08:46:28AM -0500, Jim Seymour wrote: > Lastly, in any event, it seems to me the client code will have to know > what version of the server it's dealing with so it can know what is > supported and what is not. (E.g.: 1.4.1 won't support "invisible," > 1.4.2 does.) Is there a way to fetch the server's release level? Sending a query like this will get you the version. Of the server. Well, of the JSM, which is what you want.[1] cheers dj [1]hendiadys is alive and well ;-) ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
[JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
Hi All, I've been working on the Jabber plugin for Gaim. One of the features requested is support for "AIM-style" buddy permit/deny. As I understand it, the way AIM handles this is that you set one of four "modes": permit all, deny all, permit some or deny some. For the latter two: you also send along the list of those permitted or denied. With server release 1.4.1, I found this model difficult to achieve, at best. (At least not w/o maintaining a lot of local state information. E.g.: who you've denied in the past so if you later want to permit them, you can make the appropriate presence/roster changes.) This JEP was brought to my attention JEP-0016: Server-Based Privacy Rules (jabber:iq:privacy) http://www.jabber.org/jeps/jep-0016.html I had considered submitting comments to the author. (For example: "white- listing" needs to go in right at the start, IMHO.) In the mean-time, server 1.4.2 has been released. In the docs for that I find JEP-0018: Presence http://www.jabber.org/jeps/jep-0018.html This seems to duplicate/trump/obsolete/whatever, JEP-0016, in a way? As you might imagine, I'm wondering what to think of all this. Lastly, in any event, it seems to me the client code will have to know what version of the server it's dealing with so it can know what is supported and what is not. (E.g.: 1.4.1 won't support "invisible," 1.4.2 does.) Is there a way to fetch the server's release level? Thanks, Jim -- Jim Seymour | PGP Public Key available at: [EMAIL PROTECTED] | http://www.uk.pgp.net/pgpnet/pks-commands.html http://jimsun.LinxNet.com| ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
